4 ms·
No input validation in the IHDR as to the number of bits in the palette of the image. As I understand it, you just create an arbitrary image with the palette in
by packetized 11y ago
No input validation in the IHDR as to the number of bits in the palette of the image. As I understand it, you just create an arbitrary image with the palette in the IHDR tweaked to a large number of bits, and watch as the process dies while trying to malloc() enough space to handle a palette that large.
http://seclists.org/oss-sec/2015/q4/264 http://seclists.org/oss-sec/2015/q4/264
- 0xcde4c3db 11y agoI think it's the other way around: the malicious image specifies a small bits-per-pixel value in IHDR (thus in some sense advertising that the palette will have 2^bpp entries) but then contains a palette with more than 2^bpp entries, which libpng will copy in its entirety when asked to read the palette, overflowing the destination buffer if the application only allocated enough memory for the expected number of entries.
- packetized 11y agoYou're precisely right.
- cesarb 11y agoIf that's the case, and bpp is always 8 or less, then software where the programmers were "lazy" and always allocated 256 entries for the palette might not be vulnerable. From a quick search in MXR (https://mxr.mozilla.org/mozilla-central/ https://mxr.mozilla.org/mozilla-central/) for the identifiers "png_set_PLTE" and "png_set_PLTE", it seems that at least Mozilla (Firefox) did the lazy thing and always allocated 256 entries. Edit: I was right, from https://bugzilla.mozilla.org/show_bug.cgi?id=1224244 https://bugzilla.mozilla.org/show_bug.cgi?id=1224244 "Mozilla is not vulnerable to the security issues that it fixes, when using either the in-tree libpng or the system libpng."