[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#786919: marked as done (wheezy-pu: package exactimage/0.8.5-5+deb7u4)



Your message dated Sat, 05 Sep 2015 14:33:54 +0100
with message-id <1441460034.2151.33.camel@adam-barratt.org.uk>
and subject line Closing bugs for 7.9
has caused the Debian Bug report #786919,
regarding wheezy-pu: package exactimage/0.8.5-5+deb7u4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
786919: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786919
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian.org@packages.debian.org
Usertags: pu


I'd like to upload the attached patch to oldstable-proposed-updates to fix 
#786785 (CVE-2015-3885). The security team marked this one as no-dsa but asked 
me to propose the fixes for a point release. Would this be ok? The change 
matches exactimage 0.9.1-5 + the backported "dependency" patch to get the 
ljpeg_start result validation after the ljpeg_start call. The latter change 
was in unstable before 0.9.1-5 and is required to test the patch.



Just some information to the patch (taken from my mail to the security team):

The patch was not tested against any official "special crafted image" because
none was provided with the CVE. Instead a raw image was downloaded [1] and
modified to have the len at 0x13800+0x13801 set to 0. This causes an underflow
+ endless loop in the original version of dcraw. But this also showed that the
wheezy/jessie version of exactimage did ljpeg_start() + the jh.*
validation in the wrong order and thus made the jh.* validation read
"uninintialized" data from the stack. This additional problem was fixed in an
extra patch "draw_jpeg_fix.patch". The original dcraw problem could be
reproduced after that jh.* patch was applied without the CVE fix. The test was 
run via:

$ econvert -i RAW_CANON_EOS_5DMARK3.CR2 -o test.png

The versions of exactimage with both patches doesn't crash or hang anymore
when testing with the modified RAW_CANON_EOS_5DMARK3.CR2.

The patch is the one from rawstudio with a minor context adjustment to make it
apply in the wheezy version of exactimage.

Kind regards,
	Sven

[1] http://www.rawsamples.ch/raws/canon/RAW_CANON_EOS_5DMARK3.CR2
diff -Nru exactimage-0.8.5/debian/changelog exactimage-0.8.5/debian/changelog
--- exactimage-0.8.5/debian/changelog	2013-09-10 00:06:30.000000000 +0200
+++ exactimage-0.8.5/debian/changelog	2015-05-25 19:28:21.000000000 +0200
@@ -1,3 +1,14 @@
+exactimage (0.8.5-5+deb7u4) wheezy; urgency=medium
+
+  * Fix CVE-2015-3885: Integer overflow in the ljpeg_start function in dcraw
+  * debian/patches:
+    - Add CVE-2015-3885.patch, Avoid overflow in ljpeg_start()
+      (Closes: #786785)
+    - Add draw_jpeg_fix.patch, Fix execution order of ljpeg_start() and
+      result check
+
+ -- Sven Eckelmann <sven@narfation.org>  Mon, 25 May 2015 17:57:23 +0200
+
 exactimage (0.8.5-5+deb7u3) stable-security; urgency=high
 
   * Add debian/patches/CVE-2013-1441.patch,
diff -Nru exactimage-0.8.5/debian/patches/CVE-2015-3885.patch exactimage-0.8.5/debian/patches/CVE-2015-3885.patch
--- exactimage-0.8.5/debian/patches/CVE-2015-3885.patch	1970-01-01 01:00:00.000000000 +0100
+++ exactimage-0.8.5/debian/patches/CVE-2015-3885.patch	2015-05-25 19:28:21.000000000 +0200
@@ -0,0 +1,19 @@
+Description: Avoid overflow in ljpeg_start().
+Author: Anders Brander <anders@brander.dk>
+Origin: backport, https://github.com/rawstudio/rawstudio/commit/983bda1f0fa5fa86884381208274198a620f006e
+
+---
+diff --git a/codecs/dcraw.h b/codecs/dcraw.h
+index 0436d34a40ee515a65513a7217dec97b3cde8946..8f56add58755843ace29b71c659b6173569f8e9a 100644
+--- a/codecs/dcraw.h
++++ b/codecs/dcraw.h
+@@ -836,7 +836,8 @@ struct jhead {
+ 
+ int CLASS ljpeg_start (struct jhead *jh, int info_only)
+ {
+-  int c, tag, len;
++  int c, tag;
++  ushort len;
+   uchar data[0x10000], *dp;
+ 
+   init_decoder();
diff -Nru exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch
--- exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch	1970-01-01 01:00:00.000000000 +0100
+++ exactimage-0.8.5/debian/patches/draw_jpeg_fix.patch	2015-05-25 19:28:21.000000000 +0200
@@ -0,0 +1,24 @@
+Description: Fix execution order of ljpeg_start() and result check
+Author: René Rebe <rene@exactcode.de>
+
+---
+diff --git a/codecs/dcraw.h b/codecs/dcraw.h
+index 8f56add58755843ace29b71c659b6173569f8e9a..66e32cf185f681657edda3c372b50b1d7b24b2c3 100644
+--- a/codecs/dcraw.h
++++ b/codecs/dcraw.h
+@@ -954,12 +954,12 @@ void CLASS lossless_jpeg_load_raw()
+   int min=INT_MAX;
+   ushort *rp;
+ 
+-  if(jh.wide<1 || jh.high<1 || jh.clrs<1 || jh.bits <1)
+-    longjmp (failure, 2);
+-
+   if (!ljpeg_start (&jh, 0)) return;
+   jwide = jh.wide * jh.clrs;
+ 
++  if(jh.wide<1 || jh.high<1 || jh.clrs<1 || jh.bits <1)
++    longjmp (failure, 2);
++
+   for (jrow=0; jrow < jh.high; jrow++) {
+     rp = ljpeg_row (jrow, &jh);
+     for (jcol=0; jcol < jwide; jcol++) {
diff -Nru exactimage-0.8.5/debian/patches/series exactimage-0.8.5/debian/patches/series
--- exactimage-0.8.5/debian/patches/series	2013-09-10 00:06:30.000000000 +0200
+++ exactimage-0.8.5/debian/patches/series	2015-05-25 19:28:21.000000000 +0200
@@ -12,3 +12,5 @@
 optimize2bw_denoise.patch
 CVE-2013-1438.patch
 CVE-2013-1441.patch
+CVE-2015-3885.patch
+draw_jpeg_fix.patch

--- End Message ---
--- Begin Message ---
Version: 7.9

Hi,

These bugs relate to updates which were included in the 7.9 point
release.

Regards,

Adam

--- End Message ---

Reply to: