4 ms·

Would be interested to see threat models alongside these analyses. This is the key question. Nowhere is this more clear than in the final remark: Firefox also

Would be interested to see threat models alongside these analyses. This is the key question. Nowhere is this more clear than in the final remark: Firefox also uses RLBox but this is only used to sandbox two libraries (Graphite and Ogg) which again, is not anything substantial. https://www.mozilla.org/en-US/security/advisories/mfsa2018-08/ https://www.mozilla.org/en-US/security/advisories/mfsa2018-0... https://bugzilla.mozilla.org/show_bug.cgi?id=1446062 https://bugzilla.mozilla.org/show_bug.cgi?id=1446062 https://www.mozilla.org/en-US/security/advisories/mfsa2016-37/ https://www.mozilla.org/en-US/security/advisories/mfsa2016-3... https://nvd.nist.gov/vuln/detail/CVE-2017-7778 https://nvd.nist.gov/vuln/detail/CVE-2017-7778 https://www.cvedetails.com/cve/CVE-2011-0480/ https://www.cvedetails.com/cve/CVE-2011-0480/ https://www.cvedetails.com/cve/CVE-2011-3895/ https://www.cvedetails.com/cve/CVE-2011-3895/ So, all the security features that he considers large holes haven't been used to mount successful attacks, but the ones he considers "not substantial" are the ones that have been used for the real 0-days. It seems the "threat model" was "if Chrome has it, it must be important" and "if Chrome doesn't have it, it must be useless". You cannot do a serious security analysis this way, it's like looking at a list of feature checkboxes to choose a product. But in this case it's even worse because we only look at the checkboxes vendor G has ticked. Again, checking reality, which "sandbox hole" was used in the last successful Firefox exploit in pwn2own? https://www.mozilla.org/en-US/security/advisories/mfsa2019-25/#CVE-2019-9812 https://www.mozilla.org/en-US/security/advisories/mfsa2019-2... Nothing you're gonna find on that webpage!

bnurun 5y ago
> if Chrome doesn't have it, it must be useless Those Chrome CVEs are for single-digit version numbers from 10 years ago. I'm sure they sandbox FFmpeg more extensively now.
- rockdoe 5y ago
  Those Chrome CVEs are for single-digit version numbers from 10 years ago. Not that this has any actual relevance to the argument (which is that media decoding is a huge risk vector for browsers, and the kind of thing a threat model looks at), but I'll humor you: https://nvd.nist.gov/vuln/detail/CVE-2013-0894 https://nvd.nist.gov/vuln/detail/CVE-2013-0894 I'm sure they sandbox FFmpeg more extensively now. You are making my argument for me. Chrome sandboxes Vorbis -> important! Firefox sandboxes Vorbis in a much tighter way -> "not anything substantial".
  - bnurun 5y ago
    Considering where Firefox and Chrome overall stand on sandboxing, two libraries isn't substantial. Chrome has consistent, extensive sandboxing, and Firefox has sandboxing here and there as an afterthought. I looked into trying Firefox on Android but it apparently doesn't even have a sandbox.
    - lucideer 5y ago
      > as an afterthought This is my question though. Is it "as an afterthought" or is it "where needed, considering x threat model". The article above doesn't convince me that it's the former (or that Chrome's approach is anything more than advanced security theatre).
    - rockdoe 5y ago
      two libraries isn't substantial I've already disproven this assertion by pointing out those exact libraries are real life exploit vectors instead of theoretical weaknesses that most of the rest of the page talks about. Repeating the wrong assertion doesn't doesn't make it true. Chrome has consistent, extensive sandboxing, and Firefox has sandboxing here and there as an afterthought. This isn't really true either, the Chrome sandbox varies in what it blocks per process type, and it's the same for Firefox. The processes do have to talk to the operating system to accomplish anything useful! The original article also seems to completely miss this, at least in the Chrome case.

bnurun 5y ago

> if Chrome doesn't have it, it must be useless Those Chrome CVEs are for single-digit version numbers from 10 years ago. I'm sure they sandbox FFmpeg more extensively now.

rockdoe 5y ago
Those Chrome CVEs are for single-digit version numbers from 10 years ago. Not that this has any actual relevance to the argument (which is that media decoding is a huge risk vector for browsers, and the kind of thing a threat model looks at), but I'll humor you: https://nvd.nist.gov/vuln/detail/CVE-2013-0894 https://nvd.nist.gov/vuln/detail/CVE-2013-0894 I'm sure they sandbox FFmpeg more extensively now. You are making my argument for me. Chrome sandboxes Vorbis -> important! Firefox sandboxes Vorbis in a much tighter way -> "not anything substantial".
- bnurun 5y ago
  Considering where Firefox and Chrome overall stand on sandboxing, two libraries isn't substantial. Chrome has consistent, extensive sandboxing, and Firefox has sandboxing here and there as an afterthought. I looked into trying Firefox on Android but it apparently doesn't even have a sandbox.
  - lucideer 5y ago
    > as an afterthought This is my question though. Is it "as an afterthought" or is it "where needed, considering x threat model". The article above doesn't convince me that it's the former (or that Chrome's approach is anything more than advanced security theatre).
  - rockdoe 5y ago
    two libraries isn't substantial I've already disproven this assertion by pointing out those exact libraries are real life exploit vectors instead of theoretical weaknesses that most of the rest of the page talks about. Repeating the wrong assertion doesn't doesn't make it true. Chrome has consistent, extensive sandboxing, and Firefox has sandboxing here and there as an afterthought. This isn't really true either, the Chrome sandbox varies in what it blocks per process type, and it's the same for Firefox. The processes do have to talk to the operating system to accomplish anything useful! The original article also seems to completely miss this, at least in the Chrome case.