After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770143 - CVE-2016-6855 out-of-bounds write in eog 3.10.2
CVE-2016-6855 out-of-bounds write in eog 3.10.2
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: image viewer
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-19 12:54 UTC by kaslovdmitri
Modified: 2016-08-23 12:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The image open crashes eog 3.10.2 on Ubuntu 14.04 64-bit (4.39 KB, image/svg+xml)
2016-08-19 12:54 UTC, kaslovdmitri
  Details
reference patch (1.63 KB, patch)
2016-08-21 14:25 UTC, Felix Riemann
none Details | Review

Description kaslovdmitri 2016-08-19 12:54:55 UTC
Created attachment 333622 [details]
The image open crashes eog 3.10.2 on Ubuntu 14.04 64-bit

A specially craft .svg file causes eog to crash. Find the crash info below and the POC attached.


Program Counter	0x7ffff43d0540
Crash hash	540???
Crash instruction	7ffff43d0540 movzx eax, byte ptr [rbx]
Process	PID: 11652
Registers	

    r14  : 007efd20 '\x10\x90I\xe3\xff\x7f\x00\x00\xed%\x05\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
    r15  : 7ffff443c7c0 '\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01'
    r12  : 7ffff4419e84 'lg\xfb\xff\x84g\xfb\xff\x84g\xfb\xff\x84g\xfb\xffTg\xfb\xff<g\xfb\xff\x84g\xfb\xff\x84g\xfb\xff'
    r13  : 00a9a8a9 'X\x003\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00\x00\x1c\xa1'
    r10  : 0000153f
    r11  : 00000000
    es   : 00000000
    r8   : 00000002
    rdx  : 00000000
    rdi  : 7fffe3499010 'Error domain 1 code 73 on line 1'
    rcx  : 00000001
    rsi  : 00000001
    rsp  : 7fffffffd840 '\x00\xfc~\x00\x00\x00\x00\x00@\xf6~\x00\x00\x00\x00\x00`\xe4~\x00\x00\x00\x00\x00@\xa8\xa9\x00\x00\x00\x00\x00'
    rbx  : 00ae5000
    rbp  : 00ae5000
    rip  : 7ffff43d0540 '\x0f\xb6\x03\x0f\xb6\xd0\x83\xe8"I\x0f\xbe,\x17H\x01\xdd<\x1c\x0f\x87\xaf\x00\x00\x00\x0f\xb6\xc0Ic\x04\x84'
    r9   : 00000073
    rax  : 007efd20 '\x10\x90I\xe3\xff\x7f\x00\x00\xed%\x05\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
    eflags: 00010287
    

Stack trace	
Address	Module
0x7ffff43d0540	
Disassembly	
0x7ffff43d052c movabs al, byte ptr [0x994d258d4c002b8a] 
0x7ffff43d0535 add al, 0 
0x7ffff43d0537 mov r15, qword ptr [rax] 
0x7ffff43d053a nop word ptr [rax + rax] 
0x7ffff43d0540 movzx eax, byte ptr [rbx]     <---- CRASH 
0x7ffff43d0543 movzx edx, al 
0x7ffff43d0546 sub eax, 0x22 
0x7ffff43d0549 movsx rbp, byte ptr [r15 + rdx] 
0x7ffff43d054e add rbp, rbx 
0x7ffff43d0551 cmp al, 0x1c 
0x7ffff43d0553 .byte 0x0f 


Valgrind output:'

==29915== Process terminating with default action of signal 11 (SIGSEGV)
==29915==  Access not within mapped region at address 0x1C4E600C
==29915==    at 0x85D3540: g_markup_escape_text (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==29915==    by 0x85D3882: g_markup_vprintf_escaped (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==29915==    by 0x85D39DB: g_markup_printf_escaped (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==29915==    by 0x43F285: ??? (in /usr/bin/eog)
==29915==    by 0x43F48C: ??? (in /usr/bin/eog)
==29915==    by 0x4367D0: ??? (in /usr/bin/eog)
==29915==    by 0x83455E6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==29915==    by 0x835E087: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==29915==    by 0x835ECE1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==29915==    by 0x425E9B: ??? (in /usr/bin/eog)
==29915==    by 0x85CECE4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==29915==    by 0x85CF047: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
Comment 1 André Klapper 2016-08-20 19:48:02 UTC
Using eog-3.20.3-1.fc24.x86_64, I get no crash but the following output:


(eog:3744): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error domain 1 code 73 on line 1 column 4 of file:///home/user/crashEOG.svg: Couldn't find end of Start Tag \xf4

(eog:3744): Gtk-WARNING **: Failed to set text '<small>Error domain 1 code 73 on line 1 column 4 of file:///home/user/crashEOG.svg: Couldn&apos;t find end of Start Tag \xf4
X</small>' from markup due to error parsing markup: Error on line 2 char 3: Invalid UTF-8 encoded text in name - not valid 'Error domain 1 code 73 on line 1 column 4 of file:///home/user/crashEOG.svg: Couldn't find end of Start Tag \xf4
X'

(eog:3744): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
Comment 2 Felix Riemann 2016-08-21 11:00:48 UTC
Okay, there's probably two things here.

1. Overwriting the error is a problem in eog which doesn't watch out to overwrite the previous (identical) error when closing the handle. This is should be a simple fix as we already do the same for gdk-pixbuf-decoded images. The problem shouldn't cause any problems besides the leaked error though.

2. The second problem, the crash in GMarkup, seems to be caused by the non-UTF8 character in the error message. This was apparently a weakness glib seems to have been hardened against (bug 631597) since 2.44.1 (GNOME 3.16) so it's not segfaultin anymore on recent distros. I'll try to verify this. 

Although it's a problem in older glib versions I'm not saying it's a bug but a weakness in glib as eog is actually passing unsupported data to GMarkup (which is UTF8-only) here. I'll see if eog's UTF8 sanitizing code can be applied here.
Comment 3 Felix Riemann 2016-08-21 13:11:38 UTC
(In reply to Felix Riemann from comment #2)
> Okay, there's probably two things here.
> 
> 1. Overwriting the error is a problem in eog which doesn't watch out to
> overwrite the previous (identical) error when closing the handle. This is
> should be a simple fix as we already do the same for gdk-pixbuf-decoded
> images. The problem shouldn't cause any problems besides the leaked error
> though.

I split that bug off into bug 770197.
Comment 4 Felix Riemann 2016-08-21 14:21:19 UTC
So, this is indeed as I thought in comment 2.

GMarkup in glib pre-2.44.1 could cause this out-of-bounds access if given invalid input (bug 631597). eog triggered this by passing invalid UTF8 to GMarkup.
I patched eog now to make sure the error messages in the ErrorMessageArea are valid UTF8.  This also avoids the broken markup when using newer glib versions that wouldn't crash anymore.

I'll do new eog-3.18 and 3.20 releases and possibly also a 3.16 tarball containing this fix. I won't prepare older releases for now though as the demand for those should rather small and LTS distros in my experience tend to prefer cherry-picking patches over newer tarballs anyway.

Thanks for reporting this.

commit e99a8c00f959652fe7c10e2fa5a3a7a5c25e6af4
Author: Felix Riemann <>
Date:   Sun Aug 21 15:56:46 2016 +0200

    EogErrorMessageArea: Make sure error messages are valid UTF8
    
    GMarkup requires valid UTF8 input strings and would cause odd
    looking messages if given invalid input. This could also trigger an
    out-of-bounds write in glib before 2.44.1. Reported by kaslovdmitri.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=770143
---
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
Comment 5 Felix Riemann 2016-08-21 14:25:50 UTC
Created attachment 333820 [details] [review]
reference patch

Attaching the patch for easier reference and cherry-picking.
Comment 6 kaslovdmitri 2016-08-23 12:52:24 UTC
You patched this way sooner than I anticipated.
It was a pleasure reporting this