Thanks for the answer. It is a rather odd decision to ignore an existing fix for CVE-2013-1438. This also means that dcraw cannot be used when any untrusted person has access (or he can DoS a service).
Rene Rebe, is it possible to disable dcraw support in the perl/php/python bindings of exactimage to work around this problem on webservices? 2016-03-05 2:34 GMT+00:00 <[email protected]>: > Hi Guys, > > CVE-2015-3885 was fixed in v9.26 and CVE-2015-8366 will > be fixed in v9.27. Overrunning an automatic array is how most > hijacks happen, and overrunning a malloc'd buffer is probably > not good either. > > CVE-2013-1438 seems designed to prevent dcraw from entering > an infinite or very time-consuming loop. I'm not interested in > this because there are infinitely many ways to create a loop in > a TIFF file, and solving the Halting Problem is beyond the scope > of dcraw. > Dave Coffin 3/4/2016 > > On Sat, Feb 27, 2016 at 02:28:18PM +0000, Charlemagne Lasse wrote: >> Hi, >> >> it looks like there are a number of CVE against dcraw. All of them were >> fixed in the downstream project libRAW but none of them were fixed by >> you in the upstream project dcraw. When can we expect that these are >> fixed in dcraw? The list of CVE's I know about are: >> >> CVE-2015-8366 >> https://github.com/LibRaw/LibRaw/commit/89d065424f09b788f443734d44857289489ca9e2 >> >> CVE-2015-3885 >> https://bugzilla.redhat.com/attachment.cgi?id=1027072 >> >> CVE-2013-1438 >> https://sourceforge.net/p/ufraw/bugs/361/attachment/0001-CVE-2013-1438-fix-various-security-issues.patch >> >> Several other downstream projects may still be affected. I've Cc'ed the >> ones which I know >> >> darktable >> exactimage >> kodi/xbmc >> rawstudio >> rawtherapee >> ufraw >> >> Thanks ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe exact-image
