I have been making some few specific improvement to demux fuzz target and also working on the decoder target side by side which isn’t done yet. Some general improvements that I have made for all fuzz targets is abstracting away and initializing the parent libvlc_instance_t object in LLVMFuzzerInitialize which obviously has some performance improvements as it isn’t created and destroyed on every run of the LLVMFuzzerTestOneInput.
So, I have been working on writing a fuzz target for the demux API for the past two weeks and I have reached a point where it has a good code coverage and has already found some few shallow bugs. Here are some of the stacktraces libfuzzer spit out and all of them were fixed rather promptly.
Introduction to this blog post here The Architecture I met with the VLC developers and my mentor at the VideoLabs office in Paris and after a few meetings and discussions we had a pretty good idea on how we could fuzz test libVLC and the VLC core most appropriately. In VLC, except the core, everything is a module. There are over 200+ modules in VLC along with libVLCCore and libVLC. The main module categories that take an input are: Access Access-demuxer Demuxer Packetizer Decoder Video filter
Software bugs and vulnerabilities can be difficult to detect and slow to find even when actively searched for by developers and users who usually look for superficial functional and visual bugs. In a large software especially those written in middle level languages like C/C++, security bugs and vulnerabilities can often be used to comprise the whole system. Mainly because memory management is left to the programmers of the individual software. One alternative to human Q&A testing is to use automated software testing techniques like Fuzzing where random, invalid or unexpected data is provided as input to a computer program.