Bug 58008 (CVE-2004-0597)

Summary: VUL-0: CVE-2004-0597: libpng: nasty security hole in libpng
Product: [Novell Products] SUSE Security Incidents Reporter: Thomas Biege <thomas>
Component: IncidentsAssignee: Juergen Weigert <jw>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Critical    
Priority: P3 - Medium CC: gnome-bugs, mls, nadvornik, postadal, security-team, stark
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: CVSSv2:NVD:CVE-2004-0597:10.0:(AV:N/AC:L/Au:N/C:C/I:C/A:C)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: libpng-patch.diff
patchinfo-box.libpng
patchinfo.libpng
libpng vendor-sec discussion
bad_images.tar

Description Thomas Biege 2004-07-14 20:23:29 UTC
Hi, 
another private report about a libpng bug: 
ate: Tue, 13 Jul 2004 20:30:51 +0100 (BST) 
From: chris@scary.beasts.org 
To: vendor-sec@lst.de 
Subject: [vendor-sec] Nasty security hole in libpng 
 
Hi, 
 
My advisory is included below. This is potentially quite nasty; seems to 
affect both mozilla and konqueror (I'm not sure if mozilla links 
dynamically to libpng, statically, or has its own copy or what). 
 
I'm not sure what to do with the advisory; libpng doesn't seem 
particularly maintained. Who did people liase with in the case of the 
recent libpng problems? Ideas appreciated. 
 
Cheers 
Chris 
 
CESA-2004-001 
 
libPNG 1.2.5 stack-based buffer overflow and other code concerns 
================================================================ 
 
This advisory lists code flaws discovered by inspection of the libpng-1.2.5 
code. Only the first one has been examined in practice to confirm 
exploitability. The other flaws certainly warrant fixing. 
 
1) Remotely exploitable stack-based buffer overrun in png_handle_tRNS 
(pngrutil.c) 
 
If a PNG file is of the correct format, a length check on PNG data is missed 
prior to filling a buffer on the stack from the PNG data. The exact flaw would 
seem to be a logic error; failure to bail out of a function after a warning 
condition is hit, here: 
 
      if (!(png_ptr->mode & PNG_HAVE_PLTE)) 
      { 
         /* Should be an error, but we can cope with it */ 
         png_warning(png_ptr, "Missing PLTE before tRNS"); 
      } 
      else if (length > (png_uint_32)png_ptr->num_palette) 
      { 
         png_warning(png_ptr, "Incorrect tRNS chunk length"); 
         png_crc_finish(png_ptr, length); 
         return; 
      } 
 
We can see, if the first warning condition is hit, the length check is missed 
due to the use of an "else if". 
A PNG crafted to trip this is available at 
http://scary.beasts.org/misc/pngtest_bad.png 
 
It crashes both mozilla and konqueror. 
 
 
2) Dangerous code in png_handle_sBIT (pngrutil.c) (Similar code in 
png_handle_hIST). 
 
Although seemingly not exploitable, there is dangerous code in this function. 
It relies on checks scattered elsewhere in the code in order to not overflow 
a 4-byte stack buffer. This line here should upper-bound the read onto the 
stack to 4 bytes: 
 
   png_crc_read(png_ptr, buf, truelen); 
 
 
3) Possible NULL-pointer crash in png_handle_iCCP (pngrutil.c) (this flaw is 
duplicated in multiple other locations). 
 
There are lots of lines such as these in the code: 
 
   chunkdata = (png_charp)png_malloc(png_ptr, length + 1); 
 
Where "length" comes from the PNG. If length is set to UINT_MAX then length + 
1 will equate to zero, leading to the PNG malloc 
routines to return NULL and 
subsequent access to crash. These lengths are sometimes checked to ensure 
they are smaller that INT_MAX, but it is not clear that all code paths perform 
this check, i.e. png_push_read_chunk in pngpread.c does not do this check 
(this is progressive reading mode as used by browsers). 
 
 
4) Theoretical integer overflow in allocation in png_handle_sPLT (pngrutil.c) 
 
