3 ms·

At this point, I have serious doubts whether bytecode and JIT systems, whether it be Lua in Factorio or JavaScript in Chrome, can ever be verifiably secure. I t

At this point, I have serious doubts whether bytecode and JIT systems, whether it be Lua in Factorio or JavaScript in Chrome, can ever be verifiably secure. I think we would all be better off if, like Apple’s Lockdown mode, we can disable anything JIT on a high stakes system. I don’t blame Factorio though - this (anonymous?) researcher is 100x developer material.

stavros 2y ago
How is JIT relevant here? Unless I missed something, the attack uses straight-up malicious byte code, it doesn't exploit the JIT compiler.
- gjsman-1000 2y ago
  JIT and Bytecode are two sides of the same coin, in my head. JIT also uses bytecode in some languages like Java.
  - deleted 2y ago
    [deleted]
  - fwsgonzo 2y ago
    It's much worse than that because of the complexity around JITs, behavior of hardware and speculative execution. Proper sandboxing is really hard, and I suspect that if people really want security they would disable JIT in general. Even simple ones like pcre2. Personally I have disabled Firefox's JIT (I believe it's called ion in the settings, but correct me if I misremember) for a few years now. I've never had any trouble with any websites so far. It's not instant loading, but it's close enough. ... but I don't know if I would lump bytecode with JIT. Bytecodes don't need or use RWX execute segments, for example. Lots of your favorite JITs do, for speed.
  - nanidin 2y ago
    In this case someone generated malicious bytecode that the JIT compiler would not generate. I would argue JIT is dangerous because it requires dynamic memory without the NX bit set, so if you manage to smash the stack (find an exploit) you can execute arbitrary code easily (leverage the exploit). That's a different dangerous than running malicious bytecode.
    - colejohnson66 2y ago
      JITs can still function with an NX bit; You just have to halt execution to modify it.
    - axoltl 2y ago
      This doesn't generally apply but Apple has a bunch of hardening in place that means you don't just have an RWX mapping hanging around: https://developer.apple.com/documentation/browserenginekit/protecting-code-compiled-just-in-time https://developer.apple.com/documentation/browserenginekit/p... On top of that they're working on (I haven't checked in a bit) having the JIT compiler be entirely Out-Of-Process. I don't think a lot has been written about that publicly but there's a few breadcrumbs like https://developer.apple.com/documentation/kernel/oop_jit_conversion https://developer.apple.com/documentation/kernel/oop_jit_con...
  - pjmlp 2y ago
    All modern compilers use bytecode, in one form or the other.
binary132 2y ago
I would take a look at BPF.
olliej 2y ago
The issue here isn’t things being “verifiably secure”. languages like js and lua run in a sandboxes environment where the only functions and operations that are permitted are those explicitly added by the host environment. Those sources languages are easily validated as correct code. [edit: I realize I should clarify something “correct” and “verifiable” here do not mean “bug free”, it means ‘cannot interfere with or violate language or environment state, memory, or other invariants’] The issue here is that the hosting environment is allowing the user/attacker to provide the bytecode that is generated from the provably correct code. That byte code is not itself verifiable statically, and is not verified at runtime (and it might not even be possible to). This is not to say that bytecode is not verifiable - Java, .NET, or even WASM (which is intentionally very low level) are verifiable bytecode environments. The issue is that a byte code must be _designed_ to be verifiable (and early Java bytecode was not due to JSR or similar iirc). Lua’s bytecode is designed for execution, and so allowing arbitrary bytecode execution is not too dissimilar from a JS engine allowing a website to provide direct access to their bytecode interpreter which would be similarly catastrophic.
- dfox 2y ago
  The issue is not really about the verifiability of the bytecode but about the interpreter checking the invariants. JVM bytecode is intentionally designed to be verifiable so that the inner loop of the interpreter does not need to care about whether the operation is executed with correctly typed operands (which in the JVM case would be highly impractical and would essentially mean that you need twice the amount of memory). You can design a system where the bytecode is not verifiable, but instead the checks are done at runtime, CPython works that way.
- worewood 2y ago
  Yeah absolutely. This exploit is akin to V8 allowing websites to supply its own bytecode (not WASM -- talking about the internal bytecode here) to it instead of Javascript.
cedws 2y ago
JIT has not been secure since Spectre and Meltdown.
bluelightning2k 2y ago
Not sure why this comment got downvoted or flagged all the way to ghost text. Seems reasonable to me even if some people disagree. (I actually disagree also but I can still respect this take, which was clearly also well intentioned and spoken.)

stavros 2y ago

How is JIT relevant here? Unless I missed something, the attack uses straight-up malicious byte code, it doesn't exploit the JIT compiler.

gjsman-1000 2y ago
JIT and Bytecode are two sides of the same coin, in my head. JIT also uses bytecode in some languages like Java.
- deleted 2y ago
  [deleted]
- fwsgonzo 2y ago
  It's much worse than that because of the complexity around JITs, behavior of hardware and speculative execution. Proper sandboxing is really hard, and I suspect that if people really want security they would disable JIT in general. Even simple ones like pcre2. Personally I have disabled Firefox's JIT (I believe it's called ion in the settings, but correct me if I misremember) for a few years now. I've never had any trouble with any websites so far. It's not instant loading, but it's close enough. ... but I don't know if I would lump bytecode with JIT. Bytecodes don't need or use RWX execute segments, for example. Lots of your favorite JITs do, for speed.
- nanidin 2y ago
  In this case someone generated malicious bytecode that the JIT compiler would not generate. I would argue JIT is dangerous because it requires dynamic memory without the NX bit set, so if you manage to smash the stack (find an exploit) you can execute arbitrary code easily (leverage the exploit). That's a different dangerous than running malicious bytecode.
  - colejohnson66 2y ago
    JITs can still function with an NX bit; You just have to halt execution to modify it.
  - axoltl 2y ago
    This doesn't generally apply but Apple has a bunch of hardening in place that means you don't just have an RWX mapping hanging around: https://developer.apple.com/documentation/browserenginekit/protecting-code-compiled-just-in-time https://developer.apple.com/documentation/browserenginekit/p... On top of that they're working on (I haven't checked in a bit) having the JIT compiler be entirely Out-Of-Process. I don't think a lot has been written about that publicly but there's a few breadcrumbs like https://developer.apple.com/documentation/kernel/oop_jit_conversion https://developer.apple.com/documentation/kernel/oop_jit_con...
- pjmlp 2y ago
  All modern compilers use bytecode, in one form or the other.

binary132 2y ago

I would take a look at BPF.

olliej 2y ago

The issue here isn’t things being “verifiably secure”. languages like js and lua run in a sandboxes environment where the only functions and operations that are permitted are those explicitly added by the host environment. Those sources languages are easily validated as correct code. [edit: I realize I should clarify something “correct” and “verifiable” here do not mean “bug free”, it means ‘cannot interfere with or violate language or environment state, memory, or other invariants’] The issue here is that the hosting environment is allowing the user/attacker to provide the bytecode that is generated from the provably correct code. That byte code is not itself verifiable statically, and is not verified at runtime (and it might not even be possible to). This is not to say that bytecode is not verifiable - Java, .NET, or even WASM (which is intentionally very low level) are verifiable bytecode environments. The issue is that a byte code must be _designed_ to be verifiable (and early Java bytecode was not due to JSR or similar iirc). Lua’s bytecode is designed for execution, and so allowing arbitrary bytecode execution is not too dissimilar from a JS engine allowing a website to provide direct access to their bytecode interpreter which would be similarly catastrophic.

dfox 2y ago
The issue is not really about the verifiability of the bytecode but about the interpreter checking the invariants. JVM bytecode is intentionally designed to be verifiable so that the inner loop of the interpreter does not need to care about whether the operation is executed with correctly typed operands (which in the JVM case would be highly impractical and would essentially mean that you need twice the amount of memory). You can design a system where the bytecode is not verifiable, but instead the checks are done at runtime, CPython works that way.
worewood 2y ago
Yeah absolutely. This exploit is akin to V8 allowing websites to supply its own bytecode (not WASM -- talking about the internal bytecode here) to it instead of Javascript.

cedws 2y ago

JIT has not been secure since Spectre and Meltdown.

bluelightning2k 2y ago

Not sure why this comment got downvoted or flagged all the way to ghost text. Seems reasonable to me even if some people disagree. (I actually disagree also but I can still respect this take, which was clearly also well intentioned and spoken.)