From ${URL} : 1. An dangerous integer underflow in io-icns.c [1] -------------------------------------------------- io-icns.c is the source code for the loader of Macintosh icons. An integer underflow I found allows an attacker to lead to different calls to gdk_pixbuf_loader_write with a huge (2^32-1) count (size of buffer) that can be bigger than the actual size of given buffer. It is possible to give the loader any data we want so we can call any desired loader that it's data is recognized. This may lead to various behaviors - multiple out-of-buffer reads, infinite loops, or allocation attempt with the size. Possibly other behaviors I did not test for (I didn't really check all available loaders). 1.1 The bug ----------- In the load_resources function (io-icns.c:63), inside the size switch (line 101), all the cases set plen or mlen to: blocklen - sizeof (IcnsBlockHeader); See lines 109, 117, 127, 134, 139, 146, 151, 158 and 163. blocklen is set in line 95: blocklen = GUINT32_FROM_BE (header->size); There are no checks on the size of blocklen and if it is set to less than sizeof (IcnsBlockHeader) (should be 8) there is an integer underflow. This is dangerous because it's value is later passed to gdk_pixbuf_loader_write (line 262) when size is 256. This allows an attacker to craft a file that will end up calling to a desired loader with a bogus size that is much larger than the actual buffer size. Possible exploits of the bug: 1. Adding a bmp, or a an ico image data after the header will cause an out-of-buffer read. 2. With a tiff image it would lead to an infinite loop (see bug 2). 3. With a gif, a tga or another icns after the header the code will try to allocate as much as count bytes (and most likely fail on a size of 2^32-1). Otherwise if the actual data size is less than 4096 there is an out-of-bounds read. 4. With another icns it is possible to reach another out-of-bounds 4.1 If this out-of-bounds read gets zeros we will have an infinite loop 2. Infinite loop in io-tiff.c [2] --------------------------------- This loader for tiff images will try and allocate a buffer as big as size given to it. It calls the make_available_at_least function to do that. The problem is in the function itself (from line 499): if (need_alloc > context->allocated) { guint new_size = 1; while (new_size < need_alloc) new_size *= 2; ... new_size starts with 1 and multiplies until it is larger or equal to need_alloc. If need_alloc is larger than 2^31, new_size will become 2^31 and multiply itself in 2, and become 0. This would lead to an infinite loop. 3. Out-of-bounds read on io-ico.c [3] ------------------------------------- io-ico.c is the source code for the loader of Windows icons. State->HeaderSize is calculated in line 334: State->HeaderSize = entry->DIBoffset + INFOHEADER_SIZE entry->DIBoffset is read directly from the data An integer overflow seems possible. However in line 336 it is checked if (State->HeaderSize < 0), to prevent such overflow. This works when compiling without or with basic optimization (in gcc, -O0 or -O1), but from -O2 this check seems to be ignored. Specifically when compiled with "O1 -fstrict-overflow -ftree-vrp". I believe many distributions are building with these flags. When this is overflown it is possible later to reach a segmentation fault thanks to an out-of-bounds read of the BIH variable (line 359: BIH = Data+entry->DIBoffset;). I tested this both on Arch and on Ubuntu 16.04.1 but it certainly affects other distributions as well. 4. NULL dereference on gdk-pixbuf-thumbnailer [4] ------------------------------------------------- This is a bug in gnome-thumbnailer-skeleton.c and it affects only the latest versions of gdk-pixbuf (since moving the code from gnome-desktop the the external thumbnailer in gdk-pixbuf[5]). gnome-thumbnailer-skeleton.c:272 calls file_to_pixbuf. file_to_pixbuf (gdk-pixbuf-thumbnailer.c:209) calls _gdk_pixbuf_new_from_uri_at_scale, which calls gdk_pixbuf_loader_get_pixbuf (see gdk-pixbuf-thumbnailer:195). gdk_pixbuf_loader_get_pixbuf may returns NULL, and it doesn't get a pointer to an error object to set an error. So when it returns NULL, on file_to_pixbuf pixbuf will be NULL, and on line 312 printing error->message will result in a NULL deference (error->message will be 0x0 + 0x8). 5. Impact --------- These bugs can break many binaries that rely on gdk-pixbuf and I can think of various ways these bugs can be used maliciously. Obvious applications are to cause DoS by segmentation faults or possibly by CPU exhaustion (with the infinite loops) when possible. Besides crashing the thumbnailer and some other desktop applications that use gdk-pixbuf I also managed to crash Chromium and Firefox on Ubuntu (on both via their file browser which use gdk-pixbuf). To see the full list of packages that use gdk-pixbuf on apt based distributions run `apt-cache rdepends libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-dev`. Thanks to afl for helping me find bugs 3 and 4. Links [1] https://bugzilla.gnome.org/show_bug.cgi?id=779016 [2] https://bugzilla.gnome.org/show_bug.cgi?id=779020 [3] https://bugzilla.gnome.org/show_bug.cgi?id=779012 [4] https://bugzilla.gnome.org/show_bug.cgi?id=778204 [5] https://git.gnome.org/browse/gdk-pixbuf/commit/?id=06cf4c78067203b78acbfb29862350cdb8200b73 [6] A blog post I wrote about this - http://mov.sx/2017/02/21/bug-hunting-gdk-pixbuf.html @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
*** Bug 611672 has been marked as a duplicate of this bug. ***
*** Bug 611666 has been marked as a duplicate of this bug. ***
*** Bug 611664 has been marked as a duplicate of this bug. ***
CVE-2017-6314 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-6314): The make_available_at_least function in io-tiff.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (infinite loop) via a large TIFF file. CVE-2017-6313 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-6313): Integer underflow in the load_resources function in io-icns.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (out-of-bounds read and program crash) via a crafted image entry size in an ICO file. CVE-2017-6312 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-6312): Integer overflow in io-ico.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (segmentation fault and application crash) via a crafted image entry offset in an ICO file, which triggers an out-of-bounds read, related to compiler optimizations. CVE-2017-6311 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-6311): gdk-pixbuf-thumbnailer.c in gdk-pixbuf allows context-dependent attackers to cause a denial of service (NULL pointer dereference and application crash) via vectors related to printing an error message.
Created attachment 477746 [details, diff] CVE-2017-6311.patch
Created attachment 477748 [details, diff] CVE-2017-6312.patch
Created attachment 477750 [details, diff] CVE-2017-6314.patch
commit c50f87a60070448db5c88e40f671826e0eeb449e Date: Tue Aug 29 00:01:52 2017 +0200 x11-libs/gdk-pixbuf: security version bump 2.36.6 → 2.36.9, bug #611390
@maintainer(s), please let us know when you are ready to stabilize.
Hello arches, please proceed with the stabilization of =x11-libs/gdk-pixbuf-2.36.9
ia64 stable
amd64/x86 stable
Stable on alpha.
arm stable
stable for hppa/sparc (thanks to Dakon)
stable for ppc/ppc64 Last arches are done.
Thank you. @Maintainers please verify dependencies for vulnerable versions. Several packages seem to depend on slot 2 from gdk-pixbuf which is vulnerable. @Security please add to an existing glsa or file a new one Gentoo Security Padawan ChrisADR
@Maintainers, my bad, sorry for the noise, please proceed with cleanup. Gentoo Security Padawan ChrisADR
Just cleaned up affected revisions in 004ec7a497d0afbb3cb2528c1c555d95dc65539f
Thank you Gilles, @Security please add to an existing glsa or file a new one. Gentoo Security Padawan ChrisADR
GLSA request opened.
This issue was resolved and addressed in GLSA 201709-08 at https://security.gentoo.org/glsa/201709-08 by GLSA coordinator Aaron Bauman (b-man).
