4 ms·

Not in and of itself.. However if part of that funding was used to cover formal (external) audits, investment in fuzzing/automated security testing etc.. then i

by darkr 5y ago

Not in and of itself.. However if part of that funding was used to cover formal (external) audits, investment in fuzzing/automated security testing etc.. then it might well have done

layer8 5y ago
That’s a really big "if" though.
svieira 5y ago
"Might have" is the operative word. In a world where Project Zero's _This shouldn't have happened_ [1] was also published this month (buffer overflow on NSS), I'm less certain. Quoted from the article: ---- This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. NSS was one of the very first projects included with oss-fuzz, it was officially supported since at least October 2014. Mozilla also fuzz NSS themselves with libFuzzer, and have contributed their own mutator collection and distilled coverage corpus. There is an extensive testsuite, and nightly ASAN builds. I'm generally skeptical of static analysis, but this seems like a simple missing bounds check that should be easy to find. Coverity has been monitoring NSS since at least December 2008, and also appears to have failed to discover this. Until 2015, Google Chrome used NSS, and maintained their own testsuite and fuzzing infrastructure independent of Mozilla. Today, Chrome platforms use BoringSSL, but the NSS port is still maintained. Did Mozilla have good test coverage for the vulnerable areas? YES. Did Mozilla/chrome/oss-fuzz have relevant inputs in their fuzz corpus? YES. Is there a mutator capable of extending ASN1_ITEMs? YES. Is this an intra-object overflow, or other form of corruption that ASAN would have difficulty detecting? NO, it's a textbook buffer overflow that ASAN can easily detect. ---- [1]: https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...

by darkr 5y ago

Not in and of itself.. However if part of that funding was used to cover formal (external) audits, investment in fuzzing/automated security testing etc.. then it might well have done

layer8 5y ago

That’s a really big "if" though.

svieira 5y ago

"Might have" is the operative word. In a world where Project Zero's _This shouldn't have happened_ [1] was also published this month (buffer overflow on NSS), I'm less certain. Quoted from the article: ---- This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. NSS was one of the very first projects included with oss-fuzz, it was officially supported since at least October 2014. Mozilla also fuzz NSS themselves with libFuzzer, and have contributed their own mutator collection and distilled coverage corpus. There is an extensive testsuite, and nightly ASAN builds. I'm generally skeptical of static analysis, but this seems like a simple missing bounds check that should be easy to find. Coverity has been monitoring NSS since at least December 2008, and also appears to have failed to discover this. Until 2015, Google Chrome used NSS, and maintained their own testsuite and fuzzing infrastructure independent of Mozilla. Today, Chrome platforms use BoringSSL, but the NSS port is still maintained. Did Mozilla have good test coverage for the vulnerable areas? YES. Did Mozilla/chrome/oss-fuzz have relevant inputs in their fuzz corpus? YES. Is there a mutator capable of extending ASN1_ITEMs? YES. Is this an intra-object overflow, or other form of corruption that ASAN would have difficulty detecting? NO, it's a textbook buffer overflow that ASAN can easily detect. ---- [1]: https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...