Bug 57043 - (CVE-2002-1363) VUL-0: CVE-2002-1363: libpng: missing patch
(CVE-2002-1363)
VUL-0: CVE-2002-1363: libpng: missing patch
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
All Linux
: P3 - Medium : Normal
: ---
Assigned To: Vladimir Nadvornik
Security Team bot
CVE-2002-1363: CVSS v2 Base Score: 7....
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-15 22:38 UTC by Thomas Biege
Modified: 2021-09-27 13:39 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
libpng-1.0.15-transfix.patch (1.92 KB, patch)
2004-06-15 22:39 UTC, Thomas Biege
Details | Diff
patchinfo-box.libpng (357 bytes, text/plain)
2004-06-15 22:48 UTC, Thomas Biege
Details
patchinfo.libpng (571 bytes, text/plain)
2004-06-15 22:48 UTC, Thomas Biege
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Biege 2004-06-15 22:38:11 UTC
Hi Vladimir, 
as we already discussed via email, the package meeds an update. 
 
Date: Tue, 15 Jun 2004 08:52:32 +0100 (BST) 
From: Mark J Cox <mjc@redhat.com> 
To: marcdeslauriers@videotron.ca 
Cc: Jesse Keating <jkeating@j2solutions.net>, vendor-sec@lst.de 
Subject: [vendor-sec] Re: Issue w/ libpng10 
Parts/Attachments: 
   1 Shown    16 lines  Text 
   2   OK     ~2 KB     Text, "" 
---------------------------------------- 
 
Marc Deslauriers of the Fedora Legacy Project noticed during work on an 
update for libpng that some of our libpng packages were missing a 
backported patch for an old issue; CAN-2002-1363. 
 
This patch was missed during a security audit of backported fixes to Red 
Hat Linux 9 due to confusion in the CVE entry (I've since sent in a 
correction). 
 
We're going to provide updated fixes shortly; if anyone else here used the 
Red Hat packages or is affected please let me know asap so we can 
co-ordinate. 
 
CAN-2002-1363 required patch to pngrtran.c; attached. 
 
Cheers, Mark
Comment 1 Thomas Biege 2004-06-15 22:38:11 UTC
<!-- SBZ_reproduce  -->
-
Comment 2 Thomas Biege 2004-06-15 22:39:49 UTC
Created attachment 21207 [details]
libpng-1.0.15-transfix.patch
Comment 3 Thomas Biege 2004-06-15 22:48:32 UTC
Created attachment 21210 [details]
patchinfo-box.libpng
Comment 4 Thomas Biege 2004-06-15 22:48:52 UTC
Created attachment 21211 [details]
patchinfo.libpng
Comment 5 Michael Schröder 2004-06-18 17:46:06 UTC
Folks, please submit the patchinfos to /work/src/done/PATCHINFO after
submitting all of the packages. Thanks.
Comment 6 Vladimir Nadvornik 2004-06-18 18:28:41 UTC
The documentation of the process is a bit unclear here. Should be the  
patchinfo submitted together with the package or later, when the package is 
checked in and rebuilt? 
Comment 7 Michael Schröder 2004-06-18 18:36:53 UTC
Please submit it together with the packages.
Comment 8 Vladimir Nadvornik 2004-06-18 18:58:24 UTC
OK. 
Patchinfo submitted. 
Comment 9 Thomas Biege 2004-06-29 16:48:18 UTC
<!-- SBZ_reopen -->Reopened by thomas@suse.de at Tue Jun 29 10:48:18 2004
Comment 10 Thomas Biege 2004-06-29 16:48:18 UTC
There may be problems with that fix. 
Comment 11 Thomas Biege 2004-06-29 16:49:16 UTC
Date: Mon, 28 Jun 2004 15:21:50 -0400 
From: Josh Bressers <bressers@redhat.com> 
To: vendor-sec@lst.de 
Subject: [vendor-sec] CAN-2002-1363 libpng revisited 
 
The patch for this issue had found its way out of a few of the latest Red 
Hat distributions, and has been added back in recently, but a customer 
pointed out a potential problem with our original patch (which I believe 
other distributions are using). 
 
Here's the patch that was used previously. 
 
--- libpng-1.0.12.orig/pngrtran.c 
+++ libpng-1.0.12/pngrtran.c 
@@ -1924,8 +1924,8 @@ 
          /* This changes the data from RRGGBB to RRGGBBXX */ 
          if (flags & PNG_FLAG_FILLER_AFTER) 
          { 
-            png_bytep sp = row + (png_size_t)row_width * 3; 
-            png_bytep dp = sp  + (png_size_t)row_width; 
+            png_bytep sp = row + (png_size_t)row_width * 6; 
+            png_bytep dp = sp  + (png_size_t)row_width * 2; 
             for (i = 1; i < row_width; i++) 
             { 
                *(--dp) = hi_filler; 
@@ -1946,8 +1946,8 @@ 
          /* This changes the data from RRGGBB to XXRRGGBB */ 
          else 
          { 
-            png_bytep sp = row + (png_size_t)row_width * 3; 
-            png_bytep dp = sp  + (png_size_t)row_width; 
+            png_bytep sp = row + (png_size_t)row_width * 6; 
+            png_bytep dp = sp  + (png_size_t)row_width * 2; 
             for (i = 0; i < row_width; i++) 
             { 
                *(--dp) = *(--sp); 
 
 
This works fine, but as was pointed out, it doesn't fix the same problem 
when parsing grayscale images.  Here's the new patch we're using. 
 
--- libpng-1.0.15/pngrtran.c.transfix>--2004-06-14 09:44:56.000000000 -0400 
+++ libpng-1.0.15/pngrtran.c>---2004-06-14 09:48:10.000000000 -0400 
@@ -1889,8 +1889,8 @@ 
          /* This changes the data from GG to GGXX */ 
          if (flags & PNG_FLAG_FILLER_AFTER) 
          { 
-            png_bytep sp = row + (png_size_t)row_width; 
-            png_bytep dp = sp  + (png_size_t)row_width; 
+            png_bytep sp = row + (png_size_t)row_width * 2; 
+            png_bytep dp = sp  + (png_size_t)row_width * 2; 
             for (i = 1; i < row_width; i++) 
             { 
                *(--dp) = hi_filler; 
@@ -1907,8 +1907,8 @@ 
          /* This changes the data from GG to XXGG */ 
          else 
          { 
-            png_bytep sp = row + (png_size_t)row_width; 
-            png_bytep dp = sp  + (png_size_t)row_width; 
+            png_bytep sp = row + (png_size_t)row_width * 2; 
+            png_bytep dp = sp  + (png_size_t)row_width * 2; 
             for (i = 0; i < row_width; i++) 
             { 
                *(--dp) = *(--sp); 
@@ -1965,8 +1965,8 @@ 
          /* This changes the data from RRGGBB to RRGGBBXX */ 
          if (flags & PNG_FLAG_FILLER_AFTER) 
          { 
-            png_bytep sp = row + (png_size_t)row_width * 3; 
-            png_bytep dp = sp  + (png_size_t)row_width; 
+            png_bytep sp = row + (png_size_t)row_width * 6; 
+            png_bytep dp = sp  + (png_size_t)row_width * 2; 
             for (i = 1; i < row_width; i++) 
             { 
                *(--dp) = hi_filler; 
@@ -1987,8 +1987,8 @@ 
          /* This changes the data from RRGGBB to XXRRGGBB */ 
          else 
          { 
-            png_bytep sp = row + (png_size_t)row_width * 3; 
-            png_bytep dp = sp  + (png_size_t)row_width; 
+            png_bytep sp = row + (png_size_t)row_width * 6; 
+            png_bytep dp = sp  + (png_size_t)row_width * 2; 
             for (i = 0; i < row_width; i++) 
             { 
                *(--dp) = *(--sp); 
 
As far as I can tell, this is what should be happening, the offsets are 
incorrect as written in upstream source for the grayscale images. 
 
-- 
    JB 
_______________________________________________ 
Vendor Security mailing list 
Vendor Security@lst.de 
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec 
 
Comment 12 Vladimir Nadvornik 2004-06-29 16:57:41 UTC
The patch from comment #2 which we are using is 
the same as the second patch from comment #11. 
I don't see any problem here. 
Comment 13 Thomas Biege 2009-10-13 19:31:42 UTC
CVE-2002-1363: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)