IJG jpeg6b / libjpeg-turbo Uninitialized Memory

2013-11-13 / 2014-08-05
Risk: High
Local: No
Remote: Yes

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

References:

http://lcamtuf.blogspot.com/2014/08/a-bit-more-about-american-fuzzy-lop.html
http://code.google.com/p/american-fuzzy-lop/
http://lcamtuf.coredump.cx/jpeg_leak/
http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg
http://bugs.ghostscript.com/show_bug.cgi?id=686980


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2019, cxsecurity.com

 

Back to Top