Bug 1031749 (CVE-2013-6630) - CVE-2013-6630 libjpeg: information leak (read of uninitialized memory)
Summary: CVE-2013-6630 libjpeg: information leak (read of uninitialized memory)
Status: CLOSED ERRATA
Alias: CVE-2013-6630
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20131112,repor...
Keywords: Security
Depends On: 1031737 1031739 1031740 1031741 1031955 1031957
Blocks: 1030229
TreeView+ depends on / blocked
 
Reported: 2013-11-18 17:02 UTC by Vincent Danen
Modified: 2016-04-26 14:48 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-03-02 18:03:58 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1803 normal SHIPPED_LIVE Moderate: libjpeg-turbo security update 2013-12-10 04:27:14 UTC

Description Vincent Danen 2013-11-18 17:02:02 UTC
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 17:04:50 UTC
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 17:07:51 UTC
Created libjpeg-turbo tracking bugs for this issue:

Affects: fedora-all [bug 1031737]

Comment 4 Vincent Danen 2013-11-18 17:07:58 UTC
Created mingw-libjpeg-turbo tracking bugs for this issue:

Affects: fedora-all [bug 1031740]

Comment 5 Vincent Danen 2013-11-18 17:08:05 UTC
Created mingw32-libjpeg tracking bugs for this issue:

Affects: epel-5 [bug 1031741]

Comment 6 Vincent Danen 2013-11-18 17:30:55 UTC
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 16:58:25 UTC
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 06:41:55 UTC
(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 23:28:40 UTC
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.