Live data from Hacker News

Chrome zero-day released on GitHub – fixed on V8 but still works on latest

github.com

101–110 of 160 posts

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#101
post #19

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.

Yes but unlike the browser, Node.js modules all run in a trusted environment anyway (you should never install modules you don't trust) because there are many ways that a malicious module could hijack the main process to read memory or user input so this vulnerability adds nothing.

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#103

Ah 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

#105

Ah 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

It isn't particularly safe compared to having JS disabled. RCE exploits, stealthy CSRFs, etc. that work with JS disabled are exceedingly rare compared their JS counterparts.

This is quantifiable, not "alarmist".

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#106

Ah 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

I.e. disabling JS is all fine, but in the end it is just 'safer' and whether or not that is already 'particularily safe' is a rather subjective thing.

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#107
post #20

Earlier 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\…

(Disclaimer: I know very little about Windows, I Googled a bunch of stuff so the details might be wrong. Disassembly, if you want to follow along: http://shell-storm.org/online/Online-Assembler-and-Disassemb...)

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

#108
post #99

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

The code is somewhat different, although you may have recognized that most JS engine exploits look the same once basic primitives are constructed.

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#109
post #50

Earlier 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! :)

Having worked in other spaces ensuring W^X on the basis that there is no good reason for it, the only exception is usually "because I need to code generate".

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

#110

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

The parent was talking about how the process the WASM runtime is in is sandboxed. I could be wrong, but I don't think flash did this. I think the sandbox was more of just some limitations on the APIs you were provided.
Post reply on HN