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
