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
Created mingw-LibRaw tracking bugs for this issue: Affects: fedora-all [bug 1221254]
Created dcraw tracking bugs for this issue: Affects: fedora-all [bug 1221251]
Created libkdcraw tracking bugs for this issue: Affects: fedora-all [bug 1221252] Affects: epel-5 [bug 1221259]
Created libraw1394 tracking bugs for this issue: Affects: fedora-all [bug 1221253]
Created ufraw tracking bugs for this issue: Affects: fedora-all [bug 1221258]
Created LibRaw tracking bugs for this issue: Affects: fedora-all [bug 1221250]
Created mingw-cximage tracking bugs for this issue: Affects: fedora-all [bug 1221255]
Created rawstudio tracking bugs for this issue: Affects: fedora-all [bug 1221256]
Created rawtherapee tracking bugs for this issue: Affects: fedora-all [bug 1221257]
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.)
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?
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?
(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.
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?
(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.
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).
Created netpbm tracking bugs for this issue: Affects: fedora-all [bug 1222824]
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.
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/.
Yeah, affected file is http://sourceforge.net/p/netpbm/code/HEAD/tree/advanced/converter/other/cameratopam/ljpeg.c I am going to inform upstream.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
with EOL of https://bugzilla.redhat.com/show_bug.cgi?id=1221259 we can close this bug because all bugs that depend are closed .
(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.
So let me know what we still need to be fixed ? , please
So let me know, what we still need to fix ? , please or So let me know, what still need to be fixed ? please
(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!