4

Mitigations for Spectre and Meltdown are being added to the JavaScript VMs in Chrome, Firefox, IE/Edge and WebKit.

Are similar mitigations also needed in the VMs for other dynamic languages?

For example, I assume mitigations are needed in LuaJIT because, like a JavaScript engine, it supports JIT compilation of untrusted code. Does PUC Lua also need these mitigations, or is it immune to these attacks because it is only an interpreter?

Are mitigations also needed in other VMs such as CPython, PyPy and Ruby MRI? Am I right in thinking that these VMs do not try to support secure execution of untrusted code, and hence can ignore these attacks?

  • Every engine can interpret any code, trusted or not. The difference is only that browser JavaScript engines always do interpret untrusted code. Sure, engines that are not supposed to be used with untrusted code don't need any mitigations against this. It does not depend on the scripting language, it depends on the use case. – Bergi Jan 11 '18 at 13:27
  • @Bergi - Thanks for your comment. Do you know whether it's true that the main implementations of Python and Ruby "are not supposed to be used with untrusted code"? – user200783 Jan 11 '18 at 14:49
  • I guess the existence of the file system api alone makes it clear that all code will run with full privileges of the current user and should therefore be trusted. I'll guess that there are special sandboxing libraries/solutions for executing untrusted code. I do not know whether there are any sandboxed-by-default implementations. – Bergi Jan 11 '18 at 16:29
3

As long as a VM doesn't execute an untrusted code, no.

Note that "executing untrusted code" includes taking code snippets from Github, StackOverflow or elsewhere and running them in a sandbox of any kind, like: a chroot, an isolated container or a virtual machine (but except a browser sandbox, like Brython or Emscripten, once proper browser mitigations are in place).

If a VM can under any circumstances execute an untrusted code, the answer is: it depends. It's still possible that it doesn't need all or any of the mitigations a JS engine now features, but your threat model becomes much more complicated.

As of now, a few requirements must be met for your VM to be theoretically exposed to Meltdown or effects of Spectre:

  1. The VM runs an untrusted code which can, at least, send messages to the outside world.

    Including, but not limited to, Internet access or permissions to display or write data to a location which could later at some point be accessible by an attacker.

  2. The VM allows usage of high precision timers or tools that could be used to measure relative execution time of the respective programming language instructions.

    Including, but not limited to, buffers shared between concurrent threads.

  3. The VM features optimization techniques that, at least theoretically, could allow the untrusted code to run with approximately the efficiency of compiled code.

    Including, but not limited to, just-in-time (JIT) compilation or optimized bytecode generation.

    It is believed[citation needed], that at least in case of CVE-2017-5715, under certain circumstances (e.g. presence of particular binary instruction sequences in system libraries and a series of unfortunate events), this particular requirement could be further relaxed or lifted.

  4. Any of the following conditions are met:

    • OS mitigations for Meltdown are not applied
    • The VM loads a sensitive information in the same process where the untrusted code snippet could run
    • An attacker can supply some input into any other process (which has a sensitive information in its memory and runs on the same physical system the untrusted code runs on) at the same time while the untrusted code is running, from the untrusted code itself or by any other means, directly or indirectly

If all four conditions above are true, then, theoretically, your VM could be used to extract a sensitive information from your system, based on effects of Spectre and/or Meltdown.

A simple example of a virtual machine which, albeit effectively often running a third-party code, is not exposed to Spectre is the TrueType glyph hinting language VM which doesn't allow threading or instruction timing in any way, thus breaking, at least, the requirement #2.

An important note on system updates.

In case of Javascript PoC, Meltdown or Spectre aren't used to read either kernel memory or memory of other processes. They can be, but the main issue with Spectre in Javascript VM is that the VM runs in a sandbox (meant to be isolated and safe before) within a browser process which contains sensitive data (Web site passwords, cookies and so on).

OS updates (e.g. KPTI for Linux) won't help to mitigate the issue completely, because:

  1. They target Meltdown while the main issue is Spectre;
  2. The only thing KPTI guarantees is that a process wouldn't be able to read kernel memory (and memory of other processes mapped into kernel space, via Meltdown only). KPTI doesn't forbid a thread in a process from reading a memory which is, from the operating system point of view, available for the whole process to read, which is the case of passwords and cookies stored in the same browser process a JS sandbox runs in.

Also, to be one hundred per cent accurate, you've asked if "similar mitigations" (to JS VM ones) are needed in VMs for other languages. Please note that a contemporary in-browser JS VM already features an overall well-designed sandbox which has limited access to filesystem, IPC, assembly language, and other system resources. In case your VM (e.g. a V8 JS VM which is shipped with Node.js platform) has more permissions or abilities than an in-browser JS VM has, it may require not similar, but further and more strict mitigations.

As of January, 14, 2018, this is in theory; but your question is also theoretical.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.