Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

141–150 of 160 posts

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

#141

Post by titzer »

rkangel wrote: post #109
titzer wrote: post #50

Earlier quoted context omitted.

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?

In V8, JITed JavaScript code is never writable and executable at the same time; the JIT writes into a buffer, then quiesces JS execution, then copies/flips permissions, then starts running JS code again.

In the Wasm engine inside of V8, the code is writable and executable at the same time because the JIT uses multiple concurrent threads in the background during execution and incrementally commits new JITed code as it is finished. (And, funnily enough, this performance optimization is mostly for asm.js code, which is verified and internally translated to Wasm, to be compiled and executed by the Wasm engine).

The long-term holy grail is to move the JIT compiler entirely to another process, so only that process has write permissions, and the renderer process (where Wasm and JS execute) has only R and execute permissions, and they used shared memory underneath.

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

#142

Post by kentonv »

amelius wrote: post #112
bassdropvroom wrote: post #43

Earlier quoted context omitted.

> Within an hour of V8 pushing the fix for this, our build automation alerted me that it had picked up the patch and built a new release of the Workers Runtime for us. I clicked a button to start rolling it out. After quick one-click approvals from EM and SRE, the release went to canary. After running there for a short time to verify no problems, I clicked to roll it out world-wide, which is in progress now. It will…

My guess is that the main feature which enables this kind of automation is that they can take down any node without consequences. So they can just install an update on all the machines, and then reboot/restart the software on the machines sequentially. If you have implemented redundancy correctly, then software updating becomes simple.

We actually update each machine while it is serving live traffic, with no downtime.

We start a new instance of the server, warm it up (pre-load popular Workers), then move all new requests over to the new instance, while allowing the old instance to complete any requests that are in-flight.

Fewer moving parts makes it really easy to push an update at any time. :)

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

#143

Post by wizzwizz4 »

baybal2 wrote: post #139
wizzwizz4 wrote: post #136

Earlier quoted context omitted.

That isn't sufficient. You know why? exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*") Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.

1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse

1. This one is.

2. Won't help.

3. Simply reverse, or make use of, the mangling.

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

#144

Post by baybal2 »

wizzwizz4 wrote: post #143
baybal2 wrote: post #139

Earlier quoted context omitted.

1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse

1. This one is. 2. Won't help. 3. Simply reverse, or make use of, the mangling.

> 1. This one is.

I can check browser memory with a profiler and see if this page is marked as executable. It would not be.

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

#145

Post by sfink »

baybal2 wrote: post #139
wizzwizz4 wrote: post #136

Earlier quoted context omitted.

That isn't sufficient. You know why? exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*") Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.

1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse

ArrayBuffers aren't meant to be executable code either.

JS strings are not UTF-16, they are 16-bit chunks of (potentially) nonsense, and enforcing valid UTF-16 would break quite a few existing uses. For example, anything that stores encrypted data in a string. Which "shouldn't" be done, that should be a Uint8Array, but existing APIs basically force you to do it. And there's such a thing as backwards compatibility.

Your 3rd point is much more feasible. I doubt any "real" mangling would be good enough from a performance standpoint while still being too difficult for attackers to use. But I could imagine eg breaking any invalid UTF-16/UTF-8 string up into separate rope nodes, maybe even ensuring the nodes don't get allocated too close to each other and/or injecting disrupting hardcoded bytes in between them. (I work on SpiderMonkey, the Firefox JS engine, and we do at least make sure to allocate string data in a separate part of the heap from everything else.)

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

#146

Post by baybal2 »

sfink wrote: post #145
baybal2 wrote: post #139

Earlier quoted context omitted.

1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse

ArrayBuffers aren't meant to be executable code either. JS strings are not UTF-16, they are 16-bit chunks of (potentially) nonsense, and enforcing valid UTF-16 would break quite a few existing uses. For example, anything that stores encrypted data in a string. Which "shouldn't" be done, that should be a Uint8Array, but existing APIs basically force you to do it. And there's such a thing as backwards compatibility. Yo…

Valid UTF16 is already being sporadically enforced.

People who hack JS to store arbitrary data in strings are already fighting a loosing battle, and I see no point to help them.

But my point is that we have moved from the JS as a scripting language which did not allow for arbitrary binary data, to one which did without much though over that.

Half of existing problems with zero click, zero days, and zero browse exploits running in the wild, and Chrome becoming the ActiveX 2.0 is that.

There is really no reason for a web browser to do computing on the web, and thus no need for binary manipulations in Javascript on the web.

I'm not saying to axe it from JS, but JS may limit the the browser use case by a limited set of JS standard.

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

#147

Post by kmfpl »

baybal2 wrote: post #119
heljara wrote: post #93

Earlier quoted context omitted.

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…

> 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 nati…

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.

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

#148

Post by kmfpl »

People in this thread seem very confused about a lot of stuff so I’m going to try and make some clarifications:

1) This is an RCE, so what it does is achieving code execution in the browser, i.e. it can run arbitrary code from the attacker, it’s literally like running a compiled program inside the target’s browser. This doesn’t bypass Chrome’s sandbox, so a lot of OS operations are not reachable from within the browser (for example, a lot of syscalls can’t be called).

This is the first step in an exploit chain, the second one would be a sandbox escape to expand the attack surface and do nasty stuff, or maybe a kernel exploit to achieve even higher privileges (such as root)

2) WASM being RWX is really not a security flaw. W^X protections in modern times (even in JIT-like memory mappings) makes sense only when coupled with a strong CFI (control flow integrity) model, which basically tries to mitigate code reuse attacks (such as JOP or ROP). Without this kind of protection, which needs to be a system-wide effort as iOS has shown, W^X makes literally zero sense, since any attacker can easily bypass it by executing an incredibly small JOP/ROP chain that changes memory protections in the target area to run the shellcode, or can even mmap RWX memory directly.

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

#149

Post by baybal2 »

kmfpl wrote: post #147
baybal2 wrote: post #119

Earlier quoted context omitted.

> 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 nati…

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.

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

#150

Post by danielyaa5 »

saagarjha wrote: post #79
danielyaa5 wrote: post #30

Im just curious on thoughts about sharing these on twitter. Shouldn't they be shared directly with Google. Since its web people can create exploits pretty quickly.

Google knows about (and has patched) the bug already. The exploit code has been shared wholesale.

are these patches in place without user updates?
Post reply on HN