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