Bug 1344732

Summary: libjpeg: Out-of-Bounds Read via unusually long Blocks in MCU
Product: [Other] Security Response Reporter: Andrej Nemec <anemec>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: alonbl, bmcclain, cfergeau, dblechte, dkholia, eedri, erik-fedora, gklein, klember, lsurette, mgoldboi, michal.skrivanek, negativo17, phracek, rbalakri, rh-spice-bugs, rjones, sardella, sherold, srevivo, tburke, ykaul, ylavi
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
An issue in the accelerated Huffman decoder in libjpeg-turbo was found that could have caused the decoder to read past the end of the input buffer when a malformed, specially-crafted JPEG image was being decompressed.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-13 08:10:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1344218, 1344220    
Bug Blocks: 1344217    

Description Andrej Nemec 2016-06-10 14:50:50 UTC 
A  performance optimization for simple and common cases entails that decode_mcu() calls decode_mcu_fast() to decode a single MCU. A greater speed of the latter function is attributed to the fact that it makes some assumptions that the slower decoding function is not allowed to make. One of these assumptions is that enough data is available in the input buffer, so decode_mcu_fast() does not perform bounds’ checks when reading from the input buffer (via GET_BYTE). Instead, decode_mcu() is responsible for ensuring that the input buffer is big enough for the worst case scenario.

However, the problem is that the estimate does not actually cover the worst case possibility. In specifics, the decode_mcu() assumes a maximum of 128 bytes per block while, actually, blocks with around 438 bytes in length can be crafted. (Note that these 438 bytes are not a proper worst-case estimate but rather just the length the PoC generates.)

External references:

https://wiki.mozilla.org/images/7/77/Libjpeg-turbo-report.pdf

Upstream fix:

https://github.com/libjpeg-turbo/libjpeg-turbo/commit/0463f7c9aad060fcd56e98d025ce16185279e2bc
Comment 1 Andrej Nemec 2016-06-10 14:52:53 UTC 
Created libjpeg-turbo tracking bugs for this issue:

Affects: fedora-all [bug 1344218]
Comment 2 Andrej Nemec 2016-06-10 14:53:04 UTC 
Created mingw-libjpeg-turbo tracking bugs for this issue:

Affects: fedora-all [bug 1344220]