Bug 1221249 (CVE-2015-3885) - CVE-2015-3885 dcraw: input sanitization flaw leading to buffer overflow
Summary: CVE-2015-3885 dcraw: input sanitization flaw leading to buffer overflow
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2015-3885
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20150511,reported=2...
Depends On: 1221250 1221251 1221252 1221253 1221254 1221255 1221256 1221257 1221258 1221259 1222824
Blocks: 1221263
TreeView+ depends on / blocked
 
Reported: 2015-05-13 14:57 UTC by Martin Prpič
Modified: 2019-06-11 11:13 UTC (History)
27 users (show)

Fixed In Version: LibRaw 0.16.1, LibRaw 0.17-Alpha3
Doc Type: Bug Fix
Doc Text:
A flaw was discovered in the way dcraw processed Raw images. An attacker could use this flaw to cause dcraw to crash by tricking a user into processing a specially crafted Raw image file.
Clone Of:
Environment:
Last Closed: 2019-06-08 02:41:10 UTC


Attachments (Terms of Use)
Proposed patch for CVE-2015-3885 (1.39 KB, patch)
2015-05-19 09:57 UTC, Nils Philippsen
no flags Details | Diff

Description Martin Prpič 2015-05-13 14:57:06 UTC
An integer overflow flaw, leading to a buffer overflow, was found in the way dcraw, a photo decoder, parsed certain raw images. A specially crafted raw image file could cause an application using dcraw to crash.

This vulnerability also affects other raw image parsing libraries that share dcraw's code: UFRaw, LibRaw, RawTherapee, CxImage, Rawstudio, Kodi, ExactImage.

Upstream patches:

https://github.com/LibRaw/LibRaw/commit/4606c28f494a750892c5c1ac7903e62dd1c6fdb5
https://github.com/rawstudio/rawstudio/commit/983bda1f0fa5fa86884381208274198a620f006e

External References:

http://www.ocert.org/advisories/ocert-2015-006.html

Comment 1 Martin Prpič 2015-05-13 14:59:37 UTC
Created mingw-LibRaw tracking bugs for this issue:

Affects: fedora-all [bug 1221254]

Comment 2 Martin Prpič 2015-05-13 14:59:43 UTC
Created dcraw tracking bugs for this issue:

Affects: fedora-all [bug 1221251]

Comment 3 Martin Prpič 2015-05-13 14:59:47 UTC
Created libkdcraw tracking bugs for this issue:

Affects: fedora-all [bug 1221252]
Affects: epel-5 [bug 1221259]

Comment 4 Martin Prpič 2015-05-13 14:59:51 UTC
Created libraw1394 tracking bugs for this issue:

Affects: fedora-all [bug 1221253]

Comment 5 Martin Prpič 2015-05-13 14:59:54 UTC
Created ufraw tracking bugs for this issue:

Affects: fedora-all [bug 1221258]

Comment 6 Martin Prpič 2015-05-13 14:59:57 UTC
Created LibRaw tracking bugs for this issue:

Affects: fedora-all [bug 1221250]

Comment 7 Martin Prpič 2015-05-13 15:00:00 UTC
Created mingw-cximage tracking bugs for this issue:

Affects: fedora-all [bug 1221255]

Comment 8 Martin Prpič 2015-05-13 15:00:04 UTC
Created rawstudio tracking bugs for this issue:

Affects: fedora-all [bug 1221256]

Comment 9 Martin Prpič 2015-05-13 15:00:07 UTC
Created rawtherapee tracking bugs for this issue:

Affects: fedora-all [bug 1221257]

Comment 10 Stefan Cornelius 2015-05-15 12:43:31 UTC
The problem is a mix of an integer underflow combined with a type problem in what dcraw calls the ljpeg_start() function (haven't checked the other sources yet, so I'm not sure how much they differ in that regard).

Code snippets:
>int c, tag, len;
>uchar data[0x10000];

>fread (data, 2, 2, ifp);
>tag =  data[0] << 8 | data[1];
>len = (data[2] << 8 | data[3]) - 2;
>if (tag <= 0xff00) return 0;
>fread (data, 1, len, ifp);


The first part of the problem is that "len = (data[2] << 8 | data[3]) - 2" can underflow, wrapping "len" into a negative number. fread() expects size_t type for the size, so this will be casted into a large positive number, exceeding the 0x10000 byte "data" buffer, potentially leading to a stack-based buffer overflow.

On 64bit F21, I can't trigger a buffer overflow because fread() will fail, returning EPERM errors. It works without a problem on 32bit, although it's mitigated by fortify source (edit: I accidentally wrote stack canaries before but meant to say fortify source.)

Comment 11 Nils Philippsen 2015-05-15 14:28:00 UTC
Hmm. I'm not sure if simply changing the type of len to ushort (like in the upstream patches) will fix the issue completely:

If data[2] and data[3] are zero, len would be -2, or 65534 in unsigned short int, which could overflow data[] as well.

What do you think?

Comment 12 Nils Philippsen 2015-05-15 15:08:58 UTC
Never mind, data[] is 64k in size. I still think it'd be a good idea to simply bail out if data[3]==0 and data[4]<2 because I'd expect the rest of the data to be corrupt as well. Does that make sense?

Comment 13 Stefan Cornelius 2015-05-15 15:33:55 UTC
(In reply to Nils Philippsen from comment #12)
> Never mind, data[] is 64k in size. I still think it'd be a good idea to
> simply bail out if data[3]==0 and data[4]<2 because I'd expect the rest of
> the data to be corrupt as well. Does that make sense?

I've noticed that I've accidentally stated the wrong thing in comment 10. It's not stack canaries, it's fortify source, so the overflow is hard-countered and should not be exploitable, anyways (as long as it's compiled in everywhere, didn't check all our packages yet). I'll do a quick patched test build and see if the assembly looks reasonable when using ushort and if it stops the reproducer.

Comment 14 Stefan Cornelius 2015-05-15 16:11:38 UTC
From a patched 32bit build:
 8052c27:	0f b7 d8             	movzx  ebx,ax
 8052c2a:	a1 34 2a 0f 08       	mov    eax,ds:0x80f2a34
 8052c2f:	89 44 24 10          	mov    DWORD PTR [esp+0x10],eax
 8052c33:	89 5c 24 0c          	mov    DWORD PTR [esp+0xc],ebx
 8052c37:	c7 44 24 08 01 00 00 	mov    DWORD PTR [esp+0x8],0x1
 8052c3e:	00 
 8052c3f:	c7 44 24 04 00 00 01 	mov    DWORD PTR [esp+0x4],0x10000
 8052c46:	00 
 8052c47:	89 3c 24             	mov    DWORD PTR [esp],edi
 8052c4a:	e8 e1 6b ff ff       	call   8049830 <__fread_chk@plt>

the movzx ebx, ax should be fine. 0x0000ffff should be the max possible value ebx can have, so we'll never be able to overflow 0x10000. 64bit will probably do something similar.

(In reply to Nils Philippsen from comment #12)
> simply bail out if data[3]==0 and data[4]<2 because I'd expect the rest of
> the data to be corrupt as well. Does that make sense?

You mean data[2] and data[3], right? Instead of checking the data[] fields, I would calculate len first and then check it sanity, just so that it's more obvious in the source code.
But I have no clue about the file format or if there are cameras known to produce wrong files. Maybe upstream can answer that?

Comment 15 Nils Philippsen 2015-05-18 09:25:34 UTC
(In reply to Stefan Cornelius from comment #14)
> (In reply to Nils Philippsen from comment #12)
> > simply bail out if data[3]==0 and data[4]<2 because I'd expect the rest of
> > the data to be corrupt as well. Does that make sense?
> 
> You mean data[2] and data[3], right?

Yes, of course.

> Instead of checking the data[] fields, I would calculate len first and then check it sanity, just so that it's more
> obvious in the source code.

Makes sense.

> But I have no clue about the file format or if there are cameras known to
> produce wrong files. Maybe upstream can answer that?

I don't know. I don't see how wrong (corrupted) files are supposed to yield a desirable result, it would have to be an extremely unlikely constellation of mistakes cancelling each other out.

Comment 16 Nils Philippsen 2015-05-18 10:55:20 UTC
FWIW it seems as if netpbm(-progs) is affected as well. It contains the "cameratopam" tool, which is largely a copy of the relevant parts of dcraw (as stated in the file COPYRIGHT).

Comment 17 Florian Weimer 2015-05-19 09:05:49 UTC
Created netpbm tracking bugs for this issue:

Affects: fedora-all [bug 1222824]

Comment 18 Nils Philippsen 2015-05-19 09:57:15 UTC
Created attachment 1027072 [details]
Proposed patch for CVE-2015-3885

This is the patch which I'll submit upstream.

Compared to the patches in LibRaw, rawstudio, it additionally checks if the specified length of the data to be read is valid and bails out early if not.

Comment 19 Stefan Cornelius 2015-05-19 11:07:33 UTC
This issue affects the versions of dcraw and netpbm as shipped with Red Hat Enterprise Linux 5, 6, and 7. This issue also affects LibRaw and libkdcraw as shipped with Red Hat Enterprise Linux 7. Red Hat Product Security has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Comment 20 Petr Hracek 2015-05-19 11:20:50 UTC
Yeah, affected file is http://sourceforge.net/p/netpbm/code/HEAD/tree/advanced/converter/other/cameratopam/ljpeg.c

I am going to inform upstream.

Comment 24 Fedora Update System 2015-05-26 03:15:30 UTC
mingw-LibRaw-0.16.2-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 25 Fedora Update System 2015-05-26 03:20:19 UTC
mingw-LibRaw-0.16.1-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 Fedora Update System 2015-05-26 03:42:38 UTC
mingw-LibRaw-0.15.4-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Fedora Update System 2015-05-28 12:05:13 UTC
mingw-LibRaw-0.16.2-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 28 Fedora Update System 2015-06-05 23:43:43 UTC
ufraw-0.21-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2015-06-05 23:45:36 UTC
dcraw-9.25.0-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 Fedora Update System 2015-06-05 23:50:24 UTC
ufraw-0.21-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 31 Fedora Update System 2015-06-05 23:58:59 UTC
ufraw-0.21-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2015-06-06 00:07:42 UTC
dcraw-9.25.0-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 33 Fedora Update System 2015-06-06 00:13:04 UTC
dcraw-9.25.0-2.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Fedora Update System 2015-07-18 01:58:39 UTC
rawstudio-2.1-0.1.20150511git983bda1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 35 Fedora Update System 2015-07-18 02:03:07 UTC
rawstudio-2.1-0.1.20150511git983bda1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 36 Sergio Monteiro Basto 2017-04-16 01:22:05 UTC
with EOL of https://bugzilla.redhat.com/show_bug.cgi?id=1221259 we can close this bug because all bugs that depend are closed .

Comment 37 Martin Prpič 2017-04-18 08:12:24 UTC
(In reply to Sergio Monteiro Basto from comment #36)
> with EOL of https://bugzilla.redhat.com/show_bug.cgi?id=1221259 we can close
> this bug because all bugs that depend are closed .

Please don't close bugs filed against the "vulnerability" component. They track the issue across all of Red Hat's products, not just those that have bugs filed in depends.

Comment 38 Sergio Monteiro Basto 2017-04-19 10:27:57 UTC
So let me know what we still need to be fixed  ? , please

Comment 39 Sergio Monteiro Basto 2017-04-19 10:33:10 UTC
So let me know, what we still need to fix ? , please
or 
So let me know, what still need to be fixed ? please

Comment 40 Martin Prpič 2017-04-19 16:01:29 UTC
(In reply to Sergio Monteiro Basto from comment #39)
> So let me know, what we still need to fix ? , please
> or 
> So let me know, what still need to be fixed ? please

Nothing else from Fedora/EPEL side. This bug also tracks the issue in RHEL where it has not been addressed, thus this bug should stay open. You, as a maintainer of the related package in Fedora/EPEL, should only worry about the tracking bugs filed against Fedora or EPEL. Bugs filed against the "vulnerability" component can be thought of as metabugs that simply hold general information about the issue, not necessarily its resolution in particular products. Thanks!


Note You need to log in before you can comment on or make changes to this bug.