Is there somewhere explaining this bug in terms understandable for someone not dabbling in this?
I don't really understand how this works to "escape the sandbox". Normally it's like a website you visit that get access it shouldn't have. But this talk about renderers and native apis make it seem like it's stuff another process on the computer would do?
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.
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.
It looks like the bug is that there is a way for the renderer (sandboxed) process to trigger the browser (unsandboxed) process to duplicate an arbitrary windows kernel object handle. When you duplicate a handle, you can restrict access, or allow the duplicate to have full access as the original - unfortunately this one is duplicating preserving all the capabilities/access of the original handle.
Now for the POC exploit - it so happens that 0x108 is typically a thread handle for a thread in the browser process. What can you do with a thread handle? You can pause execution of that thread, set its register values (including instruction pointer), resume execution.
If kernel32.dll loads at the same address in each process, we can find some set of instructions in it that write a register's value to another register's address. If we set the instruction pointer to that instruction, we've unlocked the ability to write arbitrary memory in the unsandboxed process.
Finally, we can call other Windows APIs (by finding the address of the function to call and setting instruction pointer to it)- in the POC, they write "calc.exe" to a string, then call the system api to launch calculator.