Google Project Zero: 95.8% of All Bug Reports Are Fixed Before Deadline Expires (zdnet.com) 41
The Google Project Zero team said that around 95.8% of the security bugs they find in other software and report to their respective vendors get fixed before the 90-day deadline for a public disclosure expires. From a report: That's quite the batting average for one of world's most infamous cybersecurity programs. In a statistic shared on Wednesday, Google's elite security team said that during its whole history -- from July 17, 2014, when Project Zero was created and until July 30, this week -- its researchers found and reported a total of 1,585 vulnerabilities to a wide range of hardware and software vendors. Of these, Google said that vendors failed to deliver a patch before the final deadline expired only for 66 reports. As a result, its researchers were forced to make vulnerability technical details public before a fix was made available to users.
Re: (Score:2)
So really it should be called (Score:2)
Re: (Score:3)
"Project Four.Two", not "Project Zero"
The "zero" refers to the concept of a 0day (zero-day) [wikipedia.org] vulnerability, one that is previously unknown to the maker of the product. The Project Zero (P0) team's mission is to find and report new (0day) vulnerabilities in widely-used products, but even more importantly to find new classes of vulnerabilities and to invent new ways to attack products. The idea is to find them before the bad guys do, and get them fixed.
Re: (Score:3)
One recent one was Apple, as reported here on Slashdot.
By right policy, the good of all (Score:4, Insightful)
The policy of giving vendors 90 days to release a fix before disclosure results in 99% of them being fixed in a timely manner. Almost all vendors decide they better fix it before it gets released.
Unfortunately, that policy, which is best for everyone, means that 1% of the time, vendors choose not to fix it and the info is released without a vendor fix (though there is often a configuration fix available).
They are forced to choose between this responsible disclosure policy, where 1% aren't fixed, or a no-disclosure policy where 85% aren't fixed, or an immediate disclosure n policy where 100% aren't fixed.
Following the best policy forces one to release info when it you'd rather not *in one particular case*.
Re: (Score:3)
"As a result, its researchers were forced to make vulnerability technical details public before a fix was made available to users."
Um, no. They chose to. Or rather, their employer chose for them. Nobody put a gun to Google's head and made it "an offer it couldn't refuse."
I'm not saying the choice was right or wrong, only that it was a choice.
If they choose to make exceptions to the policy, then it's not really a policy, and vendors will have a reduced incentive to fix the bugs.
The Project Zero team doesn't want to 0day the vendors, but if they want to make vendors fix the vulnerabilities quickly, they are forced to be strict about the policy. 90 days and no more, regardless of who the vendor is or what the vulnerability is.
Well, somewhat. I'm sure that if P0 researchers found some vulnerability that had the potential to enable crashing of
List of open issues (Score:3)
I'm curious to know who couldn't fix their software in 90 days but could not find a list.
However I found a list of open issues still not fixed: https://bugs.chromium.org/p/pr... [chromium.org]
The culprits listed:
Transmission
uTorrent
Apple (twice)
tcpdump
Re: (Score:2)
I'm curious to know who couldn't fix their software in 90 days but could not find a list.
Android failed to patch in time once, about three years ago.
I was happy to see that P0 was willing to 0day a Google product. Not that I want unpatched Android vulns to be published, but I think it's important that P0 consistently apply their policy to all vendors, including Google.
Re: (Score:2)
I was happy to see that P0 was willing to 0day a Google product.
That seems to be true only for less important bugs. I’m too lazy to go find it again, but when we had a similar discussion (main story may have been about an unpatched Apple vulnerability) here a few years ago I was able to dig up some serious Google vulnerabilities where Project Zero gave them way longer than 90 days - one was well over a year, IIRC.
Re: (Score:2)
I was happy to see that P0 was willing to 0day a Google product.
That seems to be true only for less important bugs. I’m too lazy to go find it again, but when we had a similar discussion (main story may have been about an unpatched Apple vulnerability) here a few years ago I was able to dig up some serious Google vulnerabilities where Project Zero gave them way longer than 90 days - one was well over a year, IIRC.
I'd love to see a citation.
Re: (Score:2)
Certain blocks of software are so critical that you can't just patch and go - because a failure of that software can lead to disasterous consequences.
Think of things like device drivers, kernel scheduler, file systems, network stack. Bugs in these often need more than 90 days because you want to make sure it's rock solid, or a user could lose their data, the machine could crash much too often, or other things that make
Re: (Score:2)
I'm totally with you on everything you say.
However I'd still like to see the full list and as an example of why: I just uninstalled Transmission because they have an issue with integer overflow open since 2017; uTorrent has an issue open since jan 2018. These are network applications running on a huge number of systems, 90 days seem plenty unless there are special circumstances.
With linux, one can at least get the feeling that there are a lot of programs with similar functionality and it's hard to tell whic
Re: (Score:2)