Hacker News new | ask | show | jobs
by heljara 1899 days ago
Broadly speaking, the wasm stuff is only there as a method of getting the browser to execute shellcode, its a pretty standard lump of code for turning a memory bug into code execution in v8. What this shellcode does is open calculator when the browser's sandbox is disabled (`--no-sandbox`). In general in v8 exploitation, once you've reached a point where you can read and write arbitrary memory, you find that v8 will only create either RW or RX pages for you when the JIT compilation happens. WASM is a neat little trick for getting a handle to a RWX page.

At first glance to me, the core bug is actually in abusing an array enough to get an unsigned int into a function that expects them all to be signed, causing an off-by-one error and leveraging that into a memory leak (to get the pointer to a FixedArray for floats and a pointer to a FixedArray of objects) and then replacing one with another to create a type confusion and read/write arbitrary memory through that. r4j will probably correct me on the subtlety here though!

Source: extremely similar to HackTheBox RopeTwo, which I spent more time than I am prepared to admit solving.

Disclaimer: am noob at v8 exploitation, but have done enough of it to know some of the tricks.

See also, an article that helped me previously, much of the code is similar (eg: the WASM stuff, the addrof() and fakeobj() methods): https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/

3 comments

> In general in v8 exploitation, once you've reached a point where you can read and write arbitrary memory, you find that v8 will only create either RW or RX pages for you when the JIT compilation happens. WASM is a neat little trick for getting a handle to a RWX page.

It's not a neat trick, but a grave problem of WASM model.

WASM memory (in)security will be a big problem until all of memory security tricks from native code will be migrated to WASM world, and then there will be not much use of WASM anymore.

You understand that having W^X protections on any JIT area is fairly useless without a strong CFI model in place right? Any attacker could easily execute a ROP/JOP chain to switch JIT protections to RX or even more simply allocate an RWX area where the shellcode can be copied and executed.
Yes, and this is the part of the problem of the general direction of JS ecosystem development.

JS promoters want so hard for JS to subplant other major languages, but not noticing themselves ignoring the decades long other path major languages took on robustness, and security.

Wanna play htb together at some point?

My email is in my profile.

How the heck people discover these kind of obscure bugs?