BugTraq
bugs in IJG jpeg6b & libjpeg-turbo Dec 04 2013 06:45AM
Michal Zalewski (lcamtuf coredump cx)
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

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus