AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2018.04.09 07:29 "[Tiff] fuzzing libtiff with google's oss-fuzz", by Paul Kehrer
2018.04.09 08:05 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Nicolas RUFF
2018.04.09 08:19 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Paul Kehrer
2018.04.09 13:44 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Bob Friesenhahn
2018.04.09 14:09 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Even Rouault
2018.04.09 14:52 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Bob Friesenhahn
2018.04.09 19:27 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Roger Leigh
2018.04.09 09:48 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Paavo Helde
2018.04.09 11:57 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Even Rouault
2018.04.10 01:50 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Paul Kehrer
2018.04.10 11:50 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Even Rouault
2018.04.15 14:34 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Even Rouault
2018.04.16 00:36 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Paul Kehrer

2018.04.09 07:29 "[Tiff] fuzzing libtiff with google's oss-fuzz", by Paul Kehrer

I've been experimenting with fuzzing libtiff recently and was wondering if there is interest in integrating libtiff into Google's OSS-Fuzz ( https://github.com/google/oss-fuzz)? OSS-Fuzz is a public infrastructure for running continuous fuzzing. The system will automatically fuzz the targets you define, aggregate duplicate bug reports, and file issues with minimal reproducers and stack traces so that project developers can easily verify and fix issues. libtiff appears to be getting some fuzzing by proxy via other projects, but I'd be happy to manage the process of integration and submit PRs so that you can directly receive reports and get better coverage.

The primary challenge at the moment is controlling libtiff's memory allocations (it looks like several previous OSS fuzz related fixes have attempted to address that in various code paths?). It is very easy to craft files that will cause extremely large malloc and I've been unable to find a library level way to constrain that. However, I've modified my existing fuzzer a bit to throw out most test cases that would trigger OOMs for now (at least all the ones I was able to generate locally). Ideally in the longer term those would be removed as libtiff gets better at avoiding large allocations on invalid files. Additionally, at the moment the fuzzer I wrote only uses TIFFReadRGBAImage -- do people have suggestions for other functions that might be worthwhile to fuzz? You can see the current diff adding libtiff to the oss-fuzz repo (this includes building libz and libjpeg-turbo as well as compiling the fuzzer) here: https://github.com/google/oss-fuzz/compare/master...reaperhulk:libtiff?expand=1

If there's interest I just need to know who to put as the primary project email contact and any other people you want to grant access. Those email addresses will need to be associated with a Google account so that you can log into oss-fuzz.com to view the reports.

-Paul Kehrer (reaperhulk)