Meltdown and Spectre vulnerabilities on Asus routers?

[netware5]

I am starting this thread to discuss the recently announced Meltdown and Spectre vulnerabilities. While mainly the Intel CPU world is affected there are many statements that some ARM CPUs are also affected at least by Spectre for sure. Regarding MIPS CPUs there is not so much information, just rumors.

What could be a solution in the case the router's CPU is affected?

 

[heysoundude]

I'd like to know too...BUT
@RMerlin is in the position of having to wait for Asus to make a move before he can implement anything in his/our firmware though.

 

[ColinTaylor]

I wondered how long it would take for somebody to bring this up.

https://www.snbforums.com/threads/h...the-asus-blue-cave-ac-2600.43096/#post-369834

My take on it is although the Cortex-A9 is supposedly vulnerable to Spectre 1 and 2 attacks it does require the malicious code to be running on the router itself. If the router's code has already been compromised to that extent I doubt the perpetrator would need to bother with Spectre.

 

[thelonelycoder]

As with the CRACK attack weeks ago, I am not worried since this new MELTDOWN affects practically every device worldwide. Billions of billions of servers, routers, workstations, mobile divices, IOTs, graphic cards. Heck, maybe even my Fitbit watch on my left wrist might be susceptible to it.
And it'll blow over, I'm sure. Just as the hidden Minix operating system on every Intel processor is almost forgotten, better known as IME.

 

[netware5]

While I generally agree with @ColinTaylor and @thelonelycoder that the specific purpose and mode of operation of routers are significantly different from servers' and desktops' ones, my opinion is that we should not neglect a various "insider scenarios". I am professional in the nuclear security area where the term "insider" is widely used and insider based scenarios are always considered when planning the protection measures. So, despite the vulnerabilities discussed require the malicious code to be running on the router itself, I am sure that we always will be able to find a scenario when the Meltdown and Spectre will give an advantage to potential malicious attack against router.

 

[RMerlin]

I'll just say that I ain't losing any sleep over the potential vulnerability of routers, as this exploit is quite difficult to exploit in the first place. And since most services on the router already have root access, this exploit isn't going to change much for them.

Some of the variants will never be fixed, as it basically requires rewriting ALL application code to mitigate the risk. Ain't gonna happen.

That's why companies like Microsoft and others talk about "mitigation" rather than "fixes" in this case.

 

[sfx2000]

It is possible for the spectre attack - and it can be used to suss out some info - that being said, as other have pointed out that routers tend to be fairly focused devices, and run everything as root/admin, so if someone is exploiting this bug/issue, one has bigger problems

General common sense - don't expose services that are hosted on the router without knowing the risks, always change passwords from default, and try not to run things on a the router that are probably better to be done with an adjunct box

 

[Beherit]

Both vulnerabilities allows users to access data within protected memory areas by running malicious code that exploits either vulnerability.

As routers in general, including the entire ASUS range, already run everything as root, no exploits are needed to access any and/or all memory areas. Thus it makes no difference if Meltdown and Spectre affects routers or not.

I guess that, in theory, you could use the router as a multi-user server. But no one should even attempt that.

 

[netware5]

There are some people that are using routers as a small NAS with attached usb disk. In such cases a multi-user environment is expected.

 

[RMerlin]

There are some people that are using routers as a small NAS with attached usb disk. In such cases a multi-user environment is expected.

That's not what is meant by "multi-user". The Samba service runs as root.

 

[sfx2000]

It's not that one user could read another user's data, it's that a process can see another process's data in kernel space - so even in an environment like AsusWRT, malicious code could be a problem.

 

[gjf]

To exploit any of these vulnerabilities it is necessary to run a process that will read a memory from other process.
Normally nobody will run untrusted new processes in router environment.
If you run such processes - it is your own problem. You can run something destructive right now through ssh - taking into account it has a root permissions it will ruin the system without any vulnerability

 

[sfx2000]

For ARM, the mitigation involves patches to the kernel and toolchain (specifically the compiler) - so it's non-trivial - best would be for Broadcom to update the SDK, so all Broadcom based solutions would eventually inherit the fixes.

OpenWRT is bringing the changes in from upstream - which is relevant as they support x86 and many other architectures.

 

[sfx2000]

Sharing a couple of links...

Current status of patches - this guy is doing a good job of tracking things

https://github.com/hannob/meltdownspectre-patches

Github Script to check for vulns - note that you might need bash for this to work

https://github.com/speed47/spectre-meltdown-checker/blob/master/spectre-meltdown-checker.sh

 

[sfx2000]

The github script to check things... I suspect that AsusWRT is safe for the most part - always check back...

Ubuntu 16.04LTS on Braswell - my little hotel server and jumpbox - meltdown is fixed, spectre isn't

science project on ARM - this is on a Rockchip RK3288 (Cortex-A17) - it's safe

(note - science project variant, we're working with Asus' kernel at the moment - device is TinkerBoard)

And lastly on Raspbian - Pi3 with Cortex-A53 on a more recent kernel... it's safe as well.

 

[Stephen Becker]

Considering ASUS routers are single user devices (everything runs as root), I don' think it matters if the router is vulnerable or not. The issue allows non-privileged processes to access privileged memory addresses. If everything is privileged, does it matter?

 

[sfx2000]

While I can't speak for AsusWRT, as I'm not an active contributor code wise to that project, or the forks...

In late 2016 thru the 1st half of 2017 - myself and a team of developers did build out an embedded distribution targeting various ARMv7A processors - including the Cortex-A9 cores similar to the Broadcom chips used in various AsusWRT devices... (the project does not support the Broadcom chip in Asus devices, as it doesn't include certain features, namely neon and vfp3/vfp4).

While I'm no longer active on that science project, I was brought back in to consult with the team - looking at the expected use cases and affected cores... cafeole supports Cortex-A7/A8/A9/A15/A17 based chips. Cafeole, for production is built on Kernel 4.4, so long term support is in place for the foreseeable future - patches have been pulled in for the kernel, and gcc is patched as well - the proper fix is also to look at all the packages and patch them on a rolling basis.

Generally though - even with embedded Linux - it's really hard to use this vulnerability expect in certain cases, and most of those cases require a couple of things...

1) untrusted applications
2) untrusted user behavior

Item (1) is easy - know the code and usage, most code behaves well - it's the untrusted code that can get in the way - this is why Web browsers are being patched up and updated, as many are operating systems of their own with extensions, plugins, and Javascript in general - this doesn't impact most embedded applications because the ability to arbitrarily load things is limited...

Item (2) - comes down to basic security hygiene - limit access to users and services - with embedded devices, it's really down to services exposed, and meltdown/spectre doesn't really change things there - with item (1) above, the code needs to get on the device in the first place, assuming that the code in place is trusted and vetted.

Exposing services on the public internet is always an opportunity with a single user as a threat surface, but that's nothing new - bad configs, default passwords, etc - the risk for AsusWRT is there is no user privilege separation, as everything runs as the same userid - but there's still process separation with trusted code - so again, AsusWRT by design is a closed system, and the items in place for a factory setup, or one by trusted third parties (@RMerlin and similar) should be fine - I would absolutely trust @RMerlin's builds...

One of the reasons why I started down the path of the science project that became cafeole was to deal with the security issues and concerns around the then current state of things in embedded space - while it would be nice to backport to Asus (and other consumer router/AP's), our memory and store footprint is larger than what most devices have on hand - min for the distro is 1GB ram and 8GB eMMC/SD, and that's well beyond most consumer router/AP's