I just learned about the Meltdown and Spectre attacks (CVE-2017-5754, CVE-2017-5753, CVE-2017-5715).

How vulnerable are our x86 routers? When will a patch be available?

Looking for a official word from Mikrotik.

What about Meta-Router feature? And Spectre is not Intel only, also ARM.

https://security.googleblog.com/2018/01 ... -need.html

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.

so its not possible to get from a guest down to the host?

I'm not sure about that, according to "The Register"

On a shared system, such as a public cloud server, it is possible, depending on the configuration, for software in a guest virtual machine to drill down into the host machine's physical memory and steal data from other customers' virtual machines. See below for details on Xen hypervisor updates.

https://www.theregister.co.uk/2018/01/0 ... erability/

It is possible (at least on Xen)

Why would you want to use a virtual router under RouterOS in an environment where you already run RouterOS under a hypervisor?
You can just as well run the virtual router as a separate machine under the hypervisor.

RouterOS is not affected if you only use RouterOS.

Since RouterOS does not easily allow custom code to be run, the Meltdown/Spectre attacks won't affect most RouterOS users.
However, you should be careful with KVM guest systems and who has access to them.

Here are a few things you can do: https://www.renditioninfosec.com/2018/0 ... tion-plan/

I heard that it can be exploited from Javascript.
Javascript is a lot more versatile than RouterOS scripting, so it could well be that exploiting it from there is impossible.
But it should be noted that having "guest" type users who can execute scripts could in theory lead to acquiring more privileges.

I heard that it can be exploited from Javascript.
Javascript is a lot more versatile than RouterOS scripting, so it could well be that exploiting it from there is impossible.
But it should be noted that having "guest" type users who can execute scripts could in theory lead to acquiring more privileges.

Javascript can access the CPU of your system (where the browser is running). in RouterOS there is no web browser or javascript.

The issue is not "is there a webbrowser or javascript", the issue is "is there a programmable environment where users can execute their own code".
While it surprises me that it can be exploited from javascript (vs. only from assembler or C or similar low-level language), I cannot rule out that when
it can be exploited from javascript it can be exploited from another scripting language as well.
That would not provide an attack vector via routed network traffic, but it could do so when you have guest users that can login to the router but do
not have full privileges, yet want to obtain those.

I am not aware of any user rights combination that allows you to run your own code and scripts, but has no full rights group already.
The only weak spot is an uncontrolled KVM guest where you have some untrusted people using linux as virtual machine.

I tested with a user with only the default read group, and it can telnet to the router and run scripts in immediate mode (commandline).

give an example of what kind of script you ran.
anyway, those scripts are not able to exploit Spectre, routeros scripting is not too powerful.

I just typed a simple for loop and it worked.
However, I already wrote that it is not certain that it can be used to exploit this vulnerability.
In fact I am surprised that it can be done via Javascript.

While spectre/meltdown might not be an initial attack vector for RouterOS, it's entirely possible that it could be used in conjunction with other vulnerabilities, known or unknown, to make an attack worse. There are cross-hypervisor possibilities for example, so if a remote code execution bug exists, there's a possibility to use that to access physical RAM across VM boundaries.

While it appears there's no absolute software fix, it'd be appreciated if Mikrotik could ensure that any applicable kernel-level and application-level mitigation patches to RouterOS components are applied and pushed out as soon as is practical and safe.