Hi,
Please take a look at this code from png_push_read_zTXt (libpng-1.2.31/pngpread.c:1277-1288)
png_charp tmp;
tmp = text;
text = (png_charp)png_malloc(png_ptr, text_size +
(png_uint_32)(png_ptr->zbuf_size
- png_ptr->zstream.avail_out));
png_memcpy(text, tmp, text_size);
png_free(png_ptr, tmp);
png_memcpy(text + text_size, png_ptr->zbuf,
png_ptr->zbuf_size - png_ptr->zstream.avail_out);
text_size += png_ptr->zbuf_size - png_ptr->zstream.avail_out;
*(text + text_size) = '\0';
Unless I'm seriously misreading this code, the last line writes one byte beyond the end of the allocated memory. It should allocate one more byte. This is causing crashes for me in konqueror, which is how I came across this. Adding one, the crashes go away.
I looked briefly at the other reported bugs, but didn't come across this one, and found the same problem exists in 1.4.0b33. Apologies if I missed something. In case you need any details or testing, you can contact me at truedfx@gentoo.org.
Logged In: YES
user_id=7859
Originator: NO
Thanks!
Logged In: YES
user_id=7859
Originator: NO
The bug is due to an editing error in libpng-1.2.30beta04. It's
fixed in libpng-1.2.32beta01 and libpng-1.4.0beta34.
Thanks for the report.
Is it true that the problem manifests itself only when reading
a PNG file that has two or more zTXt chunks?
Glenn
Logged In: NO
After reinstalling unpatched libpng, one of the pages that I noticed consistently triggered a crash doesn't do so anymore (probably by chance). Another still does, but it contains multiple images. I'll see if I can find which one it was, specifically.
Logged In: NO
Here's the image:
http://i.fokzine.net/upload/080905_133873_picresized_1220642267_loveguru.png
And here's the pngcheck -v output:
File: 080905_133873_picresized_1220642267_loveguru.png (127498 bytes)
chunk IHDR at offset 0x0000c, length 13
228 x 168 image, 24-bit RGB, non-interlaced
chunk iCCP at offset 0x00025, length 2599
profile name = icc, compression method = 0 (deflate)
compressed profile = 2594 bytes
chunk pHYs at offset 0x00a58, length 9: 72x72 pixels/unit (1:1)
chunk zTXt at offset 0x00a6d, length 9433, keyword: Raw profile type 8bim
chunk zTXt at offset 0x02f52, length 8848, keyword: Raw profile type exif
chunk zTXt at offset 0x051ee, length 1874, keyword: Raw profile type xmp
chunk vpAg at offset 0x0594c, length 9
unknown private, ancillary, safe-to-copy chunk
chunk IDAT at offset 0x05961, length 32768
zlib: deflated, 32K window, maximum compression
chunk IDAT at offset 0x0d96d, length 32768
chunk IDAT at offset 0x15979, length 32768
chunk IDAT at offset 0x1d985, length 6067
chunk zTXt at offset 0x1f144, length 30, keyword: EXIF:YResolution
chunk zTXt at offset 0x1f16e, length 26, keyword: jpeg:colorspace
chunk zTXt at offset 0x1f194, length 36, keyword: jpeg:sampling-factor
chunk zTXt at offset 0x1f1c4, length 50, keyword: xmlns:dc
chunk IEND at offset 0x1f202, length 0
No errors detected in 080905_133873_picresized_1220642267_loveguru.png (16 chunks, -11.0% compression).
Is that what you were looking for?
Logged In: YES
user_id=7859
Originator: NO
Yes, thanks. The vulnerability is apparently triggered by the presence of multiple zTXt chunks.
Glenn
This bug is fixed in libpng-1.2.32.