From taviso at sdf.lonestar.org Sat Apr 5 18:00:41 2008 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Sat, 5 Apr 2008 18:00:41 +0000 Subject: [Png-mng-security] png_set_unknown_chunks doesnt handle bad zero-length unknown chunks? Message-ID: <20080405180041.GA16246@sdf.lonestar.org> Hey Glenn, Greg and other png gurus, I've run into a case where png_set_unknown_chunks() seems to run into uninitialized memory when copying zero-length bad unknown chunks, this seems to happen even with the pngtest program (i'm not sure how good an indication that is of good api usage?), but it also affected my program. I'm not 100% confident this is a libpng bug, i may have just misinterpreted the documentation, but if thats the case then i suppose im reporting a bug in pngtest :-) Testcase attached. Thanks, Tavis. -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 9c48e9ef12cc4d75fd89133f51f94af7.png Type: image/png Size: 57335 bytes Desc: not available URL: From glennrp at comcast.net Sat Apr 5 20:53:42 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Sat, 05 Apr 2008 16:53:42 -0400 Subject: [Png-mng-security] png_set_unknown_chunks doesnt handle badzero-length unknownchunks? In-Reply-To: <20080405180041.GA16246@sdf.lonestar.org> Message-ID: <3.0.6.32.20080405165342.013c1da8@mail.comcast.net> At 06:00 PM 4/5/2008 +0000, Tavis Ormandy wrote: >Hey Glenn, Greg and other png gurus, > >I've run into a case where png_set_unknown_chunks() seems to run into >uninitialized memory when copying zero-length bad unknown chunks, this >seems to happen even with the pngtest program (i'm not sure how good an >indication that is of good api usage?), but it also affected my program. > >I'm not 100% confident this is a libpng bug, i may have just >misinterpreted the documentation, but if thats the case then i suppose >im reporting a bug in pngtest :-) > >Testcase attached. Pngcrush seems to be able to read the file. Is it a "bad" unknown chunk or simply a valid zero-length unknown chunk? Reading IHDR chunk, length = 13. Reading gAMA chunk, length = 4. Reading cHRM chunk, length = 32. Reading iCCP chunk, length = 2613. Reading IDAT chunk, length = 21503. Reading cmOD chunk, length = 0. Reading cpIp chunk, length = 32768. Reading iTXt chunk, length = 13. Reading tEXt chunk, length = 9. Reading meTa chunk, length = 240. Reading IEND chunk, length = 0. Pngcheck has no problem with it either: chunk IHDR at offset 0x0000c, length 13 100 x 133 image, 32-bit RGB+alpha, non-interlaced chunk gAMA at offset 0x00025, length 4: 0.45454 chunk cHRM at offset 0x00035, length 32 White x = 0.34575 y = 0.35855, Red x = 0.6485 y = 0.33088 Green x = 0.32121 y = 0.59787, Blue x = 0.15589 y = 0.06604 chunk iCCP at offset 0x00061, length 2613 profile name = sRGB IEC61966-2.1, compression method = 0 (deflate) compressed profile = 2594 bytes chunk IDAT at offset 0x00aa2, length 21503 zlib: deflated, 32K window, fast compression chunk cmOD at offset 0x05ead, length 0 unknown private, ancillary, unsafe-to-copy chunk chunk cpIp at offset 0x05eb9, length 32768 unknown private, ancillary, safe-to-copy chunk chunk iTXt at offset 0x0dec5, length 13, keyword: Title uncompressed, no language tag no translated keyword, 4 bytes of UTF-8 text chunk tEXt at offset 0x0dede, length 9, keyword: Title chunk meTa at offset 0x0def3, length 240 unknown private, ancillary, safe-to-copy chunk chunk IEND at offset 0x0dfef, length 0 No errors detected Glenn From taviso at sdf.lonestar.org Sat Apr 5 21:18:44 2008 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Sat, 5 Apr 2008 21:18:44 +0000 Subject: [Png-mng-security] png_set_unknown_chunks doesnt handle badzero-length unknownchunks? In-Reply-To: <3.0.6.32.20080405165342.013c1da8@mail.comcast.net> References: <20080405180041.GA16246@sdf.lonestar.org> <3.0.6.32.20080405165342.013c1da8@mail.comcast.net> Message-ID: <20080405211844.GA2760@sdf.lonestar.org> On Sat, Apr 05, 2008 at 04:53:42PM -0400, Glenn Randers-Pehrson wrote: > At 06:00 PM 4/5/2008 +0000, Tavis Ormandy wrote: > >Hey Glenn, Greg and other png gurus, > > > >I've run into a case where png_set_unknown_chunks() seems to run into > >uninitialized memory when copying zero-length bad unknown chunks, this > >seems to happen even with the pngtest program (i'm not sure how good an > >indication that is of good api usage?), but it also affected my program. > > > >I'm not 100% confident this is a libpng bug, i may have just > >misinterpreted the documentation, but if thats the case then i suppose > >im reporting a bug in pngtest :-) > > > >Testcase attached. > > Pngcrush seems to be able to read the file. > Is it a "bad" unknown chunk or simply a valid zero-length unknown chunk? > My mistake, i was basing that on the output of pngtest, it seems the crc is correct. $ ./pngtest 9c48e9ef12cc4d75fd89133f51f94af7.png Testing libpng version 1.2.26 with zlib version 1.2.3 libpng version 1.2.26 - April 2, 2008 Copyright (c) 1998-2008 Glenn Randers-Pehrson Copyright (c) 1996-1997 Andreas Dilger Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc. library (10226): libpng version 1.2.26 - April 2, 2008 pngtest (10226): libpng version 1.2.26 - April 2, 2008 png_sizeof(png_struct)=740, png_sizeof(png_info)=288 Testing /home/taviso/9c48e9ef12cc4d75fd89133f51f94af7.png: /home/taviso/9c48e9ef12cc4d75fd89133f51f94af7.png: libpng warning: Out of memory while processing unknown chunk. /home/taviso/9c48e9ef12cc4d75fd89133f51f94af7.png: libpng warning: cmOD: CRC error Segmentation fault -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- From glennrp at simple.dallas.tx.us Sun Apr 6 02:54:07 2008 From: glennrp at simple.dallas.tx.us (Glenn Randers-Pehrson ) Date: Sat, 5 Apr 2008 21:54:07 -0500 (CDT) Subject: [Png-mng-security] patch for zero-length unknown chunk bug Message-ID: <11880.1207450448@blade.simplesystems.org> A non-text attachment was scrubbed... Name: libpng-1.2.27beta01-1.2.26-diff.txt Type: application/octet-stream Size: 7815 bytes Desc: not available URL: From glennrp at comcast.net Sun Apr 6 03:15:46 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Sat, 05 Apr 2008 23:15:46 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <11880.1207450448@blade.simplesystems.org> Message-ID: <3.0.6.32.20080405231546.013c3930@mail.comcast.net> After applying the patch to libpng-1.2.26, pngtest runs successfully. It does not copy the problematic cmOD chunk because it is not copy-safe. I have not tested with a zero-length copy-safe chunk, and I have not tested the progressive reader. Firefox seems to be immune to this problem, although I have not tested it while using the "system" libpng instead of the embedded one, which has the buggy unknown_chunk code #ifdef'ed out. Glenn From taviso at sdf.lonestar.org Mon Apr 7 17:54:50 2008 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Mon, 7 Apr 2008 17:54:50 +0000 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080405231546.013c3930@mail.comcast.net> References: <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> Message-ID: <20080407175450.GA14070@sdf.lonestar.org> On Sat, Apr 05, 2008 at 11:15:46PM -0400, Glenn Randers-Pehrson wrote: > > After applying the patch to libpng-1.2.26, pngtest runs successfully. It does not copy the problematic cmOD chunk because it is not copy-safe. I have not tested with a zero-length copy-safe chunk, and I have not tested the progressive reader. > > Firefox seems to be immune to this problem, although I have not tested it while using the "system" libpng instead of the embedded one, which has the buggy unknown_chunk code #ifdef'ed out. > Thanks Glenn, I tested the patch here, it works perfectly. I allocated CVE-2007-6070 for this issue, feel free to use it. Thanks, Tavis. -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- From glennrp at comcast.net Mon Apr 7 18:46:39 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Mon, 07 Apr 2008 14:46:39 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <20080407175450.GA14070@sdf.lonestar.org> References: <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> Message-ID: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> At 05:54 PM 4/7/2008 +0000, Tavis Ormandy wrote: >Thanks Glenn, I tested the patch here, it works perfectly. I allocated >CVE-2007-6070 for this issue, feel free to use it. Do you see a need to handle this as a sensitive issue or can we move the discussion to the png-mng-implement list and publish libpng-1.2.27beta01? I would like to know if unpatched firefox (on linux using the system libpng) or opera reacts badly when reading your test file. Glenn From taviso at sdf.lonestar.org Mon Apr 7 19:34:14 2008 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Mon, 7 Apr 2008 19:34:14 +0000 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> References: <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <20080407193414.GB14070@sdf.lonestar.org> On Mon, Apr 07, 2008 at 02:46:39PM -0400, Glenn Randers-Pehrson wrote: > At 05:54 PM 4/7/2008 +0000, Tavis Ormandy wrote: > >Thanks Glenn, I tested the patch here, it works perfectly. I allocated > >CVE-2007-6070 for this issue, feel free to use it. > > Do you see a need to handle this as a sensitive issue or can we move > the discussion to the png-mng-implement list and publish libpng-1.2.27beta01? > I'll forward a description of the issue and your patch to vendor-sec, could I have a few days (say 4?) to give them advance notice? Thanks, Tavis. > I would like to know if unpatched firefox (on linux using the system > libpng) or opera reacts badly when reading your test file. > > Glenn -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- From glennrp at comcast.net Mon Apr 7 20:21:27 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Mon, 07 Apr 2008 16:21:27 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <20080407193414.GB14070@sdf.lonestar.org> References: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <3.0.6.32.20080407162127.01461810@mail.comcast.net> At 07:34 PM 4/7/2008 +0000, Tavis Ormandy wrote: > > >I'll forward a description of the issue and your patch to vendor-sec, >could I have a few days (say 4?) to give them advance notice? Yes, sure. Let's release on April 12 at 12:00 GMT, then. Glenn From glennrp at comcast.net Tue Apr 8 02:34:26 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Mon, 07 Apr 2008 22:34:26 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <20080407193414.GB14070@sdf.lonestar.org> References: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <3.0.6.32.20080407223426.013c2250@mail.comcast.net> I have posted two test PNGs at http://www.simplesystems.org/users/glennrp/png_bugs They are zlunk-cmOD.png (the original file that Tavis supplied) zlunk-ubSc-ubUC-ueSc-ueUC.png (a 16x16 green square with 4 unknown zero-length chunks, safe-to-copy and unsafe-to-copy, before and after IDAT) Glenn From tgl at sss.pgh.pa.us Tue Apr 8 03:24:29 2008 From: tgl at sss.pgh.pa.us (Tom Lane) Date: Mon, 07 Apr 2008 23:24:29 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> References: <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <14405.1207625069@sss.pgh.pa.us> Glenn Randers-Pehrson writes: > At 05:54 PM 4/7/2008 +0000, Tavis Ormandy wrote: >> Thanks Glenn, I tested the patch here, it works perfectly. I allocated >> CVE-2007-6070 for this issue, feel free to use it. > Do you see a need to handle this as a sensitive issue The above question went unanswered: how serious is this issue? regards, tom lane From glennrp at comcast.net Tue Apr 8 03:38:23 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Mon, 07 Apr 2008 23:38:23 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <14405.1207625069@sss.pgh.pa.us> References: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <3.0.6.32.20080407233823.01461098@mail.comcast.net> At 11:24 PM 4/7/2008 -0400, Tom Lane wrote: >Glenn Randers-Pehrson writes: >> At 05:54 PM 4/7/2008 +0000, Tavis Ormandy wrote: >>> Thanks Glenn, I tested the patch here, it works perfectly. I allocated >>> CVE-2007-6070 for this issue, feel free to use it. > >> Do you see a need to handle this as a sensitive issue > >The above question went unanswered: how serious is this issue? Evidently no one on this list has access to opera or to firefox on linux, using the system libpng, or if they do, they aren't willing to test and report the results. I tried the 16x16 image with firefox-2.0.0 on Ubuntu and nothing weird happened. I was able to observe the crash of pngtest. It produced a SEGV. Nothing weird happens with IE7, but that's not a surprise since they do not use libpng. I initiated a mozilla bug (#427683) and I am preparing a patch that will bullet-proof mozilla/firefox against this issue when using the system libpng. Glenn From glennrp at comcast.net Wed Apr 9 01:02:25 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Tue, 08 Apr 2008 21:02:25 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080407233823.01461098@mail.comcast.net> References: <14405.1207625069@sss.pgh.pa.us> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <3.0.6.32.20080408210225.013c6168@mail.comcast.net> At 11:38 PM 4/7/2008 -0400, I wrote: >At 11:24 PM 4/7/2008 -0400, Tom Lane wrote: >>The above question went unanswered: how serious is this issue? > >Evidently no one on this list has access to opera or to firefox on >linux, using the system libpng, or if they do, they aren't willing >to test and report the results. D'oh, never mind testing Opera. It doesn't use libpng as far as I know. It has no problem with the test files, on Windows XP. Glenn From glennrp at comcast.net Wed Apr 9 14:26:10 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Wed, 09 Apr 2008 10:26:10 -0400 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <14405.1207625069@sss.pgh.pa.us> References: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> Message-ID: <3.0.6.32.20080409102610.013c9998@mail.comcast.net> At 11:24 PM 4/7/2008 -0400, Tom Lane wrote: >Glenn Randers-Pehrson writes: >> At 05:54 PM 4/7/2008 +0000, Tavis Ormandy wrote: >>> Thanks Glenn, I tested the patch here, it works perfectly. I allocated >>> CVE-2007-6070 for this issue, feel free to use it. > >> Do you see a need to handle this as a sensitive issue > >The above question went unanswered: how serious is this issue? I believe it is only applications that use png_set_keep_unknown_chunks() to keep unknown chunks "ALWAYS" or "IF_SAFE" or that use png_set_read_user_chunk_fn() that are affected. Those include pngtest and ImageMagick but are otherwise probably rare. I have not observed ImageMagick crashing on the test files, so I'm not sure exactly what is happening there. So my answer is "probably not very serious". That would mean that on April 12 we can announce the vulnerability but could still go through the normal 2-week beta+rc release schedule after that. I would not mind hearing from some of you about results (positive or negative) with important applications reading the test files at . Glenn From glennrp at comcast.net Wed Apr 9 18:13:38 2008 From: glennrp at comcast.net (glennrp at comcast.net) Date: Wed, 09 Apr 2008 18:13:38 +0000 Subject: [Png-mng-security] patch for zero-length unknown chunk bug Message-ID: <040920081813.10136.47FD0752000274C80000279822007456729F9D02020A0409@comcast.net> -------------- Original message ---------------------- From: Glenn Randers-Pehrson > I have not observed ImageMagick > crashing on the test files, so I'm not sure exactly what > is happening there. I was testing an earlier version that does not save unknown chunks. The most recent version doesn't crash, but it produces incorrect warnings about insufficient memory and CRC failure. I'll be patching ImageMagick today to work properly even with unpatched libpng versions. Glenn From glennrp at comcast.net Fri Apr 11 16:54:05 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Fri, 11 Apr 2008 12:54:05 -0400 Subject: [Png-mng-security] Draft security advisory for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> References: <20080407175450.GA14070@sdf.lonestar.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> Message-ID: <3.0.6.32.20080411125405.013cae80@mail.comcast.net> Draft 01, April 11, 2008 (glennrp): Libpng-1.2.26 security advisory -- April 12, 2008 This bug has been identified as CVE-2008-6070. Tavis Ormandy advised us of a bug in libpng in its handling of unknown chunks with zero data length. We have examined the report and find that the bug exists in all libpng versions since 1.0.6. It only manifests itself when all three of the following conditions exist: 1. The application is loaded with libpng-1.0.6 through 1.0.32, libpng-1.2.0 through 1.2.26, or libpng-1.4.0beta01 through libpng-1.4.0beta19, and 2. libpng was built with PNG_READ_UNKNOWN_CHUNKS_SUPPORTED or with PNG_READ_USER_CHUNKS_SUPPORTED (this is usually the case), and 3. the application includes either a call to png_set_read_user_chunk_fn() or a call to png_set_keep_unknown_chunks(png_ptr, keep, list, N) with keep = PNG_HANDLE_CHUNK_IF_SAFE (2) or keep = PNG_HANDLE_CHUNK_ALWAYS (3) We believe this is a rare circumstance. It occurs in "pngtest" that is a part of the libpng distribution, in pngcrush, and in recent versions of ImageMagick (6.2.5 through 6.4.0-4). We are not aware of any other vulnerable applications. When an application with the bug is run, libpng will generate spurious warning messages about a CRC error in the zero-length chunk and an out-of-memory condition, unless warnings are being suppressed. There is not actually a memory overflow, but a NULL pointer returned from the memory allocator when it tries to generate a zero-length buffer for the chunk data. Later, there may be an error when the application tries to free the NULL buffer. This has been observed to cause a segmentation violation in pngtest. Libpng-1.2.27 and later, and 1.0.33 and later, will not be vulnerable. These will be released on or about April 26, 2008. Libpng-1.2.27beta01, which was released today (April 12), is also not vulnerable. From glennrp at comcast.net Fri Apr 11 18:21:38 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Fri, 11 Apr 2008 14:21:38 -0400 Subject: [Png-mng-security] Draft 02 security advisory for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080411125405.013cae80@mail.comcast.net> References: <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <20080407175450.GA14070@sdf.lonestar.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> Message-ID: <3.0.6.32.20080411142138.01479ab8@mail.comcast.net> Draft 02, April 11, 2008 (glennrp): Libpng-1.2.26 security advisory -- April 12, 2008 This bug has been identified as CVE-2008-1382. Tavis Ormandy advised us of a bug in libpng in its handling of unknown chunks with zero data length. We have examined the report and find that the bug exists in all libpng versions since 1.0.6. It only manifests itself when all three of the following conditions exist: 1. The application is loaded with libpng-1.0.6 through 1.0.32, libpng-1.2.0 through 1.2.26, or libpng-1.4.0beta01 through libpng-1.4.0beta19, and 2. libpng was built with PNG_READ_UNKNOWN_CHUNKS_SUPPORTED or with PNG_READ_USER_CHUNKS_SUPPORTED (this is usually the case), and 3. the application includes either a call to png_set_read_user_chunk_fn(png_ptr, user_ptr, callback_fn) or a call to png_set_keep_unknown_chunks(png_ptr, keep, list, N) with keep = PNG_HANDLE_CHUNK_IF_SAFE (2) or keep = PNG_HANDLE_CHUNK_ALWAYS (3) We believe this is a rare circumstance. It occurs in "pngtest" that is a part of the libpng distribution, in pngcrush, and in recent versions of ImageMagick (6.2.5 through 6.4.0-4). We are not aware of any other vulnerable applications. When an application with the bug is run, libpng will generate spurious warning messages about a CRC error in the zero-length chunk and an out-of-memory condition, unless warnings are being suppressed. There is not actually a memory overflow, but the NULL pointer returned from the memory allocator when it tries to generate a zero-length buffer for the chunk data triggers the warning. Later, there may be an error when the application tries to free the non-existent buffer. This has been observed to cause a segmentation violation in pngtest. Libpng-1.2.27 and later, and 1.0.33 and later, will not be vulnerable. These are in beta and will be released on or about April 26, 2008. Libpng-1.2.27beta01, which was released today (April 12), is also not vulnerable. From glennrp at comcast.net Sat Apr 12 14:32:50 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Sat, 12 Apr 2008 10:32:50 -0400 Subject: [Png-mng-security] Draft 02 security advisory for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080411142138.01479ab8@mail.comcast.net> References: <3.0.6.32.20080411125405.013cae80@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <20080407175450.GA14070@sdf.lonestar.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> Message-ID: <3.0.6.32.20080412103250.013ceca0@mail.comcast.net> At 02:21 PM 4/11/2008 -0400, Glenn Randers-Pehrson wrote: >Draft 02, April 11, 2008 (glennrp): > >Libpng-1.2.26 security advisory -- April 12, 2008 > >This bug has been identified as CVE-2008-1382. I've posted this advisory without any further changes to png-mng-announce and png-mng-implement, and have posted copies at the PNG ftp site and SourceForge. Tavis, please pass a copy to your vendor-sec group and to anyone else you want. Any further discussion of this can occur on png-mng-implement at lists.sf.net Glenn From taviso at sdf.lonestar.org Sat Apr 12 16:20:44 2008 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Sat, 12 Apr 2008 16:20:44 +0000 Subject: [Png-mng-security] Draft 02 security advisory for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080412103250.013ceca0@mail.comcast.net> References: <3.0.6.32.20080411125405.013cae80@mail.comcast.net> <3.0.6.32.20080407144639.01461ec0@mail.comcast.net> <20080407175450.GA14070@sdf.lonestar.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <11880.1207450448@blade.simplesystems.org> <3.0.6.32.20080405231546.013c3930@mail.comcast.net> <3.0.6.32.20080412103250.013ceca0@mail.comcast.net> Message-ID: <20080412162044.GB23843@sdf.lonestar.org> On Sat, Apr 12, 2008 at 10:32:50AM -0400, Glenn Randers-Pehrson wrote: > At 02:21 PM 4/11/2008 -0400, Glenn Randers-Pehrson wrote: > >Draft 02, April 11, 2008 (glennrp): > > > >Libpng-1.2.26 security advisory -- April 12, 2008 > > > >This bug has been identified as CVE-2008-1382. > > I've posted this advisory without any further changes to png-mng-announce and > png-mng-implement, and have posted copies at the PNG ftp site and SourceForge. > Tavis, please pass a copy to your vendor-sec group and to anyone else you want. > > Any further discussion of this can occur on png-mng-implement at lists.sf.net Excellent, thanks Glenn! -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- From newt at pobox.com Sat Apr 12 19:42:36 2008 From: newt at pobox.com (Greg Roelofs) Date: Sat, 12 Apr 2008 12:42:36 -0700 Subject: [Png-mng-security] patch for zero-length unknown chunk bug In-Reply-To: <3.0.6.32.20080407233823.01461098@mail.comcast.net> Message-ID: <200804121942.m3CJgaHF020231@bolt.sonic.net> > Evidently no one on this list has access to opera or to firefox on > linux, using the system libpng, or if they do, they aren't willing > to test and report the results. > I tried the 16x16 image with firefox-2.0.0 on Ubuntu and nothing > weird happened. Ditto 2.0.0.13 on Slackware 10.0, but it doesn't use the system libpng. Greg From glennrp at comcast.net Mon Apr 14 19:42:24 2008 From: glennrp at comcast.net (Glenn Randers-Pehrson) Date: Mon, 14 Apr 2008 15:42:24 -0400 Subject: [Png-mng-security] [fwd] Re: [png-mng-implement] libpng security advisory Message-ID: <3.0.6.32.20080414154224.015a3cf8@mail.comcast.net> >Date: Mon, 14 Apr 2008 15:41:14 -0400 >To: PNG/MNG implementation discussion list >From: Glenn Randers-Pehrson >Subject: Re: [png-mng-implement] libpng security advisory >In-Reply-To: <3.0.6.32.20080412081038.013cf728 at mail.comcast.net> > >I've revised the security advisory slightly, rewording numbered >paragraph 2 to clarify that both of the named features are normally >active. Some people seem to misunderstand the original wording. ==Glenn > >Libpng-1.2.26 security advisory -- April 12, 2008; revised April 14, 2008 > >This bug has been identified as CVE-2008-1382. > >Tavis Ormandy advised us of a bug in libpng in its handling of >unknown chunks with zero data length. > >We have examined the report and find that the bug exists in all >libpng versions since 1.0.6. It only manifests itself when all >three of the following conditions exist: > > 1. The application is loaded with libpng-1.0.6 through 1.0.32, > libpng-1.2.0 through 1.2.26, or libpng-1.4.0beta01 through > libpng-1.4.0beta19, and > > 2. libpng was built with PNG_READ_UNKNOWN_CHUNKS_SUPPORTED > or with PNG_READ_USER_CHUNKS_SUPPORTED (both are active > in default libpng installations), and > > 3. the application includes either a call to > > png_set_read_user_chunk_fn(png_ptr, user_ptr, callback_fn) > > or a call to > > png_set_keep_unknown_chunks(png_ptr, keep, list, N) > > with keep = PNG_HANDLE_CHUNK_IF_SAFE (2) > or keep = PNG_HANDLE_CHUNK_ALWAYS (3) > >We believe this is a rare circumstance. It occurs in "pngtest" >that is a part of the libpng distribution, in pngcrush, and in >recent versions of ImageMagick (6.2.5 through 6.4.0-4). We are >not aware of any other vulnerable applications. > >When an application with the bug is run, libpng will generate spurious >warning messages about a CRC error in the zero-length chunk and an >out-of-memory condition, unless warnings are being suppressed. There >is not actually a memory overflow, but the NULL pointer returned from >the memory allocator when it tries to generate a zero-length buffer >for the chunk data triggers the warning. Later, there may be an error >when the application tries to free the non-existent buffer. This has >been observed to cause a segmentation violation in pngtest. > >Libpng-1.2.27 and later, and 1.0.33 and later, will not be vulnerable. >These are in beta and will be released on or about April 30, 2008. >Libpng-1.2.27beta01, which was released on April 12, is also not >vulnerable.