7 ms·

FF Sandbox Escape

126 points by weinzierl 6y ago

ghostpepper 6y ago
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)
- comfydragon 6y ago
  Sure. https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html https://googleprojectzero.blogspot.com/2019/11/bad-binder-an... https://googleprojectzero.blogspot.com/2020/02/mitigations-are-attack-surface-too.html https://googleprojectzero.blogspot.com/2020/02/mitigations-a... https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html https://googleprojectzero.blogspot.com/2016/12/chrome-os-exp...
- jbroman 6y ago
  The very first sentence points to a PZ blog post about the Chrome sandbox.
  - jgon 6y ago
    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.
    - staticassertion 6y ago
      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.
    - _jal 6y ago
      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.
      - lawnchair_larry 6y ago
        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.
- simcop2387 6y ago
  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.
- albntomat0 6y ago
  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 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.
Sniffnoy 6y ago
Non-mobile link: https://googleprojectzero.blogspot.com/2020/06/ff-sandbox-escape-cve-2020-12388.html https://googleprojectzero.blogspot.com/2020/06/ff-sandbox-es...
etaioinshrdlu 6y ago
It looks like this is not an actual exploit, but a hole in the sandbox that first requires injecting custom code into the process?
- albntomat0 6y ago
  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.
- dathinab 6y ago
  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.
- kevingadd 6y ago
  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)
- tiraniddo 6y ago
  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.
starlig-ht 6y ago
"Sandbox Escape" sounded like something fun but alas
2close4comfort 6y ago
Meh...escape must mean something different at Google
- staticassertion 6y ago
  What do you mean?
Thorrez 6y ago
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.
- 0xcoffee 6y ago
  I know they use the v8 regex engine: https://hacks.mozilla.org/2020/06/a-new-regexp-engine-in-spidermonkey/ https://hacks.mozilla.org/2020/06/a-new-regexp-engine-in-spi...
- deleted 6y ago
  [deleted]
- keeperofdakeys 6y ago
  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
  - fluffything 6y ago
    I thought one of the main point of Firefox would be to not do this :D
    - vertex-four 6y ago
      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.
- half-kh-hacker 6y ago
  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.

126 points by weinzierl 6y ago

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)

comfydragon 6y ago
Sure. https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html https://googleprojectzero.blogspot.com/2019/11/bad-binder-an... https://googleprojectzero.blogspot.com/2020/02/mitigations-are-attack-surface-too.html https://googleprojectzero.blogspot.com/2020/02/mitigations-a... https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html https://googleprojectzero.blogspot.com/2016/12/chrome-os-exp...
jbroman 6y ago
The very first sentence points to a PZ blog post about the Chrome sandbox.
- jgon 6y ago
  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.
  - staticassertion 6y ago
    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.
  - _jal 6y ago
    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.
    - lawnchair_larry 6y ago
      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.
simcop2387 6y ago
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.
albntomat0 6y ago
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 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.

Sniffnoy 6y ago

Non-mobile link: https://googleprojectzero.blogspot.com/2020/06/ff-sandbox-escape-cve-2020-12388.html https://googleprojectzero.blogspot.com/2020/06/ff-sandbox-es...

etaioinshrdlu 6y ago

It looks like this is not an actual exploit, but a hole in the sandbox that first requires injecting custom code into the process?

albntomat0 6y ago
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.
dathinab 6y ago
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.
kevingadd 6y ago
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)
tiraniddo 6y ago
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.

starlig-ht 6y ago

"Sandbox Escape" sounded like something fun but alas

2close4comfort 6y ago

Meh...escape must mean something different at Google

staticassertion 6y ago
What do you mean?

Thorrez 6y ago

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.

0xcoffee 6y ago
I know they use the v8 regex engine: https://hacks.mozilla.org/2020/06/a-new-regexp-engine-in-spidermonkey/ https://hacks.mozilla.org/2020/06/a-new-regexp-engine-in-spi...
deleted 6y ago
[deleted]
keeperofdakeys 6y ago
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
- fluffything 6y ago
  I thought one of the main point of Firefox would be to not do this :D
  - vertex-four 6y ago
    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.
half-kh-hacker 6y ago
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.