Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Found Over 1,000 Bugs In 47 Open Source Projects (helpnetsecurity.com)

Posted by EditorDavid on from the fuzzy-logic dept.

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.

2 of 55 comments (clear)

  1. Re:Profit! by Dutch+Gun · · Score: 3, 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."

    --
    Irony: Agile development has too much intertia to be abandoned now.
  2. Re:surprised by DRichardHipp · · Score: 5, Informative

    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.