Date: Sat, 24 Jan 2015 14:55:32 -0800 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com> 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. 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@...tialys.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@...tialys.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