Hi, I just encountered a problem with a broken PNG file. The PNG file was created with Microsoft's "Snipping Tool". The problem affects both, LuaTeX and pdfTeX and proably XeTeX too (not tested). When I include a PNG file created by Microsoft's "Snipping Tool", Okular crashes. No Problem when I convert PNG->PNM->PNG with ImageMagick. In both cases the header is: 1 0 obj << /Type /XObject /Subtype /Image /Width 1942 /Height 878 /BitsPerComponent 8 /ColorSpace /DeviceRGB /Length 5115228
stream .... endstream endobj
I would expect that the number of bytes between "stream" and "endstream" is exactly the number of bytes denoted by /Length. When I use the original PNG file, 6820463 bytes are inserted between stream and endstream, with the converted file exactly 5115228 bytes are written. The value of /Length is obviously derived from the header: 1942 × 878 × 3 = 5115228 Assuming that a PDF viewer uses the value of /Length to demermine the amount of memory to allocate, crashes are quite likely and maybe this behavior can be abused to inject code into unallocated memory. Assuming that libpng is used for PNG decompression, it's probably the culprit. But I don't know whether the PNG standard allows to add additional information to the file. In this case the size cannot be determined from the header. My suggestion is, instead of relying entirely on external libraries, to make sure that (pdf|Lua)TeX always inserts exactly /Length bytes to the stream. If this is not possible, abort with an meaningful error message. At the end TeX has to create valid PDF and without such a check such problems get undetected. I've got the PNG file from someone writing his master thesis on Windows. He didn't encounter any problem himself. Here only Okular crashed, Evince and two versions of Adobe Reader didn't complain. And a minimal example which contains only the PNG file is accepted by Okular. Thus I can't provide a minimal example. But I've copied the PNG and PDF files to http://ms25.ddns.net/texlive/png-inclusion.tar.xz The PDF files were created by pdfTeX, using only the \pdfximage and \pdfrefximage primitives. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------
On 1/5/2020 1:36 AM, Reinhard Kotucha wrote:
Hi, I just encountered a problem with a broken PNG file. The PNG file was created with Microsoft's "Snipping Tool".
The problem affects both, LuaTeX and pdfTeX and proably XeTeX too (not tested).
When I include a PNG file created by Microsoft's "Snipping Tool", Okular crashes. No Problem when I convert PNG->PNM->PNG with ImageMagick.
In both cases the header is:
1 0 obj << /Type /XObject /Subtype /Image /Width 1942 /Height 878 /BitsPerComponent 8 /ColorSpace /DeviceRGB /Length 5115228
stream .... endstream endobj
I would expect that the number of bytes between "stream" and "endstream" is exactly the number of bytes denoted by /Length.
When I use the original PNG file, 6820463 bytes are inserted between stream and endstream, with the converted file exactly 5115228 bytes are written.
That image has a mask (so you should have an /smask although that depends in the minor version): zipped size : 195827 original size : 6821182 3 byte bitmap : 5115228 1 byte mask : 1705076 there is no info about resolution so the natural size is unknown
The value of /Length is obviously derived from the header:
1942 × 878 × 3 = 5115228
probably provided by pnglib .. it also depends on the filter byte being present in a row (should be in the original image data, not always in the pdf) The length is just the uncompressed length.
Assuming that libpng is used for PNG decompression, it's probably the culprit. But I don't know whether the PNG standard allows to add additional information to the file. In this case the size cannot be determined from the header.
the png stream is just the simple deinterlaced bitmap, nothing more (palette, mask etc are in the dictionary)
My suggestion is, instead of relying entirely on external libraries, to make sure that (pdf|Lua)TeX always inserts exactly /Length bytes to the stream. If this is not possible, abort with an meaningful error message. At the end TeX has to create valid PDF and without such a check such problems get undetected. There can be more wrong with an image (bad predictor info when passed along, as not all png imaged get some treatment, bad filter bytes, etc) so isn't the png library supposed to catch that?
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Reinhard Kotucha