Bug 1031749 - (CVE-2013-6630) CVE-2013-6630 libjpeg: information leak (read of uninitialized memory)
CVE-2013-6630 libjpeg: information leak (read of uninitialized memory)
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20131112,repor...
: Security
Depends On: 1031737 1031739 1031740 1031741 1031955 1031957
Blocks: 1030229
  Show dependency treegraph
 
Reported: 2013-11-18 12:02 EST by Vincent Danen
Modified: 2016-04-26 10:48 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-02 13:03:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2013-11-18 12:02:02 EST
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
Comment 1 Vincent Danen 2013-11-18 12:04:50 EST
The Chromium bug is https://code.google.com/p/chromium/issues/detail?id=299835 but it's not currently public.
Comment 3 Vincent Danen 2013-11-18 12:07:51 EST
Created libjpeg-turbo tracking bugs for this issue:

Affects: fedora-all [bug 1031737]
Comment 4 Vincent Danen 2013-11-18 12:07:58 EST
Created mingw-libjpeg-turbo tracking bugs for this issue:

Affects: fedora-all [bug 1031740]
Comment 5 Vincent Danen 2013-11-18 12:08:05 EST
Created mingw32-libjpeg tracking bugs for this issue:

Affects: epel-5 [bug 1031741]
Comment 6 Vincent Danen 2013-11-18 12:30:55 EST
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.
Comment 10 Vincent Danen 2013-11-26 11:58:25 EST
This is now correct upstream:

http://sourceforge.net/p/libjpeg-turbo/code/1090/

That patch corrects both CVE-2013-6629 and CVE-2013-6630.
Comment 11 Huzaifa S. Sidhpurwala 2013-11-27 01:41:55 EST
(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 }
Comment 13 errata-xmlrpc 2013-12-09 18:28:40 EST
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

Note You need to log in before you can comment on or make changes to this bug.