This isn't likely to cause problems in practice, but there's the possibility 
of an integer overflow during this allocation: 
 
   new_palette.entries = (png_sPLT_entryp)png_malloc( 
       png_ptr, new_palette.nentries * sizeof(png_sPLT_entry)); 
 
 
5) Integer overflow in png_read_png (pngread.c) 
 
A PNG with excessive height may cause an integer overflow on a memory 
allocation and subsequent crash allocating row pointers. This line is possibly 
faulty; I can't see anywhere that enforces a maximum PNG height: 
 
      info_ptr->row_pointers = (png_bytepp)png_malloc(png_ptr, 
         info_ptr->height * sizeof(png_bytep)); 
 
 
6) Integer overflows during progressive reading. 
 
There are many lines like the following, which are prone to integer overflow: 
 
      if (png_ptr->push_length + 4 > png_ptr->buffer_size) 
 
It is not clear how dangerous this is. 
 
 
7) Other flaws. 
 
There is broad potential for other integer overflows which I have not spotted 
- 
the amount of integer arithmetic surrounding buffer handling is large, 
unfortunately. 
 
 
CESA-2004-001 
Chris Evans 
chris@scary.beasts.org
Comment 1 Thomas Biege 2004-07-14 20:23:29 UTC
<!-- SBZ_reproduce  -->
-
Comment 2 Thomas Biege 2004-07-14 20:23:57 UTC
Date: Tue, 13 Jul 2004 21:08:43 +0100 (BST) 
From: Mark J Cox <mjc@redhat.com> 
To: chris@scary.beasts.org 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] Nasty security hole in libpng 
 
> I'm not sure what to do with the advisory; libpng doesn't seem 
> particularly maintained. Who did people liase with in the case of the 
> recent libpng problems? Ideas appreciated. 
 
Hi Chris; with the last libpng issue that was reported to us we just 
worked with the other vendor-sec folks and came up with a suitable embargo 
date.  It looks like this issue is going to affect a whole load of 
packages, do you have any particular timescale in mind for disclosure? 
 
Here are some CVE names 
 
> 1) Remotely exploitable stack-based buffer overrun in png_handle_tRNS 
> (pngrutil.c) 
> 2) Dangerous code in png_handle_sBIT (pngrutil.c) (Similar code in 
> png_handle_hIST). 
 
CAN-2004-0597 for these (we merge issues that have the same flaw type that 
get fixed in the same versions). 
 
> 3) Possible NULL-pointer crash in png_handle_iCCP (pngrutil.c) (this 
> flaw is duplicated in multiple other locations). 
 
CAN-2004-0598 for those 
 
> 4) Theoretical integer overflow in allocation in png_handle_sPLT 
> (pngrutil.c) 
> 5) Integer overflow in png_read_png (pngread.c) 
> 6) Integer overflows during progressive reading. 
> 7) Other flaws.  [integer overflows] 
 
CAN-2004-0599 for those 
 
Cheers, Mark 
_________________ 
Comment 3 Thomas Biege 2004-07-14 20:25:00 UTC
Created attachment 22160 [details]
libpng-patch.diff
Comment 4 Thomas Biege 2004-07-14 20:26:46 UTC
CAN-2004-0597 (stack overflows) is definately needed 
CAN-2004-0598 (NULL-pointer crashes) sounds definately needed 
CAN-2004-0599 (integer overflows) since there were many of these outlined 
I figured at least one might have a security context. 
Comment 5 Thomas Biege 2004-07-14 21:11:42 UTC
Created attachment 22164 [details]
patchinfo-box.libpng
Comment 6 Thomas Biege 2004-07-14 21:11:58 UTC
Created attachment 22165 [details]
patchinfo.libpng
Comment 7 Thomas Biege 2004-07-15 17:02:00 UTC
Date: Wed, 14 Jul 2004 13:38:14 -0400 
From: Matthias Clasen <mclasen@redhat.com> 
To: vendor-sec@lst.de 
Cc: chris@scary.beasts.org 
Subject: Re: [vendor-sec] Nasty security hole in libpng 
Parts/Attachments: 
   1 Shown    40 lines  Text 
   2          10 KB     Application 
