Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 24 Jan 2015 14:55:32 -0800
From: Michal Zalewski <>
To: oss-security <>
Subject: Re: Multiple vulnerabilities in LibTIFF and associated tools

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.

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

  - uninitialized memory in putcontig8bitYCbCr21tile
    Fixed in:

      2014-12-29  Even Rouault  <>

      * 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.

  - uninitialized memory in NeXTDecode
    Fixed in:

      2014-12-29  Even Rouault  <>

      * 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.

  - 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.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