Date: Wed, 12 Nov 2014 03:51:39 +0300 From: Alexander Cherepanov <cherepan@...me.ru> To: oss-security@...ts.openwall.com Subject: Re: Re: strings / libbfd crasher On 2014-11-05 05:25, Michal Zalewski wrote: >> Thanks a lot for your explanation! The data for most things that you >> describe seems to be available from valgrind so it could be scripted. > > Sort of. Microsoft actually had a triage tool along these lines > ("!exploitable" or something like that). Yes, and it surprisingly is open source: http://msecdbg.codeplex.com/ > It's always pretty coarse in the end, though. That's no surprise:-) Hm, googling found a discussion of similar question here: https://security.stackexchange.com/questions/6998/best-way-to-triage-crashes-found-via-fuzzing-on-linux which links to an "exploitable" GDB extension: http://www.cert.org/blogs/certcc/post.cfm?EntryID=90 https://github.com/jfoote/exploitable > This reminds me... Mateusz Jurczyk and Gynvael Coldwind were fuzzing > ffmpeg on several thousand cores for a while and bumped into something > around 1k seemingly distinctive crashes: > > http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html > > I can imagine that their initial enthusiasm has quickly waned when > they realized how much effort it's going to take to triage all that > and get it fixed. It is interesting how they separated security issues from non-security ones and how CVEs were assigned. They list a bunch of CVEs and for the first bunch of issues their "personal feeling is that between 10% and 20% of the problems could be considered easily exploitable security issues". > In this case, I think they had a pretty good > relationship with the maintainers, which probably helped a lot =) For binutils Nick Clifton remains very responsive for two weeks already (issues are usually fixed in under 1 day excluding weekends). I guees we can try to see how maintainers of other software react to a stream of crashes:-) >> That's after deduping by a call stack as available in valgrind output:-( > > The codebase is kind of bad, Is codebase generally much better? You aim at "the more difficult or better-fuzzed targets" but what about other software? Or put it another way: how big portion of widely used software you consider "the more difficult or better-fuzzed targets"? My guess is that too much software is of similar or lower quality. This leads to a question: how to deal with it. Suppose we are fuzzing some programs and find tens, hundreds or thousands (cf. ffmpeg above) of distinct crashes. Ok, all bugs should be fixed, hence we submit all crashes to maintainers. But how we as a community want to handle it -- separate security and non-security cases, prioritize fixes in some way, disclose all publicly from the beginning or report it privately, track everything with CVEs? It seems to me that manually analyzing exploitability of the issues adds a nontrivial amount of work to the process and requires a quite experienced men. > but I'd imagine that there aren't > hundreds of fundamentally distinctive bugs in libbfd that can be > reached via strings or equivalent (unless the library is configured > with all the exotic binary formats that are normally off). You are effectively saying that "deduping by a call stack as available in valgrind output" is not very good. Quite probably. Perhaps taking last 4 frames (as done by valgrind itself) is better. > There are definitely many instances where the same bad coding pattern > is copied and pasted into several dozen places, though. For example, > the srec bugs I initially bumped were essentially widespread > throughout the entire file, with something like a dozen possible crash > locations. So, can such cases be deduped automatically? Or should they? Or you mean that they are easy to analyze manually? -- Alexander Cherepanov
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.