Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

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.

View on HN

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.

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.

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.

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

JIT and Bytecode are two sides of the same coin, in my head. JIT also uses bytecode in some languages like Java.

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.

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.

JITs can still function with an NX bit; You just have to halt execution to modify it.

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/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_con...

All modern compilers use bytecode, in one form or the other.

JIT has not been secure since Spectre and Meltdown.

I would take a look at BPF.

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.)

Reply on news.ycombinator.com