A malicious website serving a malicious PNG file could:
\n – Compromise the browsers of visitors.
\n – A malicious PNG could be sent via e-mail and compromise
\n the e-mail viewer of the recipient.
\n – For systems with user-providable images for “face
\n browsers”, a local system compromise could be possible via
\n a malicious PNG.<\/p>\n
Want more?<\/p>\n
[url=http:\/\/deepquest.code511.com\/pngvery_bad.png]Proof of concept[\/url]
\nwill only crash you browser.<\/p>\n
This advisory lists code flaws discovered by inspection of the libpng-1.2.5
\ncode. Only the first one has been examined in practice to confirm
\nexploitability. The other flaws certainly warrant fixing.<\/p>\n
A patch which should plug all these issues is appended beneath the advisory.
\nNOTE! This patch serves as demo purposes for the flaws only. An official
\nv1.2.6 libpng with an official, slightly different fix will be released by
\nthe libpng team in parallel with this advisory.<\/p>\n
1) Remotely exploitable stack-based buffer overrun in png_handle_tRNS
\n(pngrutil.c)<\/p>\n
If a PNG file is of the correct format, a length check on PNG data is missed
\nprior to filling a buffer on the stack from the PNG data. The exact flaw would
\nseem to be a logic error; failure to bail out of a function after a warning
\ncondition is hit, here:<\/p>\n
if (!(png_ptr->mode & PNG_HAVE_PLTE))
\n {
\n \/* Should be an error, but we can cope with it *\/
\n png_warning(png_ptr, “Missing PLTE before tRNS”);
\n }
\n else if (length > (png_uint_32)png_ptr->num_palette)
\n {
\n png_warning(png_ptr, “Incorrect tRNS chunk length”);
\n png_crc_finish(png_ptr, length);
\n return;
\n }<\/p>\n
We can see, if the first warning condition is hit, the length check is missed
\ndue to the use of an “else if”.<\/p>\n
A scarier possibility is targetted exploitation by e-mailing a nasty PNG to
\nsomeone who uses a graphical e-mail client to decode PNGs with a vulnerable
\nlibpng.<\/p>\n
2) Dangerous code in png_handle_sBIT (pngrutil.c) (Similar code in
\npng_handle_hIST).<\/p>\n
Although seemingly not exploitable, there is dangerous code in this function.
\nIt relies on checks scattered elsewhere in the code in order to not overflow
\na 4-byte stack buffer. This line here should upper-bound the read onto the
\nstack to 4 bytes:<\/p>\n
png_crc_read(png_ptr, buf, truelen);<\/p>\n
3) Possible NULL-pointer crash in png_handle_iCCP (pngrutil.c) (this flaw is
\nduplicated in multiple other locations).<\/p>\n
There are lots of lines such as these in the code:<\/p>\n
chunkdata = (png_charp)png_malloc(png_ptr, length + 1);<\/p>\n
Where “length” comes from the PNG. If length is set to UINT_MAX then length + 1 will equate to
\nzero, leading to the PNG malloc routines to return NULL and
\nsubsequent access to crash. These lengths are sometimes checked to ensure
\nthey are smaller that INT_MAX, but it is not clear that all code paths perform
\nthis check, i.e. png_push_read_chunk in pngpread.c does not do this check
\n(this is progressive reading mode as used by browsers).<\/p>\n
4) Theoretical integer overflow in allocation in png_handle_sPLT (pngrutil.c)<\/p>\n
This isn’t likely to cause problems in practice, but there’s the possibility
\nof an integer overflow during this allocation:<\/p>\n
new_palette.entries = (png_sPLT_entryp)png_malloc(
\n png_ptr, new_palette.nentries * sizeof(png_sPLT_entry));<\/p>\n
5) Integer overflow in png_read_png (pngread.c)<\/p>\n
A PNG with excessive height may cause an integer overflow on a memory
\nallocation and subsequent crash allocating row pointers. This line is possibly
\nfaulty; I can’t see anywhere that enforces a maximum PNG height:<\/p>\n
info_ptr->row_pointers = (png_bytepp)png_malloc(png_ptr,
\n info_ptr->height * sizeof(png_bytep));<\/p>\n
6) Integer overflows during progressive reading.<\/p>\n
There are many lines like the following, which are prone to integer overflow:<\/p>\n
if (png_ptr->push_length + 4 > png_ptr->buffer_size)<\/p>\n
It is not clear how dangerous this is.<\/p>\n
7) Other flaws.<\/p>\n
There is broad potential for other integer overflows which I have not spotted –
\nthe amount of integer arithmetic surrounding buffer handling is large,
\nunfortunately.<\/p>\n
CESA-2004-001 – rev 3
\nChris Evans
\n[email]chris@scary.beasts.org[\/email]<\/p>\n
[Advertisement: I am interested in moving into a security related field
\n full-time. E-mail me to discuss.]<\/p>\n
diff -ru libpng-1.2.5\/png.h libpng-1.2.5.fix\/png.h
\n— libpng-1.2.5\/png.h 2002-10-03 12:32:26.000000000 +0100
\n+++ libpng-1.2.5.fix\/png.h 2004-07-13 23:18:10.000000000 +0100
\n@@ -835,6 +835,9 @@
\n \/* Maximum positive integer used in PNG is (2^31)-1 *\/
\n #define PNG_MAX_UINT ((png_uint_32)0x7fffffffL)<\/p>\n
+\/* Constraints on width, height, (2 ^ 24) – 1*\/
\n+#define PNG_MAX_DIMENSION 16777215
\n+
\n \/* These describe the color_type field in png_info. *\/
\n \/* color type masks *\/
\n #define PNG_COLOR_MASK_PALETTE 1
\ndiff -ru libpng-1.2.5\/pngpread.c libpng-1.2.5.fix\/pngpread.c
\n— libpng-1.2.5\/pngpread.c 2002-10-03 12:32:28.000000000 +0100
\n+++ libpng-1.2.5.fix\/pngpread.c 2004-07-13 23:03:58.000000000 +0100
\n@@ -209,6 +209,8 @@<\/p>\n
png_push_fill_buffer(png_ptr, chunk_length, 4);
\n png_ptr->push_length = png_get_uint_32(chunk_length);
\n+ if (png_ptr->push_length > PNG_MAX_UINT)
\n+ png_error(png_ptr, “Invalid chunk length.”);
\n png_reset_crc(png_ptr);
\n png_crc_read(png_ptr, png_ptr->chunk_name, 4);
\n png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
\n@@ -638,6 +640,8 @@<\/p>\n
png_push_fill_buffer(png_ptr, chunk_length, 4);
\n png_ptr->push_length = png_get_uint_32(chunk_length);
\n+ if (png_ptr->push_length > PNG_MAX_UINT)
\n+ png_error(png_ptr, “Invalid chunk length.”);<\/p>\n
png_reset_crc(png_ptr);
\n png_crc_read(png_ptr, png_ptr->chunk_name, 4);
\ndiff -ru libpng-1.2.5\/pngrutil.c libpng-1.2.5.fix\/pngrutil.c
\n— libpng-1.2.5\/pngrutil.c 2004-07-13 13:36:37.000000000 +0100
\n+++ libpng-1.2.5.fix\/pngrutil.c 2004-07-13 23:43:02.000000000 +0100
\n@@ -350,7 +350,11 @@
\n png_crc_finish(png_ptr, 0);<\/p>\n
width = png_get_uint_32(buf);
\n+ if (width > PNG_MAX_DIMENSION)
\n+ png_error(png_ptr, “Width is too large”);
\n height = png_get_uint_32(buf + 4);
\n+ if (height > PNG_MAX_DIMENSION)
\n+ png_error(png_ptr, “Height is too large”);
\n bit_depth = buf[8];
\n color_type = buf[9];
\n compression_type = buf[10];
\n@@ -675,7 +679,7 @@
\n else
\n truelen = (png_size_t)png_ptr->channels;<\/p>\n
– if (length != truelen)
\n+ if (length != truelen || length > 4)
\n {
\n png_warning(png_ptr, “Incorrect sBIT chunk length”);
\n png_crc_finish(png_ptr, length);
\n@@ -1244,7 +1248,8 @@
\n \/* Should be an error, but we can cope with it *\/
\n png_warning(png_ptr, “Missing PLTE before tRNS”);
\n }
\n– else if (length > (png_uint_32)png_ptr->num_palette)
\n+ if (length > (png_uint_32)png_ptr->num_palette ||
\n+ length > PNG_MAX_PALETTE_LENGTH)
\n {
\n png_warning(png_ptr, “Incorrect tRNS chunk length”);
\n png_crc_finish(png_ptr, length);
\n@@ -1400,7 +1405,7 @@
\n void \/* PRIVATE *\/
\n png_handle_hIST(png_structp png_ptr, png_infop info_ptr, png_uint_32 length)
\n {
\n– int num, i;
\n+ unsigned int num, i;
\n png_uint_16 readbuf[PNG_MAX_PALETTE_LENGTH];<\/p>\n
png_debug(1, “in png_handle_hIST\\n”);
\n@@ -1426,8 +1431,8 @@
\n return;
\n }<\/p>\n
– num = (int)length \/ 2 ;
\n– if (num != png_ptr->num_palette)
\n+ num = length \/ 2 ;
\n+ if (num != png_ptr->num_palette || num > PNG_MAX_PALETTE_LENGTH)
\n {
\n png_warning(png_ptr, “Incorrect hIST chunk length”);
\n png_crc_finish(png_ptr, length);
\n@@ -2868,6 +2873,9 @@
\n png_read_data(png_ptr, chunk_length, 4);
\n png_ptr->idat_size = png_get_uint_32(chunk_length);<\/p>\n
+ if (png_ptr->idat_size > PNG_MAX_UINT)
\n+ png_error(png_ptr, “Invalid chunk length.”);
\n+
\n png_reset_crc(png_ptr);
\n png_crc_read(png_ptr, png_ptr->chunk_name, 4);
\n if (png_memcmp(png_ptr->chunk_name, (png_bytep)png_IDAT, 4))<\/p>\n
discovered by Chris Evans<\/p>\n","protected":false},"excerpt":{"rendered":"
libPNG 1.2.5 stack-based buffer overflow and other code concerns<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-201","post","type-post","status-publish","format-standard","hentry","category-security"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p4bBYZ-3f","_links":{"self":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts\/201","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/comments?post=201"}],"version-history":[{"count":0,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts\/201\/revisions"}],"wp:attachment":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/media?parent=201"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/categories?post=201"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/tags?post=201"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}