On Thu, Mar 16, 2017 at 1:29 PM, Daniel P. Berrange <berrange@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@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.

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/ :|