Earlier quoted context omitted.
Not really. While the bug technically exists on Node, generally people do not use Node to run untrusted JS/Wasm code. Node isn't designed to be a sandbox.
People install random Node modules every day.
Chrome zero-day released on GitHub – fixed on V8 but still works on latest
101–110 of 160 posts
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#102Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS.
This absolutely made my day. HN truly is a source of nonstop entertainment.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#103Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#104Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#105Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.
"Particularly safe" is a bit alarmist, one could make the same argument about literally anything that connects to a public network isn't particularly safe
This is quantifiable, not "alarmist".
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#106Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.
"Particularly safe" is a bit alarmist, one could make the same argument about literally anything that connects to a public network isn't particularly safe
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#107Earlier quoted context omitted.
I converted it to binary with a pack("L", ...) loop and loaded it in Ghidra as a raw x86_64 binary. I don't fully understand it, but i think it's searching the address space for some kind of function entry point and then calling it with "calc.exe". So probably the standard PoC shellcode.
For anyone else wanting to analyze this: echo '\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48 \x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48 \x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9 \x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b \x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\…
The program program is shellcode, so the first thing it does is set itself up with the state it needs. This includes clearing the direction flag, aligning the stack to 16 bytes, and figuring out where it is in memory (the call to 0xca both sticks an address on the stack and avoids some code described below). It then calls into a little subroutine (at 0xa) to read through the PEB → LoaderData → InMemoryOrderModuleList. The first entry is the entry for the main binary, from which it grabs the "FullDllName", does some sort of trivial hash on it, and compares it to a known value (presumably a check to see that it's running in a sane environment?) Then it largely skips the next entry (ntdll.dll) and goes to kernel32.dll, where it looks into the exports table to find what is presumably CreateProcessA (this is done using a similar hashing scheme, so the string is not directly present in the shellcode). There's a "calc.exe" string at the end of the code (perhaps you can spot it) and with that it has enough to pop a calc.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#108Earlier quoted context omitted.
Couldn't find the PR you're referring to, unless it was this one https://github.com/rapid7/metasploit-framework/pull/15007 which was added by the same author as the OP, but looks like a different exploit as far as I can tell?
I believe it's the same exploit, check out this reference here [0], and you should see the JS snippet https://github.com/rapid7/metasploit-framework/pull/15007/fi...
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#109Earlier quoted context omitted.
Aaaaaand It's not the first time WASM seen in [0] wild. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=835887
Yeah. And it's not even bugs in the Wasm engine that are the problem; the RWX memory for Wasm JIT code makes all other bugs into potential RCE bugs. It must be banished! :)
How do you even go about getting rid of WRX in a JIT? Do you generate and then remove W?
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#110Earlier quoted context omitted.
Not at all. Flash was pretty much built insecure, WebAssembly runs in a sandbox by default (and this exploit does not break out of it).
Kind of a dishonest characterization - Flash was sandboxed too. WASM is simply easier to sandbox and has additional constraints that make it easier to keep code from trying to break out.