FF Sandbox Escape(googleprojectzero.blogspot.com)
googleprojectzero.blogspot.com
FF Sandbox Escape
https://googleprojectzero.blogspot.com/2020/06/ff-sandbox-escape-cve-2020-12388.html?m=1
25 comments
Non-mobile link: https://googleprojectzero.blogspot.com/2020/06/ff-sandbox-es...
Off topic, does Firefox depend on Chromium code?
> As I’m a Chromium committer as well as an owner of the Windows sandbox I realized I might be better placed to fix this than Mozilla who relied on our code.
> As I’m a Chromium committer as well as an owner of the Windows sandbox I realized I might be better placed to fix this than Mozilla who relied on our code.
Firefox uses some of the chromium code/libraries for the sandboxing on Windows.
https://wiki.mozilla.org/Security/Sandbox/Specifics
https://wiki.mozilla.org/Security/Sandbox/Specifics
I thought one of the main point of Firefox would be to not do this :D
Chromium contains a really solid implementation of OS process sandboxing, which is rather secondary to the bits of building a web browser that we need competition on. It could very reasonably be spun out into its own project, but that takes time and effort so it stays part of Chromium.
I know they use the v8 regex engine: https://hacks.mozilla.org/2020/06/a-new-regexp-engine-in-spi...
[deleted]
My one run-in with this has been that Firefox and Chromium both use libwebrtc, which is managed by the Chromium project as far as I can tell.
It looks like this is not an actual exploit, but a hole in the sandbox that first requires injecting custom code into the process?
I guess it depends on how you define "exploit." I'd personally consider bypassing the sandbox an exploit, even though it's not a full chain.
It’s an proof of concept exploit for a vulnerability in the sandbox used by FF which is a security boundary to reduce the impact of RCE. The reason for the injection is I don’t just have a working RCE lying around (we get them fixed) and using one would add additional complications and obfuscate the bug when reporting. The purpose of a proof of concept is to demonstrate impact so that it can be fixed.
All the big browser attacks require exploit chains, and this is a component for creating an exploit chain. The best exploit chains can go all the way from a web page's JS to complete root access (this was achieved on Chromebooks at one point in the last couple years, using webassembly as one of the hops in the chain)
In the end the sandbox is there to provide some limited security even in presence of other vulnerabilities.
So I would say it's a security critical bug a sandbox escape and a building blog for an exploit but not a exploit by itself.
Anyway it's sill a security vulnerability.
So I would say it's a security critical bug a sandbox escape and a building blog for an exploit but not a exploit by itself.
Anyway it's sill a security vulnerability.
"Sandbox Escape" sounded like something fun but alas
Off topic but does project zero ever publish vulnerabilities on google products? More and more it seems like they mostly target google's competitors (Firefox, iOS, etc)
Here's the post I put together when this same question was asked 6 days ago. All counts are rough numbers.
Project zero posts:
Google: 24
Apple: 28
Microsoft: 36
I was curious, so I poked around the project zero bug tracker to try to find ground truth about their bug reporting: https://bugs.chromium.org/p/project-zero/issues/list For all issues, including closed:
product=Android returns 81 results
product=iOS returns 58
vendor=Apple returns 380
vendor=Google returns 145 (bugs in Samsung's Android kernel,etc. are tracked separately)
vendor=Linux return 54
To be fair, a huge number of things make this not an even comparison, including the underlying bug rate, different products and downstream Android vendors being tracked separately. Also, # bugs found != which ones they choose to write about.
Project zero posts:
Google: 24
Apple: 28
Microsoft: 36
I was curious, so I poked around the project zero bug tracker to try to find ground truth about their bug reporting: https://bugs.chromium.org/p/project-zero/issues/list For all issues, including closed:
product=Android returns 81 results
product=iOS returns 58
vendor=Apple returns 380
vendor=Google returns 145 (bugs in Samsung's Android kernel,etc. are tracked separately)
vendor=Linux return 54
To be fair, a huge number of things make this not an even comparison, including the underlying bug rate, different products and downstream Android vendors being tracked separately. Also, # bugs found != which ones they choose to write about.
As siblings mentioned they do, I think part of the impression is a bit of a selection bias. Because Google puts itself into so many domains they have many many possible competitors. PZ tries to look at everything so they're bound to also look at google's competitors and find things. So even if they report on both themselves and on competitors, the numbers immediately look like they're reporting more on competitors because the number of companies involved is larger.
The very first sentence points to a PZ blog post about the Chrome sandbox.
The very first sentence points to a PZ blog post about a Windows vulnerability that affects the Chrome sandbox, not an issue with their own code.
Is the claim that PZ is some sort of PR attack on other companies?
Because as someone who is highly skeptical of Google's motives a lot of the time, that just seems like a batty take for anyone who is familiar with their work.
Because as someone who is highly skeptical of Google's motives a lot of the time, that just seems like a batty take for anyone who is familiar with their work.
That’s been the claim for as long as they existed, and one that Microsoft employees like to respond with in the media (and behind closed doors). It’s not true though. I have talked to some of the early PZ folks and they are unwavering in their devotion to sincerely held beliefs that they are making the internet safer. They feel strongly that their hard disclosure deadline is a critical component of this and they stick to those principles, even when it is unfavorable to Google.
The only reason that deadline exists is because many vendors have had a long history of taking advantage of researchers who agree to embargo details of their work while the vendors work on a fix. Bugs were going unfixed for years.
It has been my observation that this strategy only partially worked. The main thing that happened is that vendors now won’t sit on Google reported vulns, because they know Google are not bluffing, but they’re still generally happy to take their sweet time if the report comes from someone else. I know of some companies who put PZ bugs in a special queue to fast track them.
I think it has done a little bit in terms of setting norms for shorter disclosure timelines though.
The only reason that deadline exists is because many vendors have had a long history of taking advantage of researchers who agree to embargo details of their work while the vendors work on a fix. Bugs were going unfixed for years.
It has been my observation that this strategy only partially worked. The main thing that happened is that vendors now won’t sit on Google reported vulns, because they know Google are not bluffing, but they’re still generally happy to take their sweet time if the report comes from someone else. I know of some companies who put PZ bugs in a special queue to fast track them.
I think it has done a little bit in terms of setting norms for shorter disclosure timelines though.
I suspect from the Chrome security team's perspective there is very little difference, which is why they take significant measures to reduce the Windows kernel attack surface.