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.
Windows has an incredibly complicated set of token based authentication mechanisms that Chrome relies on. They interact with each other in non-trivial ways and were introduced piecemeal over a few decades.
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.
From my understanding, someone at Microsoft changed a line of code related to some access control in windows and it broke some access controls. The author thinks the change was a mistake, perhaps code cleaning from a Microsoft employee.
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.
Well, thanks for not publishing a full working POC.
About the critical missing part, I was thinking about this :
> Let’s focus on escaping the GPU process sandbox. As I don’t have a GPU RCE to hand I’ll just inject a DLL into the process to run the escape.
From what I understand, a GPU RCE would allow escaping the sandbox from remote while injecting the DLL requires a good control on the machine. But your post was not about a GPU RCE so it totally makes sense to not do it. I may be very wrong because I am not a security expert, I only read MISC (a French magazine about security) on the beach.
Ah I see what you mean :-) We'll yes I left out the RCE as I'm not an RCE person, I look for sandbox escapes and privilege escalation bugs. The injection of a DLL is to test rather than as an exploit.
I was originally going to write about using the same bug in Firefox. The default content sandbox in FF is basically the same as Chrome GPU, so any untrusted HTML/JS coming from the web could exploit RCE to get into a sandboxed process where this bug could be used. I decided considering they're using the Chromium sandbox code it really should be about Chrome.
That said, this sandbox escape isn't being presented for practical reasons. It'd be incredibly noisy to do and potentially unreliable due to the various mitigations you have to circumvent. Any "real" attacker would likely use an exploit in the kernel's WIN32K component which is accessible from GPU.
The vulnerability is in Windows 10. Windows 10 has been fixed. It's not clear in the article what other mitigations are in place in Firefox to make exploitation more difficult.
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.