Exploiting the Math.expm1 typing bug in V8
1–10 of 47 posts
Re: Exploiting the Math.expm1 typing bug in V8
#2Interesting how at the end, after acquiring out-of-bounds write access, that it was easiest to leverage the WebAssembly infrastructure to execute code than to build a ROP chain.
Apparently WebAssembly heap memory storing generated code is not write protected at all. I guess whatever architecture they have for managing typed memory chunks doesn't make it sufficiently easy to manipulate protection bits dynamically, and the WebAssembly folks were content to leave compiled WebAssembly chunks are RWX.
It's unfortunate that this thread hasn't been upvoted. It really drives home the futility of expecting something as complex as V8 to ever be safe enough to sandbox arbitrary code. And it has little to do with the language of the implementation--the same engine re-written in Rust would have been just as susceptible to the two exploits.
I guess it's just too inconvenient to accept reality. I'm still surprised that Cloudflare and AWS have actually convinced themselves they can make such architectures secure[1]. Less shocked that everybody is else is so credulous.
Though, I am shocked that Netflix is so credulous. A recent blog post described how they use AWS Lambda functions to manage their CA private key. But, again, because of how limited KMS is I guess it's too inconvenient to not trust Lambda. KMS really should support asymmetric key operations; it's ridiculous it's still not supported. I guess AWS's KMS "cloud HSM" solution just wouldn't scale (in terms of CPU) if people could do that.
[1] Absolute security is impossible, but as complex as this exploit was it's obviously still far too trivial. It's a totally unwarranted and unreasonable expectation that bad actors are incapable of reading (if not manipulate) co-hosted Lambda or Cloudflare Worker projects. Writing a non-JIT'd engine with a simplified memory architecture is not only feasible, it would be an obvious candidate for formal verification. But the demands for performance are just too strong and so, as always, security takes a back-seat to performance and speed-to-market.
Re: Exploiting the Math.expm1 typing bug in V8
#3The fundamental bug here is really slick. The static analyzer in the JIT incorrectly believes
Math.expm1(x)
Object.is(Math.expm(x), -0)
array[Object.is(Math.expm(x), -0) * INDEX]
But it's not quite that simple, because another consequence of of the static analyzer's misperception is that
Object.is(Math.expm(x), -0) * INDEX
But constant folding is an optimization, not a security boundary, and easily "defeated": replace the -0 constant in that expression with an object reference:
obj = { o: -0 }
Object.is(Math.expm(x), obj.o)
The end result of the bug is a sort of "black magic zero/one chimera" that, mixed into an expression, tricks the JIT into stripping bounds checks. It's an extremely cool exploit primitive. It's doubly cool because if you don't have Andrea's writeup or a really nuanced understanding of v8 internals, you could stare at that exploit for eternity and never understand why it works.
Re: Exploiting the Math.expm1 typing bug in V8
#4Interesting how at the end, after acquiring out-of-bounds write access, that it was easiest to leverage the WebAssembly infrastructure to execute code than to build a ROP chain. Apparently WebAssembly heap memory storing generated code is not write protected at all . I guess whatever architecture they have for managing typed memory chunks doesn't make it sufficiently easy to manipulate protection bits dynamically, an…
I don't know what you mean by AWS? They don't rely on V8 for isolation, they use KVM among many other layers.
Re: Exploiting the Math.expm1 typing bug in V8
#5The fundamental bug here is really slick. The static analyzer in the JIT incorrectly believes Math.expm1(x) can't return -0. But if x is -0, it can. That, in turn, means it believes Object.is(Math.expm(x), -0) must always be false. But if x is -0, it's true, not false. That, in turn, means that the JIT believes array[Object.is(Math.expm(x), -0) * INDEX] must be array[0], no matter what INDEX is. But if x is -0, it'll…
Hmmm! Wonder how hard it might be to make a build of v8 available that replaces assumes with asserts, and perhaps replaces code believed to be unreachable with assert(false)? If it's something like LLVM IR, where assume is just an intrinsic taking a Boolean expression, would seem relatively straightforwards- would probably need to run before every pass in the optimizer...but should be doable.
Then, take your preferred JS fuzzer...
Re: Exploiting the Math.expm1 typing bug in V8
#6I would love to know how v8 is properly secured in the instance of things like Cloudflares. Im curious to know if this goes through v8 isolates, and if something like lxd containment would be a viable alternative.
Re: Exploiting the Math.expm1 typing bug in V8
#7Interesting how at the end, after acquiring out-of-bounds write access, that it was easiest to leverage the WebAssembly infrastructure to execute code than to build a ROP chain. Apparently WebAssembly heap memory storing generated code is not write protected at all . I guess whatever architecture they have for managing typed memory chunks doesn't make it sufficiently easy to manipulate protection bits dynamically, an…
I don't know what you mean by AWS? They don't rely on V8 for isolation, they use KVM among many other layers.
I guess I was wrong. Looks like AWS is already using Firecracker for AWS Lambda: https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
Although it would be nice for AWS to explicitly say that there's one customer per hosted Lambda environment, and distinct from language-level or process-based sandboxing. From the article above you have to assume that because v1 of Lambda put one customer per EC2 instance as an expediency that it remains the case.
Nonetheless, regarding the Netflix case, nobody should be hosting long-term CA keys in Lambda or any co-hosted virtualized environment framework. These days few reputable companies except maybe Intel even bother arguing that secret keys are safe from side-channel attacks in such environments. The evidence is just too overwhelming, even for the self-deluding "if it's too complex for me to understand then it must be impossible" crowd.
Re: Exploiting the Math.expm1 typing bug in V8
#8Interesting how at the end, after acquiring out-of-bounds write access, that it was easiest to leverage the WebAssembly infrastructure to execute code than to build a ROP chain. Apparently WebAssembly heap memory storing generated code is not write protected at all . I guess whatever architecture they have for managing typed memory chunks doesn't make it sufficiently easy to manipulate protection bits dynamically, an…
Hi, TLM of the WebAssembly runtime in V8 here.
TLDR: it's asm.js's fault. And yes, complexity.
The reason that WebAssembly JIT code memory is still RMW (for now) is actually really unfortunate. As you might know, V8's JIT code memory for JS is only writable when the application is quiesced (i.e. JS is not running) and the JIT is either finishing a function or the garbage collector is moving JITted code. It's read-execute otherwise. It's never both writable and executable at the same time. We generally refer to this as WX protection (i.e. writeable/executable exclusive).
In the case of WebAssembly, it's asm.js that's the real culprit here. Internally in V8, asm.js code is translated to WebAssembly by a very quick custom-built parser that validates asm.js's type system while parsing and emits WebAssembly bytecode along the way. The WebAssembly bytecode is then fed to the WebAssembly engine for compilation.
Well...not so fast. In order to meet our performance goals for fast asm.js validation and startup, the WebAssembly engine does not do up-front compilation of Wasm code coming from asm.js. Instead, it does on-demand compilation of asm.js code, compiling the Wasm bytecode corresponding to each asm.js function upon first execution. We call this "lazy compilation".
We originally shipped lazy compilation cooperating with the WX mechanism executable for JS code. That is, upon every (lazy) compilation of asm.js code, we'd flip the permission bits on the code space in order to write in the little bit of machine code generated for each function. Problem is, that permission flip is expensive--like really expensive. So expensive that we had to unship WX protection because it made asm.js code unusably slow.
We're working on fixing this, as we are keenly aware of the risk exposure here.
Re: Exploiting the Math.expm1 typing bug in V8
#9Interesting how at the end, after acquiring out-of-bounds write access, that it was easiest to leverage the WebAssembly infrastructure to execute code than to build a ROP chain. Apparently WebAssembly heap memory storing generated code is not write protected at all . I guess whatever architecture they have for managing typed memory chunks doesn't make it sufficiently easy to manipulate protection bits dynamically, an…
Hi, TLM of the WebAssembly runtime in V8 here. TLDR: it's asm.js's fault. And yes, complexity. The reason that WebAssembly JIT code memory is still RMW (for now) is actually really unfortunate. As you might know, V8's JIT code memory for JS is only writable when the application is quiesced (i.e. JS is not running) and the JIT is either finishing a function or the garbage collector is moving JITted code. It's read-exe…
> TLDR: it's asm.js's fault.
> In order to meet our performance goals for fast asm.js validation and startup, the WebAssembly engine does not do up-front compilation of Wasm code coming from asm.js.
It sounds like the fault is how you reached your performance goals rather than asm.js itself.
Re: Exploiting the Math.expm1 typing bug in V8
#10Interesting how at the end, after acquiring out-of-bounds write access, that it was easiest to leverage the WebAssembly infrastructure to execute code than to build a ROP chain. Apparently WebAssembly heap memory storing generated code is not write protected at all . I guess whatever architecture they have for managing typed memory chunks doesn't make it sufficiently easy to manipulate protection bits dynamically, an…
Hi, TLM of the WebAssembly runtime in V8 here. TLDR: it's asm.js's fault. And yes, complexity. The reason that WebAssembly JIT code memory is still RMW (for now) is actually really unfortunate. As you might know, V8's JIT code memory for JS is only writable when the application is quiesced (i.e. JS is not running) and the JIT is either finishing a function or the garbage collector is moving JITted code. It's read-exe…
This is super-interesting back story, thanks for taking the time to share it.