Hide Forgot
It was reported [1],[2] that libjpeg-turbo would use uninitialized memory when handling Huffman tables (an issue similar to CVE-2013-6629). An example proof of concept is also available [3]. This was reported and fixed initially in Google Chrome/Chromium; it does not appear to be fixed in upstream libjpeg-turbo yet. A patch to the third party source in Chromium for libjpeg-turbo [4] however is available. Interestingly, the report at [2] indicates that libjpeg does not appear to be affected and indicates that a "simple fix for this is to locate get_dht in jdmarker.c and make sure that the huffval[] table is zeroed before use" however looking at a diff of jdmarker.c in libjpeg vs libjpeg-turbo doesn't seem to back that up (as a result this needs to be checked a little more closely as this zeroing of the huffval[] table does look applicable to libjpeg as well). [1] http://googlechromereleases.blogspot.de/2013/11/stable-channel-update.html [2] http://packetstormsecurity.com/files/123989/IJG-jpeg6b-libjpeg-turbo-Uninitialized-Memory.html [3] http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg [4] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmarker.c?r1=228381&r2=228394&pathrev=228394
The Chromium bug is https://code.google.com/p/chromium/issues/detail?id=299835 but it's not currently public.
Created libjpeg-turbo tracking bugs for this issue: Affects: fedora-all [bug 1031737]
Created mingw-libjpeg-turbo tracking bugs for this issue: Affects: fedora-all [bug 1031740]
Created mingw32-libjpeg tracking bugs for this issue: Affects: epel-5 [bug 1031741]
Common Vulnerabilities and Exposures assigned an identifier CVE-2013-6630 to the following vulnerability: Name: CVE-2013-6630 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6630 Assigned: 20131105 Reference: FULLDISC:20131112 bugs in IJG jpeg6b & libjpeg-turbo Reference: http://archives.neohapsis.com/archives/fulldisclosure/2013-11/0080.html Reference: http://git.chromium.org/gitweb/?p=chromium/deps/libjpeg_turbo.git;a=commit;h=32cab49bd4cb1ce069a435fd75f9439c34ddc6f8 Reference: http://googlechromereleases.blogspot.com/2013/11/stable-channel-update.html Reference: https://code.google.com/p/chromium/issues/detail?id=299835 The get_dht function in jdmarker.c in libjpeg-turbo through 1.3.0, as used in Google Chrome before 31.0.1650.48 and other products, does not set all elements of a certain Huffman value array during the reading of segments that follow Define Huffman Table (DHT) JPEG markers, which allows remote attackers to obtain sensitive information from uninitialized memory locations via a crafted JPEG image.
This is now correct upstream: http://sourceforge.net/p/libjpeg-turbo/code/1090/ That patch corrects both CVE-2013-6629 and CVE-2013-6630.
(In reply to Vincent Danen from comment #0) > Interestingly, the report at [2] indicates that libjpeg does not appear to > be affected and indicates that a "simple fix for this is to locate get_dht > in jdmarker.c and make sure that the huffval[] table is zeroed before use" > however looking at a diff (see below) of jdmarker.c in libjpeg vs > libjpeg-turbo doesn't seem to back that up (as a result this needs to be > checked a little more closely as this zeroing of the huffval[] table does > look applicable to libjpeg as well). > This issue does not affect libjpeg because there is already a check in jpeg_huff_decode(): From jdhuff.c: 425 /* With garbage input we may reach the sentinel value l = 17. */ 426 427 if (l > 16) { 428 WARNMS(state->cinfo, JWRN_HUFF_BAD_CODE); 429 return 0; /* fake a zero as the safest result */ 430 } 431 432 return htbl->pub->huffval[ (int) (code + htbl->valoffset[l]) ]; 433 }
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:1803 https://rhn.redhat.com/errata/RHSA-2013-1803.html