Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Bug Google Open Source

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.
This discussion has been archived. No new comments can be posted.

Google Found Over 1,000 Bugs In 47 Open Source Projects

Comments Filter:
  • Profit! (Score:5, Funny)

    by xxxJonBoyxxx ( 565205 ) on Saturday May 13, 2017 @11:39AM (#54410723)
    >> 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!
    • Re:Profit! (Score:4, Informative)

      by Dutch Gun ( 899105 ) on Saturday May 13, 2017 @12:33PM (#54410867)

      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."

    • You forgot a step...

      1.5) Get the OSS community to rely on your software on a daily basis.
    • >> 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".

  • Great news! (Score:3, Insightful)

    by therealspacebug ( 4922543 ) on Saturday May 13, 2017 @11:40AM (#54410725)
    This is what open source is about. Together making software better and more secure!
    • 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

  • by Anonymous Coward

    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.

  • by Anonymous Coward

    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)

      by DRichardHipp ( 995880 ) on Saturday May 13, 2017 @12:38PM (#54410889)

      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.

  • by nyet ( 19118 ) on Saturday May 13, 2017 @12:32PM (#54410863) Homepage

    What does this do that libasan and clang's scan-build don't?

    • 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.

  • 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).

The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin

Working...