[vlc-devel] [PATCH] add libfuzzer support

[Rémi Denis-Courmont]

Le keskiviikkona 21. kesäkuuta 2017, 18.41.12 EEST Shaleen Jain a écrit :
> > AFAIK, this won't work. You need to build the entire tree with
> > sanitizers, not just the fuzzing binary.
> > 
> > The source code is missing too. But, I don't think that this should
> > be published, as it helps potentially hostile third parties with
> > better computational power than it helps us. That is why I did not
> > publish my own AFL and libfuzzer VLC frontends.
> > --
> > Rémi Denis-Courmont
> > Typed on an inconvenient virtual keyboard
> 
> Hello,
> 
> It works, but yes for pretty stack traces you need to build the
> complete source with sanitizers while running ./configure with
> C/CXXFLAGS

Sorry but I very much doubt that undefined behaviour sanitization can work at 
all if it is not enabled during compilation. Likewise most of the address 
sanitization functionality (e.g. boundary checks). Stack traces are just the 
top of the iceberg.

And besides, sanitizers are orthogonal to fuzzing. Even if it worked, forcing 
them just there is gratuitious/arbitrary.

> Have a separate patch for the source here
> https://mailman.videolan.org/pipermail/vlc-devel/2017-June/113736.html
> 
> Working on this as part of integration with oss-fuzz which will give us
> a lot more computation power than any third party.

I don´t know that. Specifically, I don´t know how much power software 
vulnerability hoarders have.

> I don't think security by obscurity is really an option for us.

Also, it is not only about computational power. Guided fuzzers results depend 
heavily on the quality of the input samples, classification efforts, abd bug 
analysis and fixing power.

Many of the issues that I found are not even addressed yet. I found them using 
a single desktop PC with a few crappy samples. There must be hundreds of low-
hanging fruits left, and it does not seem like we have the human resources to 
deal with them.

> You should really publish your code as well

I´d rather get more opinions.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/