> Thankfully the exploit is highly dependent on a specific asm routine so exploiting it from JS or WASM in a browser should be extremely difficult. Otherwise a nefarious tab left open for hours in the background could exfiltrate without an issue.
At least one commentor here claims to be able to reproduce this with javascript: https://news.ycombinator.com/item?id=36849767 .
A very bold claim with zero evidence.
What about it is very bold? The instruction sequence mentioned seems pretty reasonable and not at all out of the question for a JavaScript JIT to generate.
It should be possible to patch this from the browser side as well.
I tried on my zen 2 box, and the same things works even when the exploit is run in a KVM.
How do you build the POC? I get "No such file or directory" and error 127 on Ubuntu.
Re:Zenbleed
by eric__cartman on Monday July 24, 2023 @04:12PM
(#36853578)
I had to run make on the uncompressed folder. Perhaps the build-essential package doesn't come with NASM in Ubuntu? I'll need a bit more info on the error if you want me to try and help you :)
After extracting the POC and installing build-essential, I still get this:
nasm -O0 -felf64 -o zenleak.o zenleak.asm
make: nasm: No such file or directory
make: ** [Makefile:11: zenleak.o] Error 127
Re:Zenbleed
by eric__cartman on Monday July 24, 2023 @04:29PM
(#36853753)
Install the nasm package. It's probably not included in build-essencial.
Thank you. I guess I should've read the error better, but I thought nasm was the thing complaining.
The parent commenter seems to have figured this out, but to clarify a bit for posterity: build-essential does not come with nasm on Ubuntu (or upstream Debian, AFAICT). It has to be installed separately for the Zenbleed PoC to compile (if not already installed).
> Thankfully the exploit is highly dependent on a specific asm routine so exploiting it from JS or WASM in a browser should be extremely difficult.
I assume that once/if a method is found it will be applicable broadly though. At the same time, hopefully software patches in V8 and SpiderMonkey will be able to mitigate this further and sooner.
But a JS exploit would require some way to exfiltrate data and presumably doing that would be quite difficult to hide entirely.
Thankfully the exploit is highly dependent on a specific asm routine so exploiting it from JS or WASM in a browser should be extremely difficult. Otherwise a nefarious tab left open for hours in the background could exfiltrate without an issue.
I'm eagerly waiting for Fedora maintainers to push the new microcode so the kernel can update it during the boot process.