what you don't know can hurt you

IJG jpeg6b / libjpeg-turbo Uninitialized Memory

IJG jpeg6b / libjpeg-turbo Uninitialized Memory
Posted Nov 12, 2013
Authored by Michal Zalewski | Site lcamtuf.coredump.cx

jpeg6b and some of its optimized clones (e.g., libjpeg-turbo) will use uninitialized memory when decoding images with missing SOS data for the luminance component (Y) in presence of valid chroma data (Cr, Cb).

tags | advisory
advisories | CVE-2013-6629, CVE-2013-6630
MD5 | c74e7593702f247838a41cf95581a50f

IJG jpeg6b / libjpeg-turbo Uninitialized Memory

Change Mirror Download
Dearly beloved,

So, for one reason or another, the IJG jpeg library has gained some
notoriety as one of the most robust pieces of complex,
security-critical C code. Despite countless fuzzing efforts, I don't
recall any reports of serious vulnerabilities at least since the
release of jpeg6b in 1998 (that's still the most commonly-used version
of that library). Compared to the track record of libraries such as
libpng or libtiff, that's quite a feat.

Well, as it happens, jpeg6b and some of its optimized clones (e.g.,
libjpeg-turbo) will use uninitialized memory when decoding images with
missing SOS data for the luminance component (Y) in presence of valid
chroma data (Cr, Cb). Here's a nice PoC for Chrome, Firefox & Safari,
with fixes shipping as we speak (CVE-2013-6629):


Funnily enough, as we were investigating this finding, we noticed that
the problem has been independently spotted back in 2003, but not
recognized as a security issue:


The patch developed by Ghotscript folks to fix rendering problems with
a particular document apparently ended up in limbo until 2013, at
which point it was incorporated into a relatively little-used version
9 of IJG jpeg. As far as I can tell, there are no changelog entries
associated with this fix.

Anyway, if you're using libjpeg-turbo, jpeg6b, or any derived code,
you probably want to backport the changes to get_sos() in jdmarker.c.
Look for the section that talks about checking for unique component
IDs. A new version of libjpeg-turbo will probably fix this upstream
soon. I wouldn't expect upstream fixes to jpeg6b itself.


While we're on the topic of JPEG libraries... a bit less
interestingly, there is also a separate but similar issue in the
handling of Huffman tables in libjpeg-turbo. This one apparently does
not affect IJG jpeg, and doesn't such a colorful history to go with
it. A raw image illustrating the problem (CVE-2013-6630) is here:


A simple fix for this is to locate get_dht in jdmarker.c and make sure
that the huffval[] table is zeroed before use.


Well, that's it. As far as the impact goes, similar info leaks have
been previously shown to allow a variety of things in the browser
environment, including cookie theft or bypassing ASLR; see
http://vexillium.org/?sec-ff for one cool example.

The general case of code that performs one-shot image conversions in a
separate process is of minimal concern; in-process or multi-shot
conversions can be problematic. Converters that do not directly decode
user-supplied JPEGs should be OK.

PS. If you're interested about the tool used to generate and isolate
these inputs, check out http://code.google.com/p/american-fuzzy-lop/



RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

June 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    1 Files
  • 2
    Jun 2nd
    2 Files
  • 3
    Jun 3rd
    19 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    15 Files
  • 6
    Jun 6th
    12 Files
  • 7
    Jun 7th
    11 Files
  • 8
    Jun 8th
    1 Files
  • 9
    Jun 9th
    1 Files
  • 10
    Jun 10th
    15 Files
  • 11
    Jun 11th
    15 Files
  • 12
    Jun 12th
    15 Files
  • 13
    Jun 13th
    8 Files
  • 14
    Jun 14th
    16 Files
  • 15
    Jun 15th
    2 Files
  • 16
    Jun 16th
    1 Files
  • 17
    Jun 17th
    18 Files
  • 18
    Jun 18th
    15 Files
  • 19
    Jun 19th
    22 Files
  • 20
    Jun 20th
    15 Files
  • 21
    Jun 21st
    15 Files
  • 22
    Jun 22nd
    2 Files
  • 23
    Jun 23rd
    1 Files
  • 24
    Jun 24th
    23 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2019 Packet Storm. All rights reserved.

Security Services
Hosting By