[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[rstone]

It seems another update will be needed, OpenVPN has 4 new vulnerabilities.
Not sure it is relevant for our hardware,but remote execution sounds nasty enough.
https://guidovranken.wordpress.com/2017/06/21/the-openvpn-post-audit-bug-bonanza/

 

[john9527]

Now with that troublesome CVE behind us (fingers crossed ), back to some other updates! This beta contains a bunch of component updates and some Merlin backports.

BETA RELEASE: Update-26B5
21-June-2017
Merlin fork 374.43_2-26B5j9527
Download http://bit.ly/1UGjcOX
============================

Following are the major changes (full changelog is in the zip files)

Update-26B5 Highlights

• Updated versions of:
  • OpenVPN to 2.4.3
  • OpenSSL to 1.0.2l
  • miniupnp to 2.0 with a new Port Forwarding syslog page (Any XBox gamers willing to test?)
  • samba - update to 3.6.25 which includes SMB2 support (enable on the USB servers page)
  • nano to 2.8.4
  • dropbear to 2017.75
  • ipset-arm to 6.32
  • avahi to 0.6.32
  • dnscrypt to 1.9.5
  • curl to 7.54
  • ASUS protection server to 380.7627
• Several backports from the latest Merlin builds

As always, a reminder to have a backup of /jffs in case the jffs space needs to be reformatted due to increases in firmware size.

SHA256

2800e24631efbbe53ad333047626a8477720dd2be70a4b97fcbd908592bea371  RT-AC68U_3.0.0.4_374.43_2-26B5j9527.trx
9618963a09eae016bece0ec23d2854723f8d4d701f99cd76c46b23924121f0d0  RT-AC56U_3.0.0.4_374.43_2-26B5j9527.trx
e0d9274986f1c0ae5870cb4515be0d445cb539c5d4b095678424432458d27e53  RT-N16_3.0.0.4_374.43_2-26B5j9527.trx
4a715680fc0b3af1cdfe95d300e04fea9c0c4b56f6cf703bd2ce2e005bd8d3ec  RT-AC66U_3.0.0.4_374.43_2-26B5j9527.trx
47683bfede72c79c7ad77b88f35e7d273bce40a37f3d2d4bd922597d72faa1c1  RT-N66U_3.0.0.4_374.43_2-26B5j9527.trx

 

[cybrnook]

John, is this a thing?

I have noticed, and gotten used to, that when my page timeout is reached (Web UI is up, idle for x amount of time, I am auto logged out), I am displayed a page that says something along the lines of "you have been logged out due to inactivity", or something like that.

If I delete the end of the url's *.asp extension, so router.asus.com/logout.asp (or whatever it is), and bring it back to just router.asus.com and hit enter, my session cookie is still active and I am instantly logged back in. I would have half expected to see a un/pw prompt again.

Couldn't something like this be tied back to a CSS type vulnerability?

 

[ColinTaylor]

@cybrnook It's always done that. You can also just hit the browser's Back button to achieve the same thing.

 

[john9527]

I would have half expected to see a un/pw prompt again.

Don't save your password in the browser and you will be prompted again for your credentials. It's all part of how standard http validation works.

 

[cybrnook]

Don't save your password in the browser and you will be prompted again for your credentials. It's all part of how standard http validation works.

I don't have my credentials saved in my browser, that's the thing..... (or any credentials for that matter) Type them by hand every time, initially.

Browser is latest/greatest firefox/chrome (but normally I only use firefox to manage my local devices)

@cybrnook It's always done that. You can also just hit the browser's Back button to achieve the same thing.

I understand, and yes, it's been this way for a long time. But my concern is it's not a "true" log out. Just a redirect to a page telling me I was logged out. And hitting back, or just navitating to router.asus.com again, you are not prompted to log back in. Hence you were never really logged out.

 

[ColinTaylor]

I understand, and yes, it's been this way for a long time. But my concern is it's not a "true" log out. Just a redirect to a page telling me I was logged out. And hitting back, or just navitating to router.asus.com again, you are not prompted to log back in. Hence you were never really logged out.

Are you using HTTP or HTTPS, I suspect it might be different with HTTPS but I haven't tried.

BTW. In this log the penultimate line is the "timeout" and the last line is me hitting the browser's Back button.

Jun 22 16:40:25 HTTP login: login 'admin' successful from 192.168.1.238:80
Jun 22 16:47:27 dropbear[4114]: Child connection from 192.168.1.238:51367
Jun 22 16:47:33 dropbear[4114]: Password auth succeeded for 'admin' from 192.168.1.238:51367
Jun 22 16:50:28 HTTP login: logout successful 192.168.1.238:80
Jun 22 16:53:28 HTTP login: login 'admin' successful from 192.168.1.238:80

 

[cybrnook]

HTTP, and yes. Same behavior for me as well. Log shows logout successful, and hitting back or re-navigating again logs the typical login successful.

We have the same behavior. My concern is it shouldn't be so. I would expect to be challenged again. Because without it, the timeout is useless.....

 

[ColinTaylor]

HTTP, and yes. Same behavior for me as well. Log shows logout successful, and hitting back or re-navigating again logs the typical login successful.

We have the same behavior. My concern is it shouldn't be so. I would expect to be challenged again. Because without it, the timeout is useless.....

It was mentioned before: https://www.snbforums.com/threads/f...leases-v25e7-v26b5.18914/page-253#post-300937

 

[cybrnook]

It was mentioned before: https://www.snbforums.com/threads/f...leases-v25e7-v26b5.18914/page-253#post-300937

Thanks, didn't see that. So at least it's a "feature".

But seems like a useless feature to keep. Why have, and specify, an auto logout if the session stays active past the logout period? With closing the tab/browser (or specifically clicking logout) being the only way to really kill it, just leave it at that, click the logout button, or close the tab.

 

[john9527]

@ColinTaylor @cybrnook
I did a little more digging, and it is actually a 'feature' (added in 2008 ) If you go off of the logout page after autologout, the router automatically supplies your username and password in the authenticate header, which is than automatically validated by the browser. If it makes everyone feel better, I can undo it and force you to authenticate again (I already tested the change)

 

[cybrnook]

@ColinTaylor @cybrnook
I did a little more digging, and it is actually a 'feature' (added in 2008 ) If you go off of the logout page after autologout, the router automatically supplies your username and password in the authenticate header, which is than automatically validated by the browser. If it makes everyone feel better, I can undo it and force you to authenticate again (I already tested the change)

Without being the one crucified here, when I enabled the auto logout feature in the webui, I was doing so under the pretense that I would be challenged for login again after the logout period.

If I wanted it to stay logged in indefinitely (until browser is closed or explicitly logged out), then I would not enable to auto log out, or set it for an obnoxious timeout length.

 

[john9527]

From the 'routers' point of view, you are actually logged off (it's no longer processing any background web activity and the login credentials are cleared). It's just a little quicker way to get back in while in the same browser session.

No problem for me....I'll queue up the change to re-authenticate for V26

 

[cybrnook]

Am I wrong with seeing this as a security concern? If the creds are stored in the header, can't that be exploited? That's all I am after, hardening.....

If you tell me it's not exploitable, I will of course believe you. I am just so consumed with security lately at work and getting everything up to "standards", it really has me opening my eyes more.

 

[RMerlin]

Am I wrong with seeing this as a security concern? If the creds are stored in the header, can't that be exploited? That's all I am after, hardening.....

That's one of the reasons why I'm not a fan of basic http authentication, as the browser can decide differently from what you might want. With a session-based authentication scheme, the server is fully in control.

 

[ColinTaylor]

No problem for me....I'll queue up the change to re-authenticate for V26

I doesn't bother me one way or the other, even though I find a quite useful because I'm very lazy. But I do agree with @cybrnook that it is counterintuitive to say that you're logged out when you can just hit the Back button.

 

[RMerlin]

ipset-arm to 6.32

ipset updating was next on my agenda - thanks for saving me the legwork

I noticed that our ipset is missing quite a few modules, was it because these aren't compatible with 2.6.36?

 

[john9527]

ipset updating was next on my agenda - thanks for saving me the legwork

I noticed that our ipset is missing quite a few modules, was it because these aren't compatible with 2.6.36?

The original support was a direct port from Tomato-Shibby.
The only thing I'm aware of that's not working is the 'extended' qualifiers when creating an ipset...skbinfo, comment and counters. (Also doesn't work on the current level). When I started to research it, I found references that these were related to linking to the kernel headers and may not work on early kernel levels. I haven't pursued it beyond that.

 

[jrmwvu04]

miniupnp to 2.0 with a new Port Forwarding syslog page (Any XBox gamers willing to test?)

Interesting.

edit: looks initially as expected, normal behavior on the boxes so far.

 

[cybrnook]

Obligated to report, had my first odd occurrence this morning.

Flashed the Beta last night around 11 PM EST or so, uneventful.

This morning decided to start using ssh keypairings on all my raspi devices at home. Which prompted me to start changing default ssh ports from 22 to something else. Got the idea I would also change my routers default 22 to something else, so logged in, and noticed right away it said uptime was 1 1/2 hours.... which I found strange, since we have had no outage over the night. Checked the log, and can confirm about 1 1/2 hours prior openvpn went through it's cycle of reconnecting (I use policy based), so seems some type of disconnect happened as the tunnel dropped, which is a clear indication.

Proceeded to change my port from 22 to something else for ssh. Went uneventful............. until about 2 minutes later, as I was clicking/navigating around in the webui, that the http server seemed to crash, navigated me to the recovery webserver, then rebooted.......

powering off and back on, I am up and running at the moment, but will likely drop back soon after the mornings work calls.