Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 491152 (CVE-2013-6629) - <media-libs/jpeg-{6b-r12,8d-r1,9c}: uninitialized memory read (CVE-2013-6629)
Summary: <media-libs/jpeg-{6b-r12,8d-r1,9c}: uninitialized memory read (CVE-2013-6629)
Status: RESOLVED FIXED
Alias: CVE-2013-6629
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: http://googlechromereleases.blogspot....
Whiteboard: A4 [noglsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-13 09:12 UTC by Agostino Sarubbo
Modified: 2018-03-26 22:29 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-11-13 09:12:31 UTC
From $URL:

[258723] Medium CVE-2013-6629: Read of uninitialized memory in libjpeg and libjpeg-turbo. Credit to Michal Zalewski of Google.
Comment 1 Agostino Sarubbo gentoo-dev 2013-11-18 16:42:38 UTC
The commit from the chromium repo, not applied to upstream:

http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/jdmarker.c?r1=228354&r2=228353&pathrev=228354
Comment 2 Samuel Damashek (RETIRED) gentoo-dev 2014-01-01 06:25:41 UTC
=media-libs/jpeg-6b is vulnerable, and all versions in the 62 slot are 6b versions. icedtea-bin, and possibly other packages, depends on the 62 slot.
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2014-01-24 12:08:51 UTC
(In reply to Agostino Sarubbo from comment #1)
> The commit from the chromium repo, not applied to upstream:
> 
> http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/jdmarker.
> c?r1=228354&r2=228353&pathrev=228354

The CVE is vague on specific version scale for jpeg...?

The patch applies to jpeg-8d, is fixed at jpeg-8d-r1 in Portage now
The patch applies to jpeg-9-r1, is not fixed because it causes a build failure

Was this already fixed differently for jpeg-9 at upstream?
Comment 4 Samuli Suominen (RETIRED) gentoo-dev 2014-01-24 12:15:16 UTC
The patch that went into media-libs/libjpeg-turbo also fixed CVE-2013-6630. Is that not valid for media-libs/jpeg?
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2014-01-24 12:16:23 UTC
(In reply to Samuli Suominen from comment #4)
> The patch that went into media-libs/libjpeg-turbo also fixed CVE-2013-6630.
> Is that not valid for media-libs/jpeg?

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/libjpeg-turbo/files/libjpeg-turbo-1.3.0-CVE-2013-6629-and-6630.patch?view=log
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2014-01-24 12:21:07 UTC
I'm going to handle stabilization in bug 491150 and leave this bug open because there remain unanswered questions.
I've package.masked >=media-libs/jpeg-9 in tree pending both, on the bugs in Tracker bug 479818 and the resolution of this bug.

- Does jpeg-6b, 8d, 9 need a patch for CVE-2013-6630?
- Does jpeg-9 need a patch for this bug? The one mentioned here causes build failure.
Comment 7 Samuli Suominen (RETIRED) gentoo-dev 2014-01-27 13:12:48 UTC
jpeg-9a was released and is in Portage without any patches. this still apply?
Comment 8 Thomas Deutschmann (RETIRED) gentoo-dev 2016-11-23 18:43:02 UTC
@ Maintainer(s):

=media-libs/jpeg-6b-r12: Safe, applies jpeg-8d-CVE-2013-6629.patch

=media-libs/jpeg-8d-r1 and =media-libs/jpeg-8d-r2: Safe, applies jpeg-8d-CVE-2013-6629.patch

=media-libs/jpeg-9a and =media-libs/jpeg-9b are both *vulnerable*. Please tell us if you are going to apply the patch to v9 as well or what action you are going to take.
Comment 9 Aaron Bauman (RETIRED) gentoo-dev 2017-02-01 01:20:13 UTC
(In reply to Thomas Deutschmann from comment #8)
> @ Maintainer(s):
> 
> =media-libs/jpeg-6b-r12: Safe, applies jpeg-8d-CVE-2013-6629.patch
> 
> =media-libs/jpeg-8d-r1 and =media-libs/jpeg-8d-r2: Safe, applies
> jpeg-8d-CVE-2013-6629.patch
> 
> =media-libs/jpeg-9a and =media-libs/jpeg-9b are both *vulnerable*. Please
> tell us if you are going to apply the patch to v9 as well or what action you
> are going to take.

@maintainer(s), ping.
Comment 10 Yury German Gentoo Infrastructure gentoo-dev 2017-05-05 00:10:01 UTC
Summary: The get_sos 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.
 Published: 2013-11-19T04:50:56.000Z
Comment 11 Aaron Bauman (RETIRED) gentoo-dev 2018-03-26 17:48:41 UTC
(In reply to Aaron Bauman from comment #9)
> (In reply to Thomas Deutschmann from comment #8)
> > @ Maintainer(s):
> > 
> > =media-libs/jpeg-6b-r12: Safe, applies jpeg-8d-CVE-2013-6629.patch
> > 
> > =media-libs/jpeg-8d-r1 and =media-libs/jpeg-8d-r2: Safe, applies
> > jpeg-8d-CVE-2013-6629.patch
> > 
> > =media-libs/jpeg-9a and =media-libs/jpeg-9b are both *vulnerable*. Please
> > tell us if you are going to apply the patch to v9 as well or what action you
> > are going to take.
> 
> @maintainer(s), ping.

The same fixes are included in the jpeg9c source.  The code layout is slightly different as the code base has grown, but the same protections are in place.

All sources in the tree are now patched.
Comment 12 Aaron Bauman (RETIRED) gentoo-dev 2018-03-26 22:29:51 UTC
After further review of the CVE's this is being downgraded to an A4.  As such, we will not release a GLSA.

GLSA Vote: No.