Slashdot Mirror
Google Found Over 1,000 Bugs In 47 Open Source Projects (helpnetsecurity.com)
Orome1 writes:
In the last five months, Google's OSS-Fuzz program has unearthed over 1,000 bugs in 47 open source software projects... So far, OSS-Fuzz has found a total of 264 potential security vulnerabilities: 7 in Wireshark, 33 in LibreOffice, 8 in SQLite 3, 17 in FFmpeg -- and the list goes on...
Google launched the program in December and wants more open source projects to participate, so they're offering cash rewards for including "fuzz" targets for testing in their software. "Eligible projects will receive $1,000 for initial integration, and up to $20,000 for ideal integration" -- or twice that amount, if the proceeds are donated to a charity.
Google launched the program in December and wants more open source projects to participate, so they're offering cash rewards for including "fuzz" targets for testing in their software. "Eligible projects will receive $1,000 for initial integration, and up to $20,000 for ideal integration" -- or twice that amount, if the proceeds are donated to a charity.
>> or twice that amount ($40K), if the proceeds are donated to a charity.
1) Create some horribly insecure OSS software
2) Set up charity, make self "director", limit payouts to cause to under 5%, set director fees to around 90%
3) Integrate Google fuzz, report self and payout to, er, "charity"
4) PROFIT!
This is what open source is about. Together making software better and more secure!
This popped out of the Chrome project, if I'm reading this right. From:
https://github.com/google/oss-fuzz/
>> Currently OSS-Fuzz supports C and C++ code (other languages supported by LLVM may work too).
>> We (did) fuzzing of Chrome components...now want to share the...service with the open source community.
Isn't it interesting how it takes a multi-billion dollar closed-source development company to clean up the security messes left by open source software?
Isn't it interesting how it takes an unpaid outfit to expose the hacks of a multi-billion dollar closed state-sponsored terrorist agency taking advantage of the security messes of multi-billlion dollar closed source development companies?
Pain is merely failure leaving the body
What does this do that libasan and clang's scan-build don't?
The SQLite developers were also surprised by how many bugs OSS-Fuzz (and American Fuzzy Lop) have found in SQLite.
The best explanation I have is that OSS-Fuzz and AFL are exploring extreme corner-cases of the code where human-generated tests would never think to go. Fuzzing is great for finding bugs that involve totally unreasonable inputs that never happen in actual practice and which can only appear as part of a deliberate attack. Fuzzing has not found any bugs that would impact the day-to-day use of SQLite.
In other words, fuzzing finds an entirely different class of bugs from what the mountains of other test cases for SQLite are designed to find. This is a good thing. We encourage testing diversity.
Here is a list of issues found in SQLite by OSS-Fuzz (and now fixed): https://www.sqlite.org/src/sea...
There are a few cases of NULL pointer dereferences or other crashes that come about while unwinding the stack following an Out-Of-Memory error. Those kinds of errors are real, and we are grateful to OSS-Fuzz for finding them, even if they are seldom seen in the wild. Other issues were assertion faults that probably would not have resulting in a crash if assert() has been disabled (which is the case for all default builds of SQLite). And then there are things like https://www.sqlite.org/src/tim... which is not really a bug at all - OSS-Fuzz was submitting a funky recursive VIEW query that after unwinding all the nested views resulted in a very larger prepared statement, which took too long to process and so OSS-Fuzz timed out. SQLite was getting the correct answer, it was just taking too long. Since the submitted SQL was of no practical use, we "fixed" that problem by limiting the size of prepared statements to be about 100 times larger than any real SQL statement needs to be, rather than the default limit of about a 10 million times larger.
Isn't it interesting how it takes a multi-billion dollar closed-source development company to clean up the security messes left by open source software?
As opposed to closed-source security messes that NEVER get cleaned up?
If only they'd fix their own bugs.
Could be worse: they could be Apple.
"First they came for the slanderers and i said nothing."
It was mentioned what 3rd party tools were being used.
https://opensource.googleblog....
Where? I don't see any credit given to the people who actually wrote the fuzz software in blog post referenced in TFA.
What do you expect a front page NYT article?
I expect to see proper attribution. Normally I wouldn't care but Google is requiring people to credit it's bot which primarily executes software Google didn't write. This is BS in my view.