Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 611390 (CVE-2017-6311, CVE-2017-6312, CVE-2017-6313, CVE-2017-6314) - <x11-libs/gdk-pixbuf-2.36.9: multiple vulnerabilities
Summary: <x11-libs/gdk-pixbuf-2.36.9: multiple vulnerabilities
Alias: CVE-2017-6311, CVE-2017-6312, CVE-2017-6313, CVE-2017-6314
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B2 [glsa cve]
: 611664 611666 611672 (view as bug list)
Depends on:
Blocks: CVE-2017-2862, CVE-2017-2870
  Show dependency tree
Reported: 2017-03-02 09:16 UTC by Agostino Sarubbo
Modified: 2017-09-17 15:49 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: Yes
stable-bot: sanity-check+

CVE-2017-6311.patch (CVE-2017-6311.patch,696 bytes, patch)
2017-06-23 23:59 UTC, Andrey Ovcharov
no flags Details | Diff
CVE-2017-6312.patch (CVE-2017-6312.patch,890 bytes, patch)
2017-06-24 00:00 UTC, Andrey Ovcharov
no flags Details | Diff
CVE-2017-6314.patch (CVE-2017-6314.patch,633 bytes, patch)
2017-06-24 00:00 UTC, Andrey Ovcharov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2017-03-02 09:16:37 UTC
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
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 =

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

Thanks to afl for helping me find bugs 3 and 4.


[6] A blog post I wrote about this -

@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.
Comment 1 Agostino Sarubbo gentoo-dev 2017-03-04 10:59:36 UTC
*** Bug 611672 has been marked as a duplicate of this bug. ***
Comment 2 Agostino Sarubbo gentoo-dev 2017-03-04 10:59:38 UTC
*** Bug 611666 has been marked as a duplicate of this bug. ***
Comment 3 Agostino Sarubbo gentoo-dev 2017-03-04 10:59:41 UTC
*** Bug 611664 has been marked as a duplicate of this bug. ***
Comment 4 GLSAMaker/CVETool Bot gentoo-dev 2017-05-16 06:24:27 UTC
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 (
  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 (
  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 (
  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.
Comment 5 Andrey Ovcharov 2017-06-23 23:59:49 UTC
Created attachment 477746 [details, diff]
Comment 6 Andrey Ovcharov 2017-06-24 00:00:18 UTC
Created attachment 477748 [details, diff]
Comment 7 Andrey Ovcharov 2017-06-24 00:00:47 UTC
Created attachment 477750 [details, diff]
Comment 8 Gilles Dartiguelongue (RETIRED) gentoo-dev 2017-08-28 22:06:26 UTC
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
Comment 9 Aaron Bauman (RETIRED) gentoo-dev 2017-08-31 22:49:16 UTC
@maintainer(s), please let us know when you are ready to stabilize.
Comment 10 Gilles Dartiguelongue (RETIRED) gentoo-dev 2017-09-02 11:03:46 UTC
Hello arches, please proceed with the stabilization of =x11-libs/gdk-pixbuf-2.36.9
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2017-09-02 15:56:57 UTC
ia64 stable
Comment 12 Aaron Bauman (RETIRED) gentoo-dev 2017-09-02 18:41:02 UTC
amd64/x86 stable
Comment 13 Tobias Klausmann (RETIRED) gentoo-dev 2017-09-04 10:49:34 UTC
Stable on alpha.
Comment 14 Markus Meier gentoo-dev 2017-09-05 04:38:28 UTC
arm stable
Comment 15 Sergei Trofimovich (RETIRED) gentoo-dev 2017-09-08 07:46:49 UTC
stable for hppa/sparc (thanks to Dakon)
Comment 16 Sergei Trofimovich (RETIRED) gentoo-dev 2017-09-09 17:24:49 UTC
stable for ppc/ppc64

Last arches are done.
Comment 17 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2017-09-09 17:36:29 UTC
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
Comment 18 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2017-09-09 18:57:03 UTC
@Maintainers, my bad, sorry for the noise, please proceed with cleanup.

Gentoo Security Padawan
Comment 19 Gilles Dartiguelongue (RETIRED) gentoo-dev 2017-09-10 10:18:31 UTC
Just cleaned up affected revisions in 004ec7a497d0afbb3cb2528c1c555d95dc65539f
Comment 20 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2017-09-10 16:29:04 UTC
Thank you Gilles,

@Security please add to an existing glsa or file a new one.

Gentoo Security Padawan
Comment 21 Aaron Bauman (RETIRED) gentoo-dev 2017-09-10 23:07:31 UTC
GLSA request opened.
Comment 22 GLSAMaker/CVETool Bot gentoo-dev 2017-09-17 15:49:39 UTC
This issue was resolved and addressed in
 GLSA 201709-08 at
by GLSA coordinator Aaron Bauman (b-man).