Seeking Feedback & Contributions: Merlin Auto Update Solutions

[Yota]

REST/JSON over TLS

If you update yourself via the router itself, then why do you need TLS? The traffic doesn't go anywhere, in fact it goes from io (0.0.0.0) to br0 (192.168.50.1), it just flows within the Broadcom CPU and doesn't even go through the switch chip. If you are developing a desktop app, then yes, TLS is something to consider. But why not make it easier? The router's script downloads and verifies the firmware, then refreshes it, and the desktop app simply sends an update request through the router-side script's API, so no malicious firmware will be sent from the desktop app to the router.

If this is really true then that's one less thing on the list!
I took the RMerlins message is it meaning the .zip had 2 firmware images, and the user had to select which one for their revision.

if it's really one file and the GUI picks the correct version, then we are already ahead of the game!

The list of things I'd like to consider left is:

Yes, I believe RMerlin is talking about the firmware of RT-AC68U, they merged RT-AC68Uv4 (which uses ARMv8a like RT-AC86U) and other ARMv7 based RT-AC68U firmware into the same firmware.

Love your list!

 

[sfx2000]

Right now this is a working solution and I am above happy, but always open to more contributions

Working and working well are two different things - hacking is fun, but real development is poetry...

 

[ExtremeFiretop]

Here's @RMerlin actual wording...

This is the part that I misunderstood:
But seems my misunderstanding is a non-concern

Another recent change to take into account: are you able to handle firmware files that contain two separate images for separate hardware revisions? Asus uses this for the RT-AC68U and RT-AX58U so far, possibly other models as well. I don`t know how these are being handled.

 

[sfx2000]

If you update yourself via the router itself, then why do you need TLS?

Only from remote - we still have to consider security - auth does more than just a password...

and once the cert is in place, you can sign this - this goes towards trust of the other end, trust of the fw image itself...

 

[Yota]

Only from remote - we still have to consider security - auth does more than just a password...

and once the cert is in place, you can sign this - this goes towards trust of the other end, trust of the fw image itself...

I prefer to leave all security risk operations to scripts running within the router.

Then provide an API to the remote device, and the remote device can trigger updates through the API. This can significantly reduce the attack surface.

Because we can control the input accepted by the API.

The firmware is still downloaded by a script inside the router without external intervention, so we assume that the operating environment inside the router is also trustworthy (if it is not trustworthy, then it is not our problem).

 

[ExtremeFiretop]

Working and working well are two different things - hacking is fun, but real development is poetry...

If you wish to help us take it from fun to poetry your more than welcome! Feel free to folk the project!
You seem to have some knowledge and theories on the subject and the Github is open to contributions!

The original goal as per OP was for the fun of the challenge, but I am not against extra folks in the road to explore!

 

[sfx2000]

I prefer to leave all security risk operations to scripts running within the router.

Then provide an API to the remote device, and the remote device can trigger updates through the API. This can significantly reduce the attack surface.

Because we can control the input accepted by the API.

The firmware is still downloaded by a script inside the router without external intervention, so we assume that the operating environment inside the router is also trustworthy (if it is not trustworthy, then it is not our problem).

Oh, but you can't...

Can you really trust the source and the download without TLS?

I'll tell you now - no, this is a security issue if the source and code cannot be validated

 

[sfx2000]

You seem to have some knowledge and theories on the subject and the Github is open to contributions!

I do and I can't - long story, but the short end is any code I contribute doesn't belong to me - yes, I could fight it, but that would be on my dime, and it's not worth it...

terms and conditions

So best I can do is influence others to go down a path that I would take... then it's not my code out in the public, and folks still win... design is not GPL, code is...

 

[ExtremeFiretop]

I do and I can't - long story, but the short end is any code I contribute doesn't belong to me - yes, I could fight it, but that would be on my dime, and it's not worth it...

terms and conditions

So best I can do is influence others to go down a path that I would take... then it's not my code out in the public, and folks still win... design is not GPL, code is...

Understood, I have some friends under similar constrains, feel free to keep looking around and influence away then!
(As long as the influencing stays calm and collective) Haha

 

[Yota]

Oh, but you can't...

Can you really trust the source and the download without TLS?

I'll tell you now - no, this is a security issue if the source and code cannot be validated

Yes, we can actually verify the security of the firmware as well as user can.

After the script learns that new firmware is available, the script obtains the firmware files through SourceForge over a TLS (https) encrypted connection.

A valid root certificate is present in the router, so if there is a man-in-the-middle attack, the download will not start at all. (We really don't intend to ignore the website certificate validity check when curl downloads).

That's just the first step, and then the script will visit Merlin's website to get the SHA256 of the firmware. This is an extra step because we're assuming a hacker can't hack both SourceForge and Merlin's sites at the same time, and if that happened, well, then anyone would be affected, not just because of the use of the script. (In short, it's not our fault)

Merlin's website is also TLS encrypted. Then we verify the SHA256 of the firmware, flash the firmware if it is consistent, delete it and end everything if it is inconsistent.



EDIT:
The biggest security flaw in this script is that it breaks Asus's protection of not saving the admin password in the router.

But this has been taken into consideration at the earliest stages of script development, and we will find ways to mitigate this security vulnerability.

As for the other security risks you raise, they are either faced by all users or they are invalid.

In fact, most users update their firmware without even verifying SHA256, because most people don't even have the appropriate software to do this.

Few people are willing to use the command line to verify SHA256 before each update, and script will strictly verify SHA256, so it will provide better security than careless operations done by ordinary users.

 

[Yota]

I think I may need to open a beer tonight for the progress made today, I'll poke at this list more tomorrow, cheers to everyone in this thread!

Cheers! (Don’t get drunk, otherwise you will have strange ideas, such as my RGB yesterday )

 

[ExtremeFiretop]

Cheers! (Don’t get drunk, otherwise you will have strange ideas, such as my RGB yesterday )

To be fair! My model does support RGB on the stock firmware!
I don't know if the Merlin Rog build still supports it (I've never tried the rog build, I've always done pure UI)

Only 3 beers in! It took me a second to realize yesterday if you were talking RGB or LED haha!

Edit: Correction: I've never turned on the lights at all, LED or RGB, I remember the RGB when I first took it out of the box, but since then the lights always stays off since it sits under my TV and I don't like the blinky blink distractions

 

[thelonelycoder]

Install and Uninstall features for AMTM... needing further research and assistance.

amtm is entirely my domain, no need to research.

 

[dave14305]

-Ensure the USB drive is connected to the router for storage.

I would leave this optional. If one is present, perform the extra backups. If not, keep going.

 

[Yota]

I would leave this optional. If one is present, perform the extra backups. If not, keep going.

Well, here's what I thought:

Normally a USB drive is not needed during an upgrade, you confirmed that the USB drive will eject during the upgrade, so the USB drive is indeed somewhat redundant for the upgrade.

However, I think since it is an automatic update script, it must be able to implement some security measures as much as possible to ensure that the router can function properly after the upgrade.

So the safety measure is to downgrade after discovering some flaw in the new firmware.

Automatic downgrading is as easy as updating, but the biggest problem with a router is no internet and WiFi, so this is where the USB drive comes in handy.


Here is a case:

If the script is scheduled to automatically update from 388.1 to 388.2, then the script can download and store the 388.1 (current version for rollback) and 388.2 firmware, and if the upgrade is successful, the files stored on the USB drive will never be used, if there are problems after the upgrade (like if the wifi is broken or no internet or something else), then the script will be able to downgrade to 388.1 even if there is no internet.

The USB drive is just a protection measure, of course, you need to import the old nvram backup after downgrading to prevent some problems, this case also requires the storage capacity of the USB drive.


------

Regarding the possibilities, I admit that RMerlin almost never messes up anything in the final released firmware, because we have a good testing cycle in the SNB forum, alpha, beta, and every test has many members helping to find potential bugs in the new firmware.

But historically RMerlin did release some problematic firmware as final versions, although it was not as serious as breaking WiFi or damaging the Internet, and RMerlin promptly launched a new version with repairs.

So the chances of having a fatal glitch that renders wifi and internet unavailable on the final release are really slim.

So you are right, the upgrade should be allowed without a USB drive.

 

[ExtremeFiretop]

Well, here's what I thought:

Normally a USB drive is not needed during an upgrade, you confirmed that the USB drive will eject during the upgrade, so the USB drive is indeed somewhat redundant for the upgrade.

However, I think since it is an automatic update script, it must be able to implement some security measures as much as possible to ensure that the router can function properly after the upgrade.

So the safety measure is to downgrade after discovering some flaw in the new firmware.

Automatic downgrading is as easy as updating, but the biggest problem with a router is no internet and WiFi, so this is where the USB drive comes in handy.


Here is a case:

If the script is scheduled to automatically update from 388.1 to 388.2, then the script can download and store the 388.1 (current version for rollback) and 388.2 firmware, and if the upgrade is successful, the files stored on the USB drive will never be used, if there are problems after the upgrade (like if the wifi is broken or no internet or something else), then the script will be able to downgrade to 388.1 even if there is no internet.

The USB drive is just a protection measure, of course, you need to import the old nvram backup after downgrading to prevent some problems, this case also requires the storage capacity of the USB drive.


------

Regarding the possibilities, I admit that RMerlin almost never messes up anything in the final released firmware, because we have a good testing cycle in the SNB forum, alpha, beta, and every test has many members helping to find potential bugs in the new firmware.

But historically RMerlin did release some problematic firmware as final versions, although it was not as serious as breaking WiFi or damaging the Internet, and RMerlin promptly launched a new version with repairs.

So the chances of having a fatal glitch that renders wifi and internet unavailable on the final release are really slim.

So you are right, the upgrade should be allowed without a USB drive.

I think if it's connected do a backup, else move forwards without one, the risk of something being extremely broken is low on a final release, the testing and downgrading aspect is a neat idea, but feels like if something I would want to handle manually, if the firmware release was broken anyways.
If a broken release did make it out into the wild, it was it would likely be caught by the delayed release cycle I would like to implement. (Aka wait a week before attempting the upgrade).

Edit: We provide the tools to provide the backup on USB, but don't automate that process in a worst case situation.

 

[Yota]

There is one more question I need to ask at this moment.

We do not rule out that people who use this script initially installed a very old version of the firmware. According to the logic of the script, it will always download the latest version, and RMerlin has stated many times that updates spanning multiple versions may be uncertain or unstable, which means a factory reset is necessary after the update.

So how do we deal with something like this?

We can't help users do a factory reset, but maybe we can warn users before updating?

Or do we not make big leaps and instead update version by version at a time until we catch up with the latest version after multiple updates?


In fact, please @RMerlin also join the discussion of this question, because I think most people on this forum do not have unanimous opinions and expertise on how often should factory reset be performed, and @RMerlin is one of the few who can express professional opinions on this.

 

[dave14305]

if there are problems after the upgrade (like if the wifi is broken or no internet or something else), then the script will be able to downgrade to 388.1 even if there is no internet.

Isn’t this going to require human intervention? I think having the current firmware available offline is a nice idea, but if there are issues with the upgraded firmware, I don’t think a script is going to be helpful.

 

[Yota]

I think if it's connected do a backup, else move forwards without one, the risk of something being extremely broken is low on a final release, the testing and downgrading aspect is a neat idea, but feels like if something I would want to handle manually, if the firmware release was broken anyways.
If a broken release did make it out into the wild, it was it would likely be caught by the delayed release cycle I would like to implement. (Aka wait a week before attempting the upgrade).

Edit: We provide the tools to provide the backup on USB, but don't automate that process in a worst case situation.

Yes, you are right.

Isn’t this going to require human intervention? I think having the current firmware available offline is a nice idea, but if there are issues with the upgraded firmware, I don’t think a script is going to be helpful.

I guess the purpose of this script is to reduce human intervention. So the people who use it may include people who are unable to intervene.

For example, they run this script on the router in their vacation cabin, many people may not go there for half a year.

So how to make sure this script doesn't screw up their access to the vacation cabin's VPN server? They may need to rely on that cabin's internet to unblock Netflix.

I think this is exactly what @Tech9 is arguing against this project. He may have similar usage scenarios.


You can't ask them to buy a plane ticket or drive 5 hours there to fix an error caused by a script. This is what most of the naysayers in this thread were afraid of in the beginning.

 

[dave14305]

So how to make sure this script doesn't screw up their access to the vacation cabin's VPN server? They may need to rely on that cabin's internet to unblock Netflix.

I still don’t understand how a simple shell script would “know” there’s a problem with the firmware or wifi or vpn, and it’s now necessary to downgrade the firmware.

Starting small, the first version would simply login and upload the firmware file like a person would do. What happens after that would be the same as if a human did it.

The more limited the scope of a script like this, the more trustworthy it can become. Do one thing and do it well.