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.

22 of 55 comments (clear)

  1. Profit! by xxxJonBoyxxx · · Score: 4, Funny

    >> 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!

    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:Profit! by freeze128 · · Score: 1

      You forgot a step...

      1.5) Get the OSS community to rely on your software on a daily basis.

    3. Re:Profit! by swillden · · Score: 1

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

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:Profit! by AchilleTalon · · Score: 1

      Are you talking about systemd?

      --
      Achille Talon
      Hop!
    5. Re: Profit! by Anonymous Coward · · Score: 1

      That's the easy part xD

  2. Great news! by therealspacebug · · Score: 3, Insightful

    This is what open source is about. Together making software better and more secure!

    1. Re:Great news! by Dutch+Gun · · Score: 2

      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 this project.

      --
      Irony: Agile development has too much intertia to be abandoned now.
  3. Thank you Google by Anonymous Coward · · 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.

    1. Re: Thank you Google by xxxJonBoyxxx · · Score: 2

      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.

    2. Re: Thank you Google by haruchai · · Score: 4, 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?

      --
      Pain is merely failure leaving the body
    3. Re: Thank you Google by nyet · · Score: 1

      Ever heard of valgrind?
      scan-build?
      libasan?

    4. Re: Thank you Google by chipschap · · Score: 2

      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?

    5. Re: Thank you Google by phantomfive · · Score: 2

      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."
  4. surprised by Anonymous Coward · · 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.

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

  5. What does this do by nyet · · Score: 2

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

    1. Re:What does this do by swillden · · Score: 1

      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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  6. Re:What value is google providing? by WaffleMonster · · Score: 2

    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.

  7. Re: Why my program doesn't use SQLite by Brockmire · · Score: 1

    Because you have a backdoor in it. Or just embarrassed by how shitty your code is.

  8. And how many in closed source again? by UnknownSoldier · · Score: 1

    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.

    i.e. The WMF bug was fixed in 2006 but has existed since the Windows 3.x days (1990).

  9. Re:What value is google providing? by Dutch+Gun · · Score: 1

    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 attribution, but I think you're underestimating Google's contribution as well.

    --
    Irony: Agile development has too much intertia to be abandoned now.