---------------------------------------- 
 
Hey Chris, 
 
some comments on your patch: 
 
1) the pngpread.c changes look fine, I came up with exactly the same 
after reading your initial mail. 
 
2) the image dimension checks should probably be done in png_set_IHDR - 
there are already checks against PNG_MAX_UINT there, which can be 
modified to be a bit stricter. 
 
3) Your additional checks against png_ptr->channels > 4 and 
png_ptr->num_palette > PNG_MAX_PALETTE_LENGTH are not really necessary, 
since libpng already enforces this. But you have to study 
png_handle_IHDR, png_set_IHDR and png_handle_PLTE carefully to determine 
this, so adding the extra checks may still be a good idea for clarity. 
 
4) Here is a fix for the theoretical overflow in png_handle_sPLT which 
you mention: 
 
--- libpng-1.2.5/pngrutil.c.chunklength2002-10-03 07:32:30.000000000 
-0400 
+++ libpng-1.2.5/pngrutil.c    2004-07-14 12:27:03.000000000 -0400 
@@ -1154,6 +1154,8 @@ 
    } 
 
    new_palette.nentries = data_length / entry_size; 
+   if (new_palette.nentries > PNG_MAX_UINT / sizeof(png_sPLT_entry)) 
+     png_error(png_ptr, "sPLT chunk too long"); 
    new_palette.entries = (png_sPLT_entryp)png_malloc( 
        png_ptr, new_palette.nentries * sizeof(png_sPLT_entry)); 
 
5) I have constructed a crasher image for the "possible NULL pointer 
crash" which you mention as issue 3. My crasher image causes a segfault 
in png_push_handle_tEXT() when loaded incrementally. I'm attaching it 
wrapped in a tar file, to keep the email from crashing Evolution... 
 
Regards, 
 
Matthias Clasen (RH libpng package maintainer) 
Comment 8 Thomas Biege 2004-07-15 17:03:17 UTC
ate: Wed, 14 Jul 2004 20:33:09 +0100 (BST) 
From: chris@scary.beasts.org 
To: Matthias Clasen <mclasen@redhat.com> 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] Nasty security hole in libpng 
 
Hi! 
 
On Wed, 14 Jul 2004, Matthias Clasen wrote: 
 
> some comments on your patch: 
... 
> 3) Your additional checks against png_ptr->channels > 4 and 
> png_ptr->num_palette > PNG_MAX_PALETTE_LENGTH are not really necessary, 
> since libpng already enforces this. But you have to study 
> png_handle_IHDR, png_set_IHDR and png_handle_PLTE carefully to determine 
> this, so adding the extra checks may still be a good idea for clarity. 
 
Yep, I agree. In my advisory, I noted that it seems to not be exploitable 
and just a case of bad code. At one stage I thought it _was_ exploitable 
if a very specific set of circumstances was met - but it seems not. The 
lack of exploitability is IMHO "luck" so I'd be more comfortable keeping 
the redundant check in place. It will guard against future code changes 
accidentally opening up a hole. 
 
> 4) Here is a fix for the theoretical overflow in png_handle_sPLT which 
> you mention: 
 
I don't think this is needed because of the added checks against all PNG 
chunk lengths being <= PNG_UINT_MAX (which is actually defined as 
the C standard INT_MAX). Running through this function with length set 
at PNG_UINT_MAX, I don't think the overflow can trigger. Let me know if 
I'm wrong. 
 
> 5) I have constructed a crasher image for the "possible NULL pointer 
> crash" which you mention as issue 3. My crasher image causes a segfault 
> in png_push_handle_tEXT() when loaded incrementally. I'm attaching it 
> wrapped in a tar file, to keep the email from crashing Evolution... 
 
Hey, excellent. I'm glad I wasn't smoking regarding this one. 
 
The libpng maintainer has responded, and is working towards a libpng-1.2.6 
with all the known security issues fixed. He is also making tweaks to my 
patch. You might want to contact him 
Glenn Randers-Pehrson <glennrp@glennrp.com> 
and work together to get the best combined patch. 
 
Cheers 
Chris 
 
Comment 9 Thomas Biege 2004-07-15 21:56:36 UTC
1. A stack-based buffer overflow in libpng which can be triggered to run 
arbitrary code by a malicious png file: CAN-2004-0597 
 
2. A NULL-pointer crash in libpng which can be triggered by a malicious 
png file: CAN-2004-0598 
 
3. Various possible integer overflows in libpng which may have security 
consequences:  CAN-2004-0599 
 
Comment 10 Thomas Biege 2004-07-15 21:58:11 UTC
Date: Thu, 15 Jul 2004 09:51:10 -0400 
From: Matthias Clasen <mclasen@redhat.com> 
To: chris@scary.beasts.org 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] Nasty security hole in libpng 
 
On Wed, 2004-07-14 at 15:33, chris@scary.beasts.org wrote: 
 
> > 4) Here is a fix for the theoretical overflow in png_handle_sPLT which 
> > you mention: 
> 
> I don't think this is needed because of the added checks against all PNG 
> chunk lengths being <= PNG_UINT_MAX (which is actually defined as 
> the C standard INT_MAX). Running through this function with length set 
> at PNG_UINT_MAX, I don't think the overflow can trigger. Let me know if 
> I'm wrong. 
> 
 
Hmm, I guess that depends on how the compiler packs structs. length 
can be no larger than 2^31-1, thus slength and data_length are also 
<= 2^31-1. Thus newpalette.nentries can be no larger than 
2^31-1/6 = 0x15555555. Now if sizeof (png_sPLT_entry) is 10, we end up 
allocating not more than 0xD5555552 < 2^32 bytes, but if the size of the 
struct is 20 (is the compiler actually allowed to do that ?), then 
we may end up allocating 0x1AAAAAAA4 > 2^32 bytes and overflow. 
 
Matthias 
 
Comment 11 Thomas Biege 2004-07-16 19:15:53 UTC
Date: Thu, 15 Jul 2004 17:06:37 +0100 (BST) 
From: chris@scary.beasts.org 
To: Matthias Clasen <mclasen@redhat.com> 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] Nasty security hole in libpng 
 
Hi, 
 
On Thu, 15 Jul 2004, Matthias Clasen wrote: 
 
> Hmm, I guess that depends on how the compiler packs structs. length 
> can be no larger than 2^31-1, thus slength and data_length are also 
> <= 2^31-1. Thus newpalette.nentries can be no larger than 
> 2^31-1/6 = 0x15555555. Now if sizeof (png_sPLT_entry) is 10, we end up 
> allocating not more than 0xD5555552 < 2^32 bytes, but if the size of the 
> struct is 20 (is the compiler actually allowed to do that ?), then 
> we may end up allocating 0x1AAAAAAA4 > 2^32 bytes and overflow. 
 
Good point - better to be safe than sorry. 
 
Cheers 
Chris 
 
Comment 12 Vladimir Nadvornik 2004-07-16 22:43:12 UTC
Thomas, are the patches from comment #3 and comment #7 sufficient? 
Comment 13 Thomas Biege 2004-07-19 15:50:51 UTC
CRD: 04.08.2004 
 
Comment 14 Thomas Biege 2004-07-19 16:16:21 UTC
Created attachment 22251 [details]
libpng vendor-sec discussion
Comment 15 Thomas Biege 2004-07-19 16:25:57 UTC
Created attachment 22252 [details]
bad_images.tar
Comment 16 Thomas Biege 2004-07-19 16:32:26 UTC
concerning comment #12, yes I think so. 
Please have a look at the whole discussion attached in comment #14 because 
Tom Rini <trini@mvista.com> had some trouble backporting the patch.	 
Comment 17 Vladimir Nadvornik 2004-07-19 20:28:50 UTC
Packages and patchinfo files are submitted. 
 
 
 
Comment 18 Michael Schröder 2004-07-19 22:33:32 UTC
What about all other packages that contain libpng? They are probably also
vulnerable if they don't use the system's libpng. Please check.
- abiword
- abiword2
- crossover-office
- crossover-plugin
- doxygen
- ghostpcl
- htmldoc
- qt3
- rrdtool
- tetex
- tkimg
- wxGTK

Comment 19 Michael Schröder 2004-07-19 23:47:20 UTC
There is also
- AROS
- MainActor
- Mozilla
- MozillaFirebird
- MozillaThunderbird
- amaya
- chronium
- jazz
Comment 20 Thomas Biege 2004-07-20 18:08:15 UTC
I'll lookup the maintainers... 
Comment 21 Thomas Biege 2004-07-20 18:14:52 UTC
Hello Maintainers, 
I added you to CC to cjeck if your package does NOT use the system-wide 
libpng. 
 
Please add your comments here. 
Comment 22 Adrian Schröter 2004-07-20 21:16:37 UTC
qt3 has a patch to use the system wide one. 
Comment 23 Stanislav Brabec 2004-07-20 21:30:08 UTC
abiword* probably uses system one (must check for older versions, too)
chromium, ghostpcl and jazz probably uses its own (but ghostpcl distribution was
cancelled by legal team)
Comment 24 Thomas Biege 2004-07-20 21:39:19 UTC
we still support SL 8.1 upwards, so it's not needed to check versions prior 
8.1. 
Comment 25 Marcus Meissner 2004-07-20 21:40:30 UTC
i have verified crossover-office and crossover-plugin, while png is  
mentioned in the logfile, it is neither compiled nor linked in.  
 
Comment 26 Lars Müller 2004-07-20 22:52:04 UTC
htmldoc uses the system wide one.
Comment 27 Reinhard Max 2004-07-20 23:30:18 UTC
tkimg uses it's own. I have to check if I can patch it to use the one from the
system, or if I have to replace the one that comes with the package.
Comment 28 Wolfgang Rosenauer 2004-07-21 02:52:40 UTC
all mozilla packages since 8.1 use --with-system-png.
So they really should not be statically linked with old libs.
For 8.0 I'm not sure but we don't care about it anymore.
Comment 29 Juergen Weigert 2004-07-21 03:41:49 UTC
MainActor is vulnerable and cannot be fixed easily. 
They use a binary only libgfl.so.1.93 to read images, which obviously  
contains libpng. 
 
They need to disable PNG support through libgfl and implement an alternative 
using system libpng. I'll have vendor check their options. 
Comment 30 Thomas Biege 2004-07-21 19:20:06 UTC
just a private side-note from CERT: 
 
Hello folks, 
 
We have received the following additional information from the libpng 
maintainers regarding the vulnerabilities we reported to you last 
week: 
 
        A test version of libpng is available that deals with these 
vulnerabilit 
ies. 
        See http://libpng.sourceforge.net/scary/ 
 
        It's in two formats, take your pick: 
        libpng-1.2.6beta3b.tar.gz 
        lp126b3b.zip 
 
        It incorporates the patch from the bug report, except for the 
        PNG_MAX_DIMENSION change which has been replaced with a check 
        inside the png_read_png() function (VU#160448). 
 
        Feel free to pass this information along to any libpng vendors 
        with whom you are communicating.  Ask them not to make any links 
        to the above-mentioned directory so it isn't picked up prematurely 
        by search engines. 
 
Just as a reminder, the original reporter has indicated that he will 
publish his advisory regarding these issues on August 4, 2004.  We 
intend to be prepared to publish information about these issues at 
that time.  Please respond with any comments or vendor statements you 
might have before that date. 
 
If you have any additional questions or concerns, please do not 
hesitate to contact us. 
 
Best Regards, 
 
Chad 
 
-- 
Chad Dougherty 
Comment 31 Stanislav Brabec 2004-07-23 20:26:55 UTC
jazz: Code is not used.
Comment 32 Stanislav Brabec 2004-07-23 21:49:02 UTC
ghostpcl: Code is not used.
Comment 33 Dr. Werner Fink 2004-07-26 22:31:26 UTC
xv, xemacs, gnuplot, and ghostscript use system libpng
Comment 34 Juergen Weigert 2004-07-26 22:43:21 UTC
mainactor: upstream promised an update that uses system libpng before Aug 4. 
Comment 35 Michal Čihař 2004-07-27 16:47:38 UTC
wxGTK uses system library.
Comment 36 Thomas Biege 2004-07-28 15:25:09 UTC
Ok, here my summary: 
package                 system          own                     action 
------------------------------------------------------------------------------- 
abiword                 +               -                       na 
abiword2                +               -                       na 
crossover-office        +               -                       na 
crossover-plugin        +               -                       na 
doxygen                 ?               ?                       NO RESPONSE 
ghostpcl                -               + (code not used)       na 
htmldoc                 +               -                       na 
qt3                     +               -                       na 
rrdtool                 ?               ?                       NO RESPONSE 
tetex                   ?               ?                       NO RESPONSE 
tkimg                   -               +                       !!!UPDATE!!! 
wxGTK                   +               -                       na 
AROS                    ?               ?                       NO RESPONSE 
MainActor               -               +                       !!!UPDATE!!! 
Mozilla                 +               -                       na 
MozillaFirebird         +               -                       na 
MozillaThunderbird      +               -                       na 
amaya                   ?               ?                       NO RESPONSE 
chronium                -               +                       !!!UPDATE!!! 
jazz                    -               + (code not used)       stable 
xv                      +               -                       na 
xemacs                  +               -                       na 
gnuplot                 +               -                       na 
ghostscript             +               -                       na 
 
Comment 37 Thomas Biege 2004-07-28 15:31:33 UTC
I've no response for the following packages: 
- AROS:		stephan@suse.de 
- amaya:	ltinkl@suse.cz 
- doxygen:	postadal@suse.cz 
- textex:	??? 
- rddtools:	??? 
Comment 38 Thomas Biege 2004-07-28 15:33:46 UTC
Updates neeed for 4th of August: 
- tkimg 
- MainActor 
- chronium 
 
jazz, what do you think about using the system libpng in future? 
 
Comment 39 Thomas Biege 2004-07-28 15:35:48 UTC
ok, the packages is called tetex and not textex. 
and it seems to use the systemwide libpng since 8.1. 
Comment 40 Vladimir Nadvornik 2004-07-28 16:21:31 UTC
chromium uses libpng to read it's own datafiles. It does not open 
any png from untrusted source. I don't think the update is needed. 
Comment 41 Reinhard Max 2004-07-28 16:24:09 UTC
I've just submitted tkimg to STABLE and 9.1. It didn't exist in earlier
versions. It uses libpng, libtiff, and libjpeg from the system instead of it's
own now.

Shall I write the patchinfo file or is the security team going to do that?
Comment 42 Dr. Werner Fink 2004-07-28 17:27:05 UTC
AFAICS no one of the tools of tetex uses its own libpng but
only the system libpng.
Comment 43 Michael Schröder 2004-07-28 18:00:45 UTC
"rddtools" was "rrdtool" in comment #18 and is maintained by tcrhak@suse.cz
Comment 44 Tomas Crhak 2004-07-28 19:49:15 UTC
rrdtool in SL 9.1 and STABLE uses the system libpng
8.0, ..., 9.0 uses its own libpng-1.0.9
Comment 45 Reinhard Max 2004-07-29 00:09:54 UTC
I just learned that it is not good to introduce a new package dependency (on
libpng) with a YOU update.

But it would be possible to put the tkimg rpm into the same patchinfo file as
libpng. Cornelius Schumacher told me it is possible to have multiple RPMs in one
patchinfo file but only those that are already installed will be updated.

Can we do that for libpng and tkimg, and maybe also for the other packages that
get changed to use the system libpng due to this bug?
Comment 46 Michael Schröder 2004-07-29 00:44:38 UTC
That won't help. The new dependency would only hurt if libpng is not installed
in the system, in that case libpng will also not be installed with the update.
Comment 47 Reinhard Max 2004-07-29 01:10:22 UTC
So what else would you suggest, Michael?
Can we just assume that libpng exists on any sensible system that has X11 (which
is in turn requird by tkimg)?
Comment 48 Michael Schröder 2004-07-29 01:12:18 UTC
The "clean" solution would be to apply the png security fixes to the png sources
of the package.
Comment 49 Reinhard Max 2004-07-29 01:39:53 UTC
I think the included version is too old for that:

   libpng version 1.0.8 - July 24, 2000

So the realistic options are (in order of my personal preferrence):

a) Use the current version and hope nobody who has installed tkimg is missing
   libpng (I think chances are very good, as libpng is in the standard
   installation and required by many other packages and tkimg is optional).

b) Make a patchinfo file for tkimg that contains and installs libpng as well
   (the libpng update might be downloaded twice in this case).

c) Use the current version, but link it statically.

Awaiting further advice...
Comment 50 Thomas Biege 2004-07-29 16:13:09 UTC
d) a YOU popup window for telling the customer about the dependency 
 
 
c) sounds good to me. 
Comment 51 Ludwig Nussel 2004-07-29 16:19:05 UTC
no popups please 
Comment 52 Thomas Biege 2004-07-29 17:02:21 UTC
JFYI: 
Date: Wed, 28 Jul 2004 19:27:21 +0100 (BST) 
From: chris@scary.beasts.org 
To: vendor-sec@lst.de 
Subject: [vendor-sec] Re: New libpng vulnerabilities: libpng-1.2.6beta4, 
beta4d (fwd) 
 
Hi, 
 
This is a libpng update. 
 
CERT requested more time beyond 4th Aug, but after discussion with the 
libpng maintainer, this request has been denied. The libpng community were 
strongly against further delay. 
 
So as far as I'm aware we're still on for Aug 4th. 
Hopefully nothing will leak until then, although more libpng people are 
about to be brought into the loop. Also note that some libpng people want 
to do an immediate disclosure but I think they have been disuaded. 
 
I'm forwarding details of the latest + greatest official fixed libpng 
release below in case you find it useful. 
 
Cheers 
Chris 
 
---------- Forwarded message ---------- 
Date: Wed, 28 Jul 2004 13:59:05 -0400 
From: "Glenn Randers-Pehrson <glennrp>" <glennrp@comcast.net> 
To: chris@scary.beasts.org 
Subject: Re: New libpng vulnerabilities: libpng-1.2.6beta4, beta4d 
 
chris@scary.beasts.org wrote: 
> 
> Hi Glenn, 
> 
> On Wed, 28 Jul 2004, Glenn Randers-Pehrson <glennrp> wrote: 
> 
> > I have decided that I will open the discussion to all of png-implement 
> > tonight or tomorrow regardless of the CERT request.  Greg can decide 
> > whether to shut off or delay the archiving process or not.  I will see 
> > about producing a supplemental archive of the off-list messages on  the 
> > topic. 
> 
> Could you remind me of the location of the latest fully fixed libpng? I'll 
> let vendor-sec know in case of an early leak. 
> 
> Cheers 
> Chris 
 
http://www.graphicsmagick.org/libpng/beta/src  # libpng-1.2.6beta4e 
sources 
http://www.graphicsmagick.org/libpng/beta/patches   # patches for all 
versions 
also a.k.a. 
http://www.simplesystems.org/libpng/beta/* 
 
Glenn 
_______________________________________________ 
Vendor Security mailing list 
Vendor Security@lst.de 
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec 
 
Comment 53 Tomas Crhak 2004-07-29 17:46:56 UTC
The patch for libpng 1.0.8 from http://www.graphicsmagick.org/libpng/beta/patches
applies well to rrdtool's libpng 1.0.9 (there is no patch for 1.0.9 there). Is
that single patch sufficient?
Comment 54 Thomas Biege 2004-07-29 20:23:50 UTC
The patch looks complete. 
Comment 55 Reinhard Max 2004-07-29 20:43:11 UTC
OK, so I'll use that one for tkimg, too.
Comment 56 Reinhard Max 2004-07-29 22:12:06 UTC
tkimg and patchinfo file submitted for 9.1.
Comment 57 Tomas Crhak 2004-07-29 22:47:23 UTC
rrdtool 8.0, 8.1, 8.2 and 9.0 submitted
is sles7 still maintained?
Comment 58 Ruediger Oertel 2004-07-29 22:53:51 UTC
Tomas: can I have a patchinfo for rrdtool ? 
Comment 59 Tomas Crhak 2004-07-29 23:16:56 UTC
submitted rrdtool.box and rrdtool.maintained
Comment 60 Thomas Biege 2004-07-30 18:35:50 UTC
comment #57, sles7 isnt maintained anymore. 
Comment 61 Petr Ostadal 2004-08-02 22:50:46 UTC
Package Doxygen uses own libpng for generating own diagrams and doesn't use it
for   any untrusted sources, I think the update for doxygen isn't needed.
Comment 62 Thomas Biege 2004-08-02 22:55:05 UTC
Petr, 
ok. But can you update it for stable please. 
Comment 63 Thomas Biege 2004-08-04 13:06:50 UTC
please take care about this: 
Date: Tue, 3 Aug 2004 23:33:05 -0400 (EDT) 
From: glennrp@studio.imagemagick.org 
To: Simon Cooper <scooper@apple.com> 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] libpng patches.  Warning:  the 
"libpng-<ver>-all-patches.txt" files are missing patch11* 
 
On Tue, 3 Aug 2004, Simon Cooper wrote: 
 
> For those patching older versions of libpng I wanted warn everyone that 
> the "libpng-<ver>-all-patches.txt" files 
> are all missing "patch11". 
> 
> The combined patch files have not been updated since July 23rd and 
> patch11 appears to have been added early on Aug 2nd. 
> 
 
The combined patch files and the associated INFO.txt file have been 
updated; all now contain patch11. 
 
See http://www.graphicsmagick.org/libpng/beta/patches 
 
Glenn 
 
_______________________________________________ 
Vendor Security mailing list 
Vendor Security@lst.de 
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec 
 
 
Comment 64 Thomas Biege 2004-08-04 13:11:45 UTC
Please have a look at your source (libpng, tkimg, rrdtool, jazz, chronium, 
MainActor) if patch http://www.graphicsmagick.org/libpng/beta/patches/
libpng-patch11-limit-dimensions.txt is missing. 
 
If this is the case, we should release the current update package and make 
another update later. 
Comment 65 Vladimir Nadvornik 2004-08-04 16:17:14 UTC
The patch from comment #3, which I used for libpng has similar check 
in png_handle_IHDR, the difference is that the dimensions are not checked  
on image write. Is it sufficient? 
 
For chromium, did you notice comment #40? 
Comment 66 Thomas Biege 2004-08-04 16:26:41 UTC
about comment #40: yes I saw it, but it would be nice to have it fixed at 
least in STABLE anyway. 
 
comment #65: reading is more prone to be exploited, but nevertheless is should 
be fixed for writing too. 
 
 
Comment 67 Thomas Biege 2004-08-04 23:59:00 UTC
packages approved. 
 
please handle the missing patch. Thank you! 
Comment 68 Thomas Biege 2004-08-05 00:00:01 UTC
sorry.. sounds a bit rude. 
 
can you handle the missing patch please?  
 
:) 
Comment 69 Vladimir Nadvornik 2004-08-13 22:05:47 UTC
I submitted libpng with the official patches. 
Thomas, can you please submit patchinfos? 
Comment 70 Thomas Biege 2004-08-14 01:25:07 UTC
done. 
Comment 71 Thomas Biege 2004-08-17 19:22:45 UTC
rrdtool and libpng approved. 
 
Still open: opera (we wait for a new release from opera software) 
            and MainActor 
 
Jürgen, is there a new version available now? 
Comment 72 Juergen Weigert 2004-08-17 21:09:17 UTC
I've submitted an update of MainActor-5 to STABLE. This is a binary 
package. It works with 9.1, but may not work with 9.0 or before. 
 
(package MainActor, which contains a 3.x version is internal). 
Comment 73 Thomas Biege 2004-08-18 15:55:40 UTC
Thanks! 
 
I consider this bug fixed now.