** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Drew Yao of Apple Product Security reported two integer overflows and one free() on an uninitialized pointer in OpenEXR 1.6.1 and earlier. The following is an excerpt of his email. He also provided patches, but I'd like upstream to sign-off on them first. Bugs 1 and 2: CVE-2009-1720 Bug 3: CVE-2009-1721 Bug 4: CVE-2009-1722 Bug 1) Integer overflow in Imf::PreviewImage::PreviewImage in ImfPreviewImage.cpp PreviewImage::PreviewImage (unsigned int width, unsigned int height, const PreviewRgba pixels[]) { _width = width; _height = height; _pixels = new PreviewRgba [_width * _height]; If _width * _height * sizeof(PreviewRgba) wraps around to a small number, an unexpectedly small buffer will be allocated, leading to memory corruption. Bug 2) Integer overflows in compressor constructors name:ImfPxr24Compressor.cpp Pxr24Compressor::Pxr24Compressor (const Header &hdr, int maxScanLineSize, int numScanLines) : Compressor (hdr), _maxScanLineSize (maxScanLineSize), _numScanLines (numScanLines), _tmpBuffer (0), _outBuffer (0), _channels (hdr.channels()) { int maxInBytes = maxScanLineSize * numScanLines; _tmpBuffer = new unsigned char [maxInBytes]; _outBuffer = new char [int (ceil (maxInBytes * 1.01)) + 100]; maxScanLineSize and numScanLines come from the file. If the multiplication wraps around, the buffer would be allocated unexpectedly small, leading to memory corruption later. Bug 3) Freeing uninitialized pointers in Imf::hufUncompress name:ImfHuf.cpp void hufUncompress (const char compressed[], int nCompressed, unsigned short raw[], int nRaw) { ... AutoArray <Int64, HUF_ENCSIZE> freq; AutoArray <HufDec, HUF_DECSIZE> hdec; hufUnpackEncTable (&ptr, nCompressed - (ptr - compressed), im, iM, freq); try { if (nBits > 8 * (nCompressed - (ptr - compressed))) invalidNBits(); hufBuildDecTable (freq, im, iM, hdec); hufDecode (freq, hdec, ptr, nBits, iM, nRaw, raw); } catch (...) { hufFreeDecTable (hdec); throw; } hufFreeDecTable (hdec); ... void hufFreeDecTable (HufDec *hdecod) // io: Decoding table { for (int i = 0; i < HUF_DECSIZE; i++) { if (hdecod[i].p) { delete [] hdecod[i].p; hdecod[i].p = 0; } } } The problem is that the catch block will call hufFreeDecTable to free every pointer in the table, even if part of the table is uninitialized. Bug 4) Buffer overflow in ImfPizCompressor.cpp This was fixed a while ago in version 1.6.1, but never got a CVE. http://openexr.com/ """ October 22, 2007 - New versions of OpenEXR and CTL are now available. This release fixes a buffer overrun in OpenEXR and a Windows build problem in CTL, and it removes a few unnecessary files from the .tar.gz packages.OpenEXR 1.6.1, OpenEXR_Viewers 1.0.1 and IlmBase 1.0.1 can be downloaded from the downloads section of www.openexr.com. CTL 1.4.1 and OpenEXR_CTL 1.0.1 can be downloaded from http://www.oscars.org/council/ctl.html . """ Relevant patches for this bug: http://cvs.savannah.gnu.org/viewvc/OpenEXR/ChangeLog?root=openexr&r1=1.111&r2=1.112 http://cvs.savannah.gnu.org/viewvc/OpenEXR/IlmImf/ImfHeader.cpp?root=openexr&r1=1.17&r2=1.19 http://cvs.savannah.gnu.org/viewvc/OpenEXR/IlmImf/ImfHeader.h?root=openexr&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewvc/OpenEXR/IlmImf/ImfPizCompressor.cpp?root=openexr&r1=1.6&r2=1.7
now public
craig: CVE-2009-1722 was fixed in 2007 in gentoo and is not relevant anymore
Created attachment 200439 [details, diff] openexr-CVE-2009-1720+CVE-2009-1721.patch patch in CVS HEAD.
Created attachment 200441 [details, diff] openexr-1.6.1-CVE-2009-1720+CVE-2009-1721.patch trivial backport to 1.6.1 please bump!
(In reply to comment #4) > Created an attachment (id=200441) [edit] > openexr-1.6.1-CVE-2009-1720+CVE-2009-1721.patch > > trivial backport to 1.6.1 > > please bump! Problem is, this breaks ABI, use nm -D --defined-only /usr/lib/libIlmImf.so.6.0.0 | awk '{print $3}' | c++filt to obtain it. Then, diffing the output gives me: -Imf::B44Compressor::B44Compressor(Imf::Header const&, int, int, bool) -Imf::B44Compressor::B44Compressor(Imf::Header const&, int, int, bool) +Imf::B44Compressor::B44Compressor(Imf::Header const&, unsigned long, unsigned long, bool) +Imf::B44Compressor::B44Compressor(Imf::Header const&, unsigned long, unsigned long, bool) Defined in /usr/include/OpenEXR/ImfB44Compressor.h, hence available for library consumers. Other changes are not defined in public headers thus may be considered safe.
Oh, I did not notice. I checked, the CVS HEAD has the same LIBTOOL_CURRENT as the last release (6). We could either contact Florian Kainz about increasing it so their next release is ok and then amend the patch, or use the original patches by Drew Yao which should be ABI compatible. http://cvs.fedoraproject.org/viewvc/rpms/OpenEXR/devel/openexr-1.6.1-CVE-2009-1720-1.patch?revision=1.1&view=markup http://cvs.fedoraproject.org/viewvc/rpms/OpenEXR/devel/openexr-1.6.1-CVE-2009-1720-2.patch?revision=1.1&view=markup http://cvs.fedoraproject.org/viewvc/rpms/OpenEXR/devel/openexr-1.6.1-CVE-2009-1721.patch?revision=1.1&view=markup Since I prefer going with the upstream approach, I'd mail him if you have not done so yet.
*ping*
Test & stabilize: =media-libs/ilmbase-1.0.2 "alpha amd64 hppa ia64 ppc ppc64 s390 sh sparc x86" =media-libs/openexr-1.7.0 "alpha amd64 hppa ia64 ppc ppc64 s390 sh sparc x86" =media-gfx/openexr_viewers-1.0.2 "alpha amd64 hppa ia64 ppc ppc64 sparc x86"
*** Bug 346657 has been marked as a duplicate of this bug. ***
amd64 ok
Stable for HPPA.
Tested on SPARC: ilmbase-1.0.2, passed all tests, openexr-1.7.0 built OK but failed on one of the tests which aborted the testing process as it threw an assert, openexr_viewers-1.0.2 built OK, but has no tests to run through. I think that. It's up to you whether you can stabilise or not on SPARC, but personally I'd investigate the test failure and why it aborted.
amd64 done. Thanks Agostino
x86 stable
alpha/ia64/sparc stable, s390/sh keywords dropped
Stable for PPC.
ppc64 done. @security: last arch done, into you hands
and vulnerable versions removed from tree as well, add media-video@ back if you need something, thanks!
GLSA request filed.
hum, may it's time to close?
This issue was resolved and addressed in GLSA 201312-07 at http://security.gentoo.org/glsa/glsa-201312-07.xml by GLSA coordinator Chris Reffett (creffett).