Google Found Over 1,000 Bugs In 47 Open Source Projects (helpnetsecurity.com) 55
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.
Profit! (Score:5, Funny)
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!
Re:Profit! (Score:4, Informative)
From TFA (in case anyone was wondering about the criteria):
"To qualify for these rewards, a project needs to have a large user base and/or be critical to global IT infrastructure."
Re: (Score:2)
1.5) Get the OSS community to rely on your software on a daily basis.
Re: (Score:2)
Re: (Score:2)
>> 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!
You forgot step 1.5: "Get horribly insecure OSS software to be used by a large number of people and/or be critical to global I/T infrastructure".
Re: Profit! (Score:1)
That's the easy part xD
Great news! (Score:3, Insightful)
Re: (Score:3)
If you haven't done this for your projects, fuzz testing is an awesome stability and security test for any sort of input parser.
I maintain a small open source project (that no one but me uses, but hey, it's there if people want), and I found several bugs in the parser with my fuzz tests. I just wrote a *very* simple test myself using basic mutation techniques (randomly altering samples of valid input data), and it was still pretty effective.
I'm looking forward to hearing about further positive results from
Thank you Google (Score:1)
Thank you, this shows again the advantage of open source free software. Now all communities can start fixing the bugs. There is no security by obscurity, or it's just a false misperception, possible like with proprietary software.
Re: (Score:3)
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.
Re: Thank you Google (Score:5, Insightful)
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?
Re: (Score:2)
Ever heard of valgrind?
scan-build?
libasan?
Re: (Score:3)
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?
Re: (Score:3)
Could be worse: they could be Apple.
surprised (Score:1)
I'm surprised they found so few in libreoffice compared to sqlite. Sqlite has the most extensive unit tests I've ever seen in my life. and LibreOffice is just so huge relative to it. I guess that goes to saying they're doing a pretty good job.
Re:surprised (Score:5, Informative)
The SQLite developers were also surprised by how many bugs OSS-Fuzz (and American Fuzzy Lop [coredump.cx]) 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 [sqlite.org] 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... [sqlite.org]
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... [sqlite.org] 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.
Re: Why my program doesn't use SQLite (Score:1)
What does this do (Score:3)
What does this do that libasan and clang's scan-build don't?
Re: (Score:2)
What does this do that libasan and clang's scan-build don't?
Fuzzing is the process of running code that accepts some user input and feeding it all sorts of bizarre garbage in an attempt to find cases the developers failed to handle. It's common to use a fuzzer in combination with something like libasan, because libasan will point make buggy codepaths fail more obviously when the fuzzer triggers them. Clang's scan-build is a static code analyzer, a completely different type of scanner.
Re: (Score:3)
It was mentioned what 3rd party tools were being used.
https://opensource.googleblog.... [googleblog.com]
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.
Re: (Score:2)
Few others can devote such intense, continuous computational resources to finding bugs. Fuzz testing relies on a lot of brute-force computational power to test such a unfathomable number of potential test permutations, and it seems like this is essentially what they're providing.
Given how many bugs they've found, I'd call "promotion of a worthwhile service" rather than "attention whoring". I mean, Google is essentially sponsoring projects to help make them more secure.
I understand your point about attribu
And how many in closed source again? (Score:2)
At least in the open source you a) KNOW about the bugs, and b) can fix them.
In closed source bugs can remain hidden for DECADES. [wikipedia.org]
i.e. The WMF bug was fixed in 2006 but has existed since the Windows 3.x days (1990).