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

Bug#786918: marked as done (jessie-pu: package exactimage/0.8.9-7+deb8u1)



Your message dated Sat, 06 Jun 2015 13:11:11 +0100
with message-id <1433592671.2987.12.camel@adam-barratt.org.uk>
and subject line Fix released with 8.1 point release
has caused the Debian Bug report #786918,
regarding jessie-pu: package exactimage/0.8.9-7+deb8u1
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.)


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


I'd like to upload the attached patch to stable-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 mentioned in CVE-2015-3885.

Kind regards,
	Sven

[1] http://www.rawsamples.ch/raws/canon/RAW_CANON_EOS_5DMARK3.CR2
diff -Nru exactimage-0.8.9/debian/changelog exactimage-0.8.9/debian/changelog
--- exactimage-0.8.9/debian/changelog	2014-08-30 15:47:09.000000000 +0200
+++ exactimage-0.8.9/debian/changelog	2015-05-25 19:23:02.000000000 +0200
@@ -1,3 +1,14 @@
+exactimage (0.8.9-7+deb8u1) jessie; 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:45:27 +0200
+
 exactimage (0.8.9-7) unstable; urgency=medium
 
   * debian/rules:
diff -Nru exactimage-0.8.9/debian/patches/CVE-2015-3885.patch exactimage-0.8.9/debian/patches/CVE-2015-3885.patch
--- exactimage-0.8.9/debian/patches/CVE-2015-3885.patch	1970-01-01 01:00:00.000000000 +0100
+++ exactimage-0.8.9/debian/patches/CVE-2015-3885.patch	2015-05-25 19:23:02.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 b115191c2f8f049e8ad933e0f83de52568413ec2..2f24f0f73744520a87cf6dc2eeb7dea84e83a563 100644
+--- a/codecs/dcraw.h
++++ b/codecs/dcraw.h
+@@ -775,7 +775,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];
+   const uchar *dp;
+ 
diff -Nru exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch
--- exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch	1970-01-01 01:00:00.000000000 +0100
+++ exactimage-0.8.9/debian/patches/draw_jpeg_fix.patch	2015-05-25 19:23:02.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 2f24f0f73744520a87cf6dc2eeb7dea84e83a563..5584fef46c9759776475683a17d252b723a58ee5 100644
+--- a/codecs/dcraw.h
++++ b/codecs/dcraw.h
+@@ -893,12 +893,12 @@ void CLASS lossless_jpeg_load_raw()
+   struct jhead jh;
+   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);
+     if (load_flags & 1)
diff -Nru exactimage-0.8.9/debian/patches/series exactimage-0.8.9/debian/patches/series
--- exactimage-0.8.9/debian/patches/series	2014-08-30 15:47:09.000000000 +0200
+++ exactimage-0.8.9/debian/patches/series	2015-05-25 19:23:02.000000000 +0200
@@ -13,3 +13,5 @@
 libgif.patch
 ftbfs_evas_object.patch
 perl_vendor_dir.patch
+CVE-2015-3885.patch
+draw_jpeg_fix.patch

--- End Message ---
--- Begin Message ---
Version: 8.1

Hi,

The fix discussed in this bug was released to stable as part of the 8.1
point release earlier today.

Regards,

Adam

--- End Message ---

Reply to: