1475514 - AddressSanitizer: heap-buffer-overflow [@ __interceptor_index] with READ of size 11 (through GTK and XcursorLibraryLoadImages)

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Christian Holler (:decoder)]

The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 63.0a1-20180711221812-https://hg.mozilla.org/mozilla-central/rev/3aca103e49150145dbff910be15e7886b7c4495a (originally reported by unknown).

For detailed crash information, see attachment.


Not sure if this is actionable because the memory violation appears to be in libXcursor and there is no debug information available for this library and GTK on the submitting machine.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Daniel Veditz [:dveditz]]

Does the ASan Nightly Reporter collect any of the other metadata that our crash reporter does? In particular system OS and version, the version of libraries referenced in the process, etc?

Alex says there's a CVE for libXcursor that was fixed in version 1.1.15 (CVE-2017-16612) which might be related?

Was there an email associated with this one so we can ask questions?

Comment 3

[Christian Holler (:decoder)]

(In reply to Daniel Veditz [:dveditz] from comment #2)
> Does the ASan Nightly Reporter collect any of the other metadata that our
> crash reporter does? In particular system OS and version, the version of
> libraries referenced in the process, etc?

Only that it is Linux, and no specific distro information. And we also don't collect any information about installed libraries. 

> Alex says there's a CVE for libXcursor that was fixed in version 1.1.15
> (CVE-2017-16612) which might be related?

Could be. There is no way for me to tell the version of the affected library right now unfortunately :/

> Was there an email associated with this one so we can ask questions?

I searched for reports with an email, unfortunately there were none so far. I will try again if I see more reports.

Comment 4

[Christian Holler (:decoder)]

The original reporter has libXcursor 1.1.14-1ubuntu0.16.04.1 installed, which appears to be the latest version available for Ubuntu 16.04 and derivatives. According to the Ubuntu advisory for that CVE (https://usn.ubuntu.com/3501-1/), this version has the fix for that CVE. I assume it must be another problem then. We can try to fully symbolize the trace on an Ubuntu 16.04 with debug symbols for libXcursor installed.

Comment 5

[Christian Holler (:decoder)]

Attachment: Fully symbolized crash information on Ubuntu 16.04.4

Using a docker image for 16.04, I was able to symbolize the GTK and libXcursor parts of the trace. Of course any source references refer to Ubuntu sources which are potentially patched. The libXcursor version used here is 1.1.14-1ubuntu0.16.04.1.

Maybe someone else can pick this up and investigate if this is

1) An issue with libXcursor or our fault.
2) If it is in libXcursor, check if it has been fixed and report upstream if necessary.

Comment 6

[Alex Gaynor [:Alex_Gaynor]]

I believe this could theoretically be caused by https://bugs.freedesktop.org/show_bug.cgi?id=90857, which is not included in Ubuntu 16.04. Here's how it'd go:

|_XcursorThemeInherits| allocates |result| (which will become |inherits| in |XcursorScanTheme|). It writes some string bytes to |result|, and then writes the NUL terminator one past the end of the array.

Next something else gets allocated, because these are small allocations, it's right next to |result| from |_XcursorThemeInherits|. When it gets written to, the NUL byte is overwritten with something else.

|XcursorScanTheme| passes |inherits| to |_XcursorBuildThemeDir|, which calls |strchr| on it. Now the NUL byte is no longer there, so it keeps reading into the second allocation.

This would cause the stack trace we saw. If I've read the code correctly, the NUL byte is _always_ written past the end of the allocation, so the necessary conditions for this to occur would be:

1) A second allocation between |_XcursorThemeInherits| and the |strchr|.
2) The allocations being sized such that |strlen() + 1| byte from the first allocation is a part of the second allocation, and thus overwritten.

I've now spent more time than I intended looking at this (including writing a fuzzer for |_XcursorThemeInherits|, which independently rediscovered that upstream bug). Can someone sanity check this?

Comment 7

[Alex Gaynor [:Alex_Gaynor]]

Oh, one more detail: the circumstances I would describe would match this ASAN report -- libXcursor is not compiled with ASAN, so the normal heap-buffer-overflow WRITE 1 is not caught, but it is still linked against the ASAN strchr, so that's why the read is caught, but not the write.

Comment 8

[Alex Gaynor [:Alex_Gaynor]]

I realized I could slap a |__attribute__((no_sanitize("address")))| on |_XcursorThemeInherits| in order to simulate having an ASAN runtime but not ASAN-ing the heap-buffer-overflow WRITE 1. It confirms my hypothesis.

At this point I'm now very confident in my theory. I emailed the x.org security list to see about getting a CVE issued for the upstream bug and getting it backported to Ubuntu and whatever other distros.

Comment 10

[Alex Gaynor [:Alex_Gaynor]]

After a bit of back-and-forth with the x.org folks, they've ok'd getting a CVE, now waiting for one of the distros to issue it. Then I'll try to get Ubuntu to backport the fix. *Gazes upon the stack of yaks*

Comment 11

[Alex Gaynor [:Alex_Gaynor]]

CVE-2015-9262 has been issued for the libXcursor bug. I'll now move up the stack to trying to get Ubuntu/Debian to backport the fix.

Comment 12

[Alex Gaynor [:Alex_Gaynor]]

And it's now been packaged and released for Ubuntu: https://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-9262.html (https://usn.ubuntu.com/3729-1/).

I think we can call this fixed. (Some other distros haven't upgraded yet, but unless we're getting reports from them, I don't think there's a need to hold this open.)

Comment 13

[Daniel Veditz [:dveditz]]

Bugs in the underlying OS are not covered by our bug bounty program

Comment 14

[sampath.rajapakse]

(In reply to Daniel Veditz [:dveditz] from comment #13)
> Bugs in the underlying OS are not covered by our bug bounty program

Thanks, I was already aware of this.