Re: Multiple vulnerabilities in LibTIFF and associated tools

[Michal Zalewski <lcamtuf () coredump cx>]

Oh well... if the cat is out the bag anyway, here's what I reported to
them. These affect the library itself and would also impact uses
within ImageMagick, etc.

http://lcamtuf.coredump.cx/afl/vulns/libtiff-mem2.tif

  - uninitialized memory in putcontig8bitCIELab / TIFFCIELabToXYZ
    I'm guesisng this is a dupe of CVE-2014-8127

http://lcamtuf.coredump.cx/afl/vulns/libtiff-cvs-1.tif

  - uninitialized memory in putcontig8bitYCbCr21tile
    Fixed in:

      2014-12-29  Even Rouault  <even.rouault () spatialys com>

      * libtiff/tif_getimage.c: in OJPEG case, fix checks on strile width/height
        in the putcontig8bitYCbCr42tile, putcontig8bitYCbCr41tile and
        putcontig8bitYCbCr21tile cases.

    I don't think this had a CVE number assigned yet.

http://lcamtuf.coredump.cx/afl/vulns/libtiff-cvs-2.tif

  - uninitialized memory in NeXTDecode
    Fixed in:

      2014-12-29  Even Rouault  <even.rouault () spatialys com>

      * libtiff/tif_next.c: add new tests to check that we don't read outside of
      the compressed input stream buffer.

    I don't think this had a CVE number assigned yet.

http://lcamtuf.coredump.cx/afl/vulns/libtiff5.tif

  - another use of uninitialized memory in NeXTDecode after fixing the
previous case.
    I don't think this had a CVE number assigned yet.

The communications with upstream have been spotty, which is probably
in part because many people are submitting crash reports at once. I
don't know when they plan the next release, and the commits often
aren't flagged as security-relevant or credited to any particular
report or reporter.

Anyway, the bottom line is that for now, using the last stable version
of libtiff on anything attacker-controlled is probably a bad idea.

/mz