CVE-2013-6629: Infoleak
It was reported [1],[2] that libjpeg and libjpeg-turbo would use uninitialized memory when decoding images with missing SOS data for the luminance component (Y) in the presence of valid chroma data (Cr, Cb). An example proof of concept that can be viewed in a browser is also available [3].
This was reported and fixed initially in Google Chrome/Chromium; it does not appear to be fixed in upstream libjpeg or libjpeg-turbo yet. Patches to the third party source in Chromium for libjpeg [4] and libjpeg-turbo [5] however are available.
[1] http://googlechromereleases.blogspot.de/2013/11/stable-channel-update.html [2] http://packetstormsecurity.com/files/123989/IJG-jpeg6b-libjpeg-turbo-Uninitialized-Memory.html [3] http://lcamtuf.coredump.cx/jpegleak/ [4] http://src.chromium.org/viewvc/chrome/trunk/src/thirdparty/libjpeg/jdmarker.c?r1=228354&r2=228353&pathrev=228354 [5] http://src.chromium.org/viewvc/chrome/trunk/deps/thirdparty/libjpegturbo/jdmarker.c?r1=228381&r2=228380&pathrev=228381
Other sources
The getsos function in jdmarker.c in (1) libjpeg 6b and (2) libjpeg-turbo through 1.3.0, as used in Google Chrome before 31.0.1650.48, Ghostscript, and other products, does not check for certain duplications of component data during the reading of segments that follow Start Of Scan (SOS) JPEG markers, which allows remote attackers to obtain sensitive information from uninitialized memory locations via a crafted JPEG image.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.7.0-oracle-1:1.7.0.55-1jpp.2.el5_10 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.6.0-sun-1:1.6.0.75-1jpp.3.el5_10 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.7.0-oracle-1:1.7.0.55-1jpp.1.el6_5 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.6.0-sun-1:1.6.0.75-1jpp.1.el6_5 - Upgrade
Upgrade
redhat/libjpeg-turboto a version that resolves this vulnerability.Fixed in 0:1.2.1-3.el6_5 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.6.0-ibm-1:1.6.0.16.0-1jpp.1.el5 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.7.0-ibm-1:1.7.0.7.0-1jpp.1.el5_10 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.6.0-ibm-1:1.6.0.16.0-1jpp.1.el5_10 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.5.0-ibm-1:1.5.0.16.6-1jpp.1.el5_10 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.7.0-ibm-1:1.7.0.7.0-1jpp.1.el6_5 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.6.0-ibm-1:1.6.0.16.0-1jpp.1.el6_5 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.5.0-ibm-1:1.5.0.16.6-1jpp.1.el6_5 - Upgrade
Upgrade
redhat/javato a version that resolves this vulnerability.Fixed in 1.7.1-ibm-1:1.7.1.1.0-1jpp.2.el7_0
Event History
Parent advisories
This vulnerability appears in the following advisories.
Frequently Asked Questions
What is the severity of CVE-2013-6629?
The severity of CVE-2013-6629 is rated as moderate, but it can lead to potential security issues due to uninitialized memory usage.
How do I fix CVE-2013-6629?
To fix CVE-2013-6629, update the affected software to the recommended versions such as libjpeg-turbo 1.2.1-3.el6_5 or the respective patched versions for Java.
What software is affected by CVE-2013-6629?
CVE-2013-6629 affects several packages, including libjpeg-turbo and various Java versions from Red Hat.
Can exploiting CVE-2013-6629 lead to information leakage?
Yes, exploiting CVE-2013-6629 could potentially lead to information leakage due to the way uninitialized memory is handled.
Are there known exploits for CVE-2013-6629?
While there is a proof of concept available, specific public exploits for CVE-2013-6629 have not been widely reported.