On Thu, Mar 16, 2017 at 1:29 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> 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.
Regards,
Daniel
--
Hi all,
I am reviewing the feedbacks of this thread, and I would like to revisit some topics.
I think this project is more about finding bugs in libvirt, when using fuzzing, especially
the implications would be security vulnerabilities. Thus the input file could be anything
that pretend to be legitimate xml, which potentially would crash the target program,
such as virsh. Depending on the exact fuzzer, being either mutational or generational, or
even hybrid, the fuzzer engine and the executor will take care most of the work
including input file generation, mutation, testing, recording, and reporting. Fuzzing
will allow us to reproduce the bugs with the recorded culprit xml file, then we have
a case where we find a bug. It is totally a lazy person's tool to do software testing,
without writing much code.
Therefore, I am modifying this project a little towards be a CI fuzzing testing framework,
potentially a deliverable product presenting a centralized real-time status of online fuzzing
information, integrated with libvirt existing toolchain. The components of the framework
incorporates fuzzer manager, a panel of open source fuzzer engines, executor, CI and
dashboard system.
There are related works such as oss-fuzz. However, the most obvious difference is that
here it can be potentially closely integrated into existing libvirt community workflow, or any other
open source community of the like who would like to have their own fuzzing CI with flexible
and version-ed configuration.
Dan
|: 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/ :|
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
