[Slackware-security] libjpeg

mancha · 11-24-2013, 04:53 AM

It has been discovered there are problems (with security implications) in the way segments following Start Of Scan and Define Huffman Table markers are read in libjpeg-turbo (CVE-2013-6629 & CVE-2013-6630).

IJG's jpeg library, as shipped by Slackware, is also vulnerable to CVE-2013-6629.

I've put together a patch (sig) that applies to jpegsrc (v8a through v8d as well as v6b) so can be used on Slackware 12.1 through -current.

--mancha

samac · 11-24-2013, 04:56 AM

Have you submitted the patch to Patrick Volkerding?

samac

GazL · 11-24-2013, 05:51 AM

Thanks mancha. What a complete balls-up: Ghostscript guys find it in 2004. IJG eventually fix it in V9 in january this year but failed to realise that it's a security issue and neither announced it as such nor back-ported it to 8d which they released at the same time. That is, I hope they "didn't realise", rather than just being too embarrassed to admit that they'd sat on a security issue for over 8 years.

Bet the NSA have been making good use of this one.

irgunII · 11-24-2013, 07:53 AM

Forgive the ignorance...how does one install a 'patch'?

Didier Spaier · 11-24-2013, 08:02 AM

man patch

mancha · 11-24-2013, 11:40 AM

@GazL:

This issue certainly has an interesting history as you've pointed out. Given your comment, I should mention I decided to patch libjpeg following Google Chrome and libjpeg-turbo's example of rejecting JPEGs that violate SOS specs. The resulting behavior will be consistent with other programs which use the optimized jpeg-turbo library such as Mozilla's Firefox. ICJ v9 took a different approach and adopted Ghostscript's 2004 solution which papers over out-of-spec JPEGs by creating "fake" component IDs.

I've made a PoC JPEG available at: CVE-2013-6629.jpg

On Slackware, you can quickly see the difference in behavior pre and post patch using Imagemagick's display (which links libjpeg):

Code:

$ display CVE-2013-6629.jpg

@irgunII:

To apply this you would: 1) download the libjpeg source files from your favorite Slackware mirror or copy them from your source media; 2) download my patch to the same directory; 3) edit libjpeg.SlackBuild by adding the following line (in red) just before the configure block:

Code:

patch -p1 --verbose < $CWD/jpeg-8_CVE-2013-6629.diff || exit 1

export CFLAGS="$SLKCFLAGS"
./configure \
  --prefix=/usr \
  --mandir=/usr/man

4) rebuild the package and upgradepkg --reinstall.

--mancha

irgunII · 11-24-2013, 01:09 PM

Thanks mancha!

@Didier - I'd already done that but 'man patch' was far too confusing for this dummy!

number22 · 11-24-2013, 01:49 PM

Thanks for this head up, security is always main concern. should i replace libjpeg with libjpeg-turbo?
well, the patch works with libjpeg-turbo.

GazL · 11-24-2013, 04:02 PM

Quote:

Originally Posted by mancha

I should mention I decided to patch libjpeg following Google Chrome and libjpeg-turbo's example of rejecting JPEGs that violate SOS specs. The resulting behavior will be consistent with other programs which use the optimized jpeg-turbo library such as Mozilla's Firefox. ICJ v9 took a different approach and adopted Ghostscript's 2004 solution which papers over out-of-spec JPEGs by creating "fake" component IDs.

IMO you went the right way.

Perhaps a move to libjpeg-turbo is something Pat should consider for this development cycle. It's likely to require a few rebuilds though.

cwizardone · 11-24-2013, 05:02 PM

Quote:

Originally Posted by mancha

@GazL:....@irgunII:

To apply this you would: 1) download the libjpeg source files from your favorite Slackware mirror or copy them from your source media; 2) download my patch to the same directory; 3) edit libjpeg.SlackBuild by adding the following line (in red) just before the configure block:

Code:

patch -p1 --verbose < $CWD/jpeg-8_CVE-2013-6629.diff || exit 1

export CFLAGS="$SLKCFLAGS"
./configure \
  --prefix=/usr \
  --mandir=/usr/man

4) rebuild the package and upgradepkg --reinstall.

--mancha

I must be doing something wrong... wouldn't be the first time.

I've tried the instructions and get the follow error,

Quote:

jpeg-8a/makejmak.vc6
Hmm...patch unexpectedly ends in middle of line
I can't seem to find a patch in there anywhere.
patch: **** Only garbage was found in the patch input.

mancha · 11-24-2013, 06:27 PM

Quote:

Originally Posted by number22

Thanks for this head up, security is always main concern. should i replace libjpeg with libjpeg-turbo?

If you patch Slackware's libjpeg you will be fine. However, if you're interested in testing libjpeg-turbo for performance reasons see my comment to GazL below.

Quote:

Originally Posted by GazL

Perhaps a move to libjpeg-turbo is something Pat should consider for this development cycle.

libjpeg-turbo advertises compatibility with ICJ's libjpeg (v6 & v8). So I slapped together the necessary build files and placed them at the slackdepot so you and others interested can give it a test drive. As far as I can tell it's a drop-in replacement (removepkg libjpeg; installpkg libjpeg-turbo). I am running it now and nothing's broken so far.

The turbo folks present results showing libjpeg-turbo outperforming libjpeg-v6b by 2-5 times and libjpeg-v8d by 2-6 times (see: http://www.libjpeg-turbo.org/About/Performance). I'll try to benchmark locally in the coming days to see what kinds of gains I get on my HW.

One thing which immediately comes to mind that would benefit from such performance bumps is VNC with JPEG compression/decompression.

If those who test libjpeg-turbo consistently have positive experiences, it would make a good candidate for Pat to consider for a future release.

--mancha

PS @cwizardone, hrmmm, not sure what you're doing wrong. Try building Pat's version (no patch). If that works, verify your download of my patch. I just did it here from scratch again and it works fine.

glorsplitz · 11-24-2013, 07:44 PM

Thanks mancha, I just did it from scratch and it worked fine.

GazL · 11-25-2013, 06:12 AM

Interesting, I knew it was ABI compatible with v6, I hadn't realised it'd work as a drop-in for v8 though. Thanks Mancha, I'm definitely going to give this a go.

Speek · 11-25-2013, 06:18 AM

Hi mancha!
Your SlackBuild results in a package that puts some files in /usr/share/doc:

Code:

usr/share/doc/example.c
usr/share/doc/wizard.txt
usr/share/doc/usage.txt
usr/share/doc/structure.txt
usr/share/doc/libjpeg.txt
usr/share/doc/README-turbo.txt
usr/share/doc/README

There is no configure option to change this. But it can be fixed by using this "make install" command:

Code:

make docdir=/usr/doc/libjpeg-turbo-$VERSION \
 exampledir=/usr/doc/libjpeg-turbo-$VERSION install DESTDIR=$PKG

mancha · 11-25-2013, 07:14 AM

Speek: Thanks for catching that. New slackbuild is up which places all docs in /usr/doc/libjpeg-turbo-$VERSION.

--mancha