exploit the possibilities

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/


Login or Register to add favorites

File Archive:

October 2021

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

Top Authors In Last 30 Days

File Tags


packet storm

© 2020 Packet Storm. All rights reserved.

Security Services
Hosting By