Date: Tue, 18 Nov 2014 13:32:09 -0800 From: Seth Arnold <seth.arnold@...onical.com> To: oss-security@...ts.openwall.com Subject: Re: RE: [security-vendor] Re: Fuzzing findings (and maybe CVE requests) - Image/GraphicsMagick, elfutils, GIMP, gdk-pixbuf, file, ndisasm, less On Tue, Nov 18, 2014 at 03:10:58PM +0000, Radzykewycz, T (Radzy) wrote: > There's no guarantee about anything being "bug free". Even > certification by NIAP doesn't guarantee that it's bug free. Nor that > it's secure. But it does make it relatively more likely to have fewer > bugs and be more secure. Same with OSS tool fuzzing and some kind of > database indicating the level of fuzzing that has happened on them. > > If I were a Linux distro maintainer, looking at packages to include, I > would appreciate this information. (For that matter, I'd appreciate it > for my own use, though that's less relevant.) > > If there is a distro maintainer on this list, please chime in. Part of my job at Canonical is reviewing packages before the Ubuntu security team commits to supporting the packages. (Ubuntu "main" receives official security support; "universe" receives community support.) The reviews are very short; typically they take me a day to read the code and an hour or so to provide a report for context for the decision. More complicated projects may take a bit longer and only the smallest of projects can be done in an hour or two. Because there's so little time for each one, automated assistance is wonderful. I look for compiler warnings, run some static analysis checks, and use a large pile of greps that help find difficult or troublesome pieces of code. I'd like to have more automated assistence. We're not looking for bug-free software -- that's unlikely -- so we're looking for software that's professionally developed and feels like it won't be an undue maintenance burden. Adding a fuzzer or two to the process might be worthwhile; the downside is that most fuzzers seem to require a certain amount of preperation work before they start giving good results, and depending upon the program, a fuzzer may not reliably represent the attack surfaces available. (Consider trying to fuzz e.g. openssh or nginx.) I don't think it'd be easy to automate. Getting AFL to work with every package suggested for Ubuntu main is probably too much work. Getting zzuf to work might be easier but may not provide as comprehensive results. zzuf would at least help on projects written in languages where static analysis tools are lacking or not yet in our auditing framework. The results of a fuzzing project would not greatly influence our decision to support a package. I don't believe surviving a fuzzer is the best proxy for code quality, though it would be nice to have more information when making a decision to support a package. Of course, if someone were to run a fuzzing project, the results would doubtless be valuable for everyone, assuming you could get buy-in from upstreams to help prepare patches or at least accept them. Thanks Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
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.