2018.04.09 11:57 "Re: [Tiff] fuzzing libtiff with google's oss-fuzz", by Even Rouault

Paul,

I've some experience with fuzzing libtiff, as I do it indirectly through the GDAL project that uses it and embed an internal copy, which tracks libtiff HEAD quite closely.

GDAL doesn't use the RGBA interface very often, only as a last resort if the TIFF configuration is too "funny", so your fuzzer program would be complementary.

My suggestion (and I think that's in the line with oss-fuzz's recommandations) for a better integration would be to let the minimum bootstrapping code in oss-fuzz repository and move the rest to the libtiff one, so libtiff committers can easily (*) add new fuzzers to it. That's what I've done for GDAL.

See for example: https://github.com/google/oss-fuzz/blob/master/projects/gdal/build.sh

At the end it calls scripts in the GDAL repository itself: https://github.com/OSGeo/gdal/blob/master/gdal/fuzzers/build_google_oss_fuzzers.sh and that will build the fuzzer programs contained in that directory. and https://github.com/OSGeo/gdal/blob/master/gdal/fuzzers/build_seed_corpus.sh that prepare seed corpus files (could be the same script actually)

I've also a make target that creates 'dummy' binaries of the fuzzer program by compiling the fuzzer function together with a main() program https://github.com/OSGeo/gdal/blob/master/gdal/fuzzers/fuzzingengine.cpp That way you can easily test the fuzzer program in a standalone mode.

Quite handy for 99% cases of reproduction without needing the docker based infrastructure.

If that fit your needs, feel free to take inspiration of / copy the logic of https://github.com/OSGeo/gdal/tree/master/gdal/fuzzers

This is license compatible with libtiff.

You could add my email in the authorized list, even.rouault@gmail.com, but I' be happy if someone else would be identified as the lead.

Note that I do NOT engage myself to fix issues reported.

The issue of large memory allocations in face of some invalid (or even valid. RLE compression of a zeroed image can give you super small files with super large tiles) files is a annoying and tough one.

Suggestion: remove the explicit sanitizers: in project.yaml. I believe oss-fuzz doc says that would prevent new sanitizers they might add in the future to be triggered if you explicitly specify a list with sanitizers.

In tiff_read_rgba_fuzzer.cc, you call TIFFGetField(tif, TIFFTAG_IMAGEWIDTH, twice with different output variables

And you call TIFFGetField(tif, TIFFTAG_TILEWIDTH,) without checking that the image is tiled, which probably works from what I can see in tif_dirread.c but is probably kind of undefined behaviour.

Even

(*) Contributing to the Google oss-fuzz repository is a bit annoying for a casual contribution as you need to sign a CLA

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?expan

> d=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)

--
Spatialys - Geospatial professional services
http://www.spatialys.com