[libvirt] [GSOC] project libvirt fuzzing

[D L]

On Thu, Mar 16, 2017 at 1:29 PM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> On Tue, Mar 07, 2017 at 12:27:58AM -0500, D L wrote:
> > On Sun, Mar 5, 2017 at 2:47 AM, Michal Privoznik <mprivozn at redhat.com>
> wrote:
> > Regarding fuzzing, I think we can try several fuzzing tools to run in
> > parallel, as different
> >  fuzzers tend to find different kinds of bugs. Thus, AFL (American Fuzz
> > Lop) [1],
> > which is a coverage-guided mutation-based fuzzer with genetic algorithm,
> > can
> > take hand-crafted xml seed to fuzz our libvert target. Alternatively, we
> > could
> > develop generation-based grammar module in AFL (which is definitely
> > non-trivial);
> > so far I have not seen active development in AFL community on xml format
> > grammar generation. Another option could be clang-libfuzzer [2].
> >
> > Several related articles show examples of fuzzing are using AFL to
> generate
> > SQL [3], llvm-afl [4], and hexml fuzzing with AFL [5]. In combination
> with
> > lcov, we
> >  could compare different fuzzers and guide our fuzzing tuning.
>
> FYI, I would very much like to see it use a fuzzer that is open source,
> because
> I'd like the end result of the project to ideally produce some test suite
> or
> test framework that we can put in to our CI system and run daily to
> validate
> future changes.
>
>
> Hi Daniel,

Yes, I am definitely focusing on open source fuzzers.

I have been having a question for quite a while. I thought mostly behind
the scenes
of each established open sources projects should have a security team
working
on security testing on a regular basis. Accordingly they also have the tool
chains
and standardized procedures to find, report and fix security
vulnerabilities. They may
or may not work with or collaborate with the Developer teams.

It is also possible that some of those exploitable bugs were purely
discovered just by
interested individuals as their side project/work. And some of them got CVE
assigned
eventually. I was hoping to find some record
 of how such bugs were discovered; i.e., there'd be some tutorial-like
documentations
describing how to work on a large scale industrial fuzzing project. I
primarily got
most of the impressions from the following links about libxml2 AFL fuzzing
bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=744980
https://bugzilla.gnome.org/show_bug.cgi?id=756263
https://bugzilla.gnome.org/show_bug.cgi?id=759020
https://bugzilla.gnome.org/show_bug.cgi?id=759671
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7115
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7116

Not only at libvirt community, is libxml2's situations also similar to
other major open
source projects?

Dan

Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/
> :|
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170320/869a01a4/attachment-0001.htm>