Hacker News Reader

Comment by Retr0id | Hacker News Reader

First you compromise the renderer process via e.g. a bug in the JS engine. But even if you have native code execution in the context of the renderer process, you're still in a sandbox.

The bug in the OP is for the second stage - breaking out of the sandbox.

The referenced `patch.diff` is basically for simulating a compromised renderer.

View on HN

Ah, so it's like a two stage rocket, this turns a small exploit into a humongous one?

Yes. Chrome has multi-process architecture, with renderer processes running in a sandbox. They are the ones that deal with untrusted stuff coming from the Internet and so it is safe to assume that they can be compromised (relatively) easily. The puppet master for all those processes is the browser process, and it is Really Bad if you could exploit it. The described bug presumably does it (note how "sandbox escape" was used in one of the comments), but I'm not competent enough to say exactly how. ;)

Edit: just wanted to riff on your analogy. It is relatively simple to crash/shoot down a rocket, but this exploit gets into the control room and could allow the attacker to see where all other rockets are going & maybe redirect/crash them.

Or an escape room, indeed.

Once you're thinking along the lines of "Alright, if I had some order of flags, I could solve that thing over there. If I knew some kind of weights, I could solve that over there. And if I could find a light bulb I could deal with that over there", you're kinda in the mindset of finding an exploitation chain.

It's just that in the security world, it's more about bad memory accesses, confusing programs into doing the right actions with wrong files, file permissions being weird and such.

Sorta, although I wouldn't necessarily call the first exploit "small", it's at least equally important in the overall chain. "Chain" being the more usual metaphor, for this reason.

This sounds like a good way to think about exploit chains (though I'm not an expert)

> The referenced `patch.diff` is basically for simulating a compromised renderer.

The patch.diff part is hard to understand. Surely if you have a compromised renderer, you have effectively full access to the machine already?

The main browser process treats the renderer as untrustworthy/potentially hostile. A compromised renderer is in the threat model.

Modern browsers have multiple processes with different sandbox policies. The renderer process handles untrusted web content and is heavily sandboxed. The browser process does all the other stuff required to interact with your computer (and is generally much less isolated).

No, because of the sandbox.

Reply on news.ycombinator.com