exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

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
SHA-256 | 75281af87c2ac01e67120a1b37a4356f62199b948183ba8069556c239c29df05

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):

http://lcamtuf.coredump.cx/jpeg_leak/

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:

http://bugs.ghostscript.com/show_bug.cgi?id=686980

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:

http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg

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/

/mz


Login or Register to add favorites

File Archive:

January 2023

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By
Rokasec
close