Anything can be exploited. Normal compilers too, especially if you're running code someone else supplied. But I wouldn't say there are any especially severe vulnerabilities unique to JITing.
In the long run, I don't see how this is much more useful than JIT-ed Java bytecode. In both cases, you're relying on a heavyweight browser plugin to execute code. Nativeclient runs direct x86 code, after scrubbing it down to a subset of x86. JIT Java takes a bytecode stream and generates a safe x86 instruction stream.
In both cases, the plugin has to provide a system call interface to do anything "interesting" with the client. That system call interface is either too trivial to enable interesting applications, or so complicated that it, not the instruction analyzer, is going to be the primary attack surface of the plugin.
If you take Java bytecode to be the attack surface, it is probably less likely than that a complex, microcode-based CPU instruction set contains a back door because it is hard to smuggle a multi-instruction side effect into an open source bytecode interpreter. Other attacks like an undocumented jni call are also difficult to conceal. That leaves things like network libraries, and most of those are an interface to protocols, leaving not much room for shenanigans, IF the source is available and build-able.
If the JIT engine in Nitro had a JIT Spray vulnerability and Nitro was a shared library could it allow an attacker to inject code into other applications that also use Nitro?
Not that shared libraries are a problem, just that JIT'ing introduces a new attack vector that is hard to secure.
The interesting part is that most of the bytecode-level security problems in the Java world come from the JIT compilation, where it stops being bytecode again.
But yes, bytecode isn't magic pixi dust that makes things secure; it can be a tool to make things more secure though, with effort.
But the feature the exploit takes advantage of isn't just in time compilation, it is compilation! An ahead of time java compiler would have suffered from the exact same problem. In fact, any language compiling to machine code would be just as vulnerable.
I think it's worth noting that what you're referring to - the JVM escapes - are exploited under a completely different threat model where the attacker already has remote code execution.
In this model the attacker already can execute code on the victim's host, but the VM attempts to limit what the attacker can do via restricted APIs. It's just a completely different threat.
This is a strategy, but it typically falls apart against clever attackers who are targeting you specifically. Hackers have been performing return-to-libc attacks forever where they don't actually get to write any code at all, just sequence code that already exists in your binary.
Java also tried this in a slightly more rigorous manner with the SecurityManager and that just ended up being a botch.
It's not impossible there'd be something interesting there... but Java is a more likely attack vector simply because part of its normal functionality is to execute code downloaded from the internet.
Before this recent patch, that code would be executed without even prompting the user.
Sure, there's a sandbox, but (as we know) sometimes a sandbox has cracks, particularly when the runtime is designed to let code to only enforce the sandbox for some code it runs, not all. (Compare to JavaScript execution, which also runs downloaded code without prompting, but JS in the browser is always in the sandbox -- there are things it simply can't do, vs. Java's "this is do-able but not for you".
Cool. Was this in Java 6? (circa 2010 - I couldn't find a way to do it back then). Also, why would you need (even on JDK7 or JDK8) unsafe access to jit a memory mapped access inline? Is there an underlying philosophical reason, or is it just that they never got to do it?
Interesting, thank you for that analysis. From what I understand, the RCE exploit really needs two things to work: 1) The interpretation of the JNDI reference by log4j, and 2) The 'auto-execute loaded classes' (which I don't quite understand).
Is there any kind of low-level flag you can pass to Java or your environment to completely disable JNDI? I recall that there is a flag you can pass to log4j, but I can't see any reason why I would ever use JNDI anywhere in Java.
Also, do you have any additional insights on how exactly the mechanism for 2) works? From what I understand, this is a feature of Java itself?
Code execution in a JVM is typically equivalent to code execution on the host where it's running.
Because this vulnerability affects both clients and servers, it sounds like a good way for someone to write a worm that ends up creating a giant botnet by spreading from servers to clients and vice-versa.
What could an attacker do if they were able to trick the JIT into emitting evil native code?
reply