Written by Jan Otte, Thursday 11 January 2018
Early this year, a few vulnerabilities impacting inside-CPU code were announced.
While there is not a full disclosure available to us at present time, we can tell a few things now.
First, not all of the vulnerabilities are limited to x86 architecture. The ARM architecture is impacted as well.
While keeping this brief and understandable, the nature of announced vulnerabilities (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) lies in the problems connected with a few techniques used inside of the CPU.
The known impact is information leak via side effects of speculative execution. "Speculative execution" is nothing extraordinary. It is just a technical name of a well-known and widely used technique inside of the CPU which boosts up the execution power of the CPU. Due to the implementation details of this technique, it is possible that one process executing on the CPU is, under some circumstances and effort, able to read some parts of the memory without having a proper access rights.
While the impact on multi-user and cloud machines is high, impact on our products is very low and with the right (default) configuration, none.
Router, in its nature, is build as a single-user machine as in reality, the single user is used by the systems - there are no real users logging in and executing programs. Considering the shell access (ssh), if this is allowed, only the root user (administrator) should be allowed to do this. It does not matter if this is realized under the real 'root' account or using a secondary account for ssh access, given the secondary account credentials are known only to the administrator.
In our system, it is possible to define other users than root user, but the ssh access is disabled by default. The additional users are here for the possibility of showing only subset of the web configuration, not for allowing ssh acces to a third party.
Our system is build, prepared and made quite secure to the usage as a router. Also, our devices are able to serve as application gateways, providing either data or services to other devices. Our main way of doing this is by User Modules. User Modules are meant as a way how to provide extended functionality. However, User Modules are run under the root account intentionally - it represents a system service, not a non-system-user application.
To sum it up, router is a single user system with the availiability of providing different web configuration abilities via creation of additional users.
As such, while impacted by some of the recently announced vulnerabilities, these vulnerabilities does not present any new attack vector on our devices.
Just to repeat and provide view from another side - to exploit the vulnerabilities, attacker needs to execute malicious code on the targetted device.
On our devices, only the root (or more generally, the administrator) is able to add additional code to the code already present on the system. As she is an admin already, she can access all the data in the system so even if she can exploit the vulnerabilities, there is nothing new that can be gained.
The devices are not executing any other code. There is no way how the incoming or trespassing traffic can be executed. There is no browser running on the router executing Javascript or JAVA code from the Internet.
Which keeps us with the only possible attack vector, which can be opened by a specific configuration - if the administrator of the router adds a user account, opens a shell access for this account and passes credentials to this account to a third party.
Please note, that our device - as mentioned above - is build and made secure as a single-user system. Which means that by giving shell access to a third party, the security model is broken. One should not need a Spectre or Meltdown vulnerabilities to get to priviledged information once the security model is broken. Yes, being a modern and secured Linux system, our OS is still quite resistant in giving out privileged data to a unprivileged process but given the security model is broken, a capable attacker will find her way sooner or later.
As a result of current state of the knowledge about the announced vulnerabilities and our security model in-place, we see no motivation in applying fixes. With existing security model, the fixes to the announced vulnerabilities would only negatively impact performance of the system while giving no additional security.
If, in future, the further research of the announced vulnerabilities would open any unforseen attack vectors, like remote exploitability, we could reconsider our approach. However, remote exploitability of Meltdown or Spectre is very improbable.
As a 'point' of this blogpost I would rather urge you: do you have (on a router) open shell access for a third party? If so, close it and update FW to last version (to make sure you get rid of possible rogue binaries)(*). There is no other action that could be considered safe, regardless of Meltdown or Spectre.
(*) Actually, you should also remove all user modules, wipe out the rest of /opt directory and restore configuration from backup as the configuration could contain scripts. Afterwards, you can re-install the preferred user modules.
Links:
