What a one line change did to the Chrome sandbox

Or, you can slap a Service Control Policy on the whole account and then boom, nobody can do Whichever Bad Thing that you're worried about Today.

The former approach requires me to reload the entire graph of dependencies and assumptions into my head whenever I want to make a change or ask my mental model of it a question. The latter approach allows nearly-reflexive answers.

Bear in mind, browser security comes from many levels. A sandbox escape first requires that someone has gotten malicious code to execute in your browser. And the first line of defense is blocking a lot of extraneous and harmful code from running in the first place.

But the takeaway from this post is more that perfect safety is difficult / impossible to achieve.

There are these security token objects that are used to keep track of what a process can and can't do. (Think of them as collections of capabilities.)

The design of the system is that you can create a less powerful child copy of your security token (dropping capabilities), and assign this token to a child process when you create that child. A process is free to change its security token to be any child of its current token or any sibling of its current token (plus a few other restrictions).

Someone screwed up a change to the Windows 10 kernel such that when the browser creates a restricted child of its token, the less powerful token is actually marked as a sibling of the browser's token, which is itself a sibling of many other tokens in the system. This means that the token the browser uses to create its child sandbox process has many unrestricted sibling tokens.

The rest of the exploit involves figuring out how to get a handle to a security tokens that a few other processes make publicly available (sounds very strange to me) and which aren't as restrictive as the security token used to create the sandbox process.

If the sandbox's token were (correctly) a child of the main browser process's token, then these other tokens found wouldn't be siblings of the sandbox's token, and the sandbox process couldn't switch to using these security tokens. However, because of the screwed up family tree of these tokens, the sandbox is free to switch to these other security tokens.

It is so complicated that even the people maintaining it don’t understand it, and they accidentally added a privilege escalation path.

The author uses that to use a Chrome sandbox bug to escape from the sandbox.

The real WTF is the complexity and obscurity of the security primitives being exported from the kernel. Arguably, all major operating systems have the same issue, and are getting worse over time — I doubt anyone understands all of the layers of privilege checking mechanisms that have been bolted on to Linux, Windows or Mac OS over the years.

Then it's a long detailed post about how you can exploit the bug, while missing some critical parts so you actually can't exploit it for real.

The problem with dealing with Windows and by extension Microsoft is there's no way of inspecting what they've changed from version to version other than by RE or having test cases. However, we try and avoid writing unit tests for behaviors Microsoft's responsible for, but of course in many cases MS don't have those tests either so these things fall through the cracks.

I think it’s a great model, but it breaks down when the new version is a feature/usability regression vs the old version.

Once that started happening more often than not, the “aas” models came out, where the vendors started force upgrading users instead of trying to compete with version N-1.

This is worse for the users, but better for deadline-focused middle management, so it’s become incredibly popular.