oss-sec mailing list archives

Browsing and attaching images considered harmful in Linux


From: Gustavo Grieco <gustavo.grieco () gmail com>
Date: Mon, 4 Jul 2016 21:13:05 +0200

Hi,

I would like to bring the attention of the oss-security list to the
existence of many security issues in the gdk-pixbuf library and its
dependencies causing a that attaching a corrupted image file in Linux
has become a risky business. For instance,  there is a read
out-of-bounds in librsvg2 (a dependency of gdk-pixbuf used to render
svg images), which can be easily triggered if you try to attach a svg
in Firefox. I tested it in Ubuntu 14.04 (x86_64) using the
corresponding version of librsvg2 (2.40.2-1 with debug symbols) and
Firefox. To reproduce:

1. Download and unpack boom.tar.gz somewhere.
2. gdb --args /usr/lib/firefox/firefox
3. Execute "run" and try to attach (ctrl+o) the svg file inside boom
directory in Firefox.

Result:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffbb7a4c0d in rsvg_pattern_fix_fallback
(pattern=pattern@entry=0x7ffffffea110) at rsvg-paint-server.c:645
645        rsvg-paint-server.c: No such file or directory.
(gdb) bt
#0  0x00007fffbb7a4c0d in rsvg_pattern_fix_fallback
(pattern=pattern@entry=0x7ffffffea110) at rsvg-paint-server.c:645
#1  0x00007fffbb7c0650 in _set_source_rsvg_pattern
(ctx=0x7fffc1672b00, rsvg_pattern=0x7ffffffea110, opacity=<optimized
out>, bbox=...)
    at rsvg-cairo-draw.c:195
#2  0x00007fffbb7c1e4d in rsvg_cairo_render_path (ctx=0x7fffc1672b00,
path=<optimized out>) at rsvg-cairo-draw.c:526
#3  0x00007fffbb7bea12 in rsvg_render_path
(ctx=ctx@entry=0x7fffc1672b00, path=path@entry=0x7fffc4708640) at
rsvg-base.c:1976
#4  0x00007fffbb7b59c8 in _rsvg_node_rect_draw (self=0x7fffc45c6f50,
ctx=0x7fffc1672b00, dominate=0) at rsvg-shapes.c:479
#5  0x00007fffbb7b6503 in rsvg_node_draw (self=0x7fffc45c6f50,
ctx=0x7fffc1672b00, dominate=<optimized out>) at rsvg-structure.c:69
#6  0x00007fffbb7b6583 in _rsvg_node_draw_children
(self=0x7fffc8058560, ctx=0x7fffc1672b00, dominate=0) at
rsvg-structure.c:87
#7  0x00007fffbb7b6503 in rsvg_node_draw (self=0x7fffc8058560,
ctx=0x7fffc1672b00, dominate=<optimized out>) at rsvg-structure.c:69
#8  0x00007fffbb7b6903 in rsvg_node_svg_draw (self=0x7fffc4915080,
ctx=0x7fffc1672b00, dominate=<optimized out>) at rsvg-structure.c:323
#9  0x00007fffbb7b6503 in rsvg_node_draw (self=0x7fffc4915080,
ctx=0x7fffc1672b00, dominate=<optimized out>) at rsvg-structure.c:69
#10 0x00007fffbb7c2ac3 in rsvg_handle_render_cairo_sub
(handle=handle@entry=0x7fffc8cd3440, cr=cr@entry=0x7fffd7d58000,
id=id@entry=0x0)
    at rsvg-cairo-render.c:225
#11 0x00007fffbb7c2ef4 in rsvg_handle_get_pixbuf_sub
(handle=0x7fffc8cd3440, id=id@entry=0x0) at rsvg.c:90
#12 0x00007fffbb7c2f77 in rsvg_handle_get_pixbuf (handle=<optimized
out>) at rsvg.c:119
#13 0x00007fffbb9cee46 in gdk_pixbuf__svg_image_stop_load
(data=0x7fffc50e18e0, error=0x7ffffffea6b8) at io-svg.c:160
#14 0x00007ffff35d31fb in gdk_pixbuf_loader_close
(loader=loader@entry=0x7fffc4424ea0, error=error@entry=0x0) at
gdk-pixbuf-loader.c:821
#15 0x00007ffff35d0e2a in gdk_pixbuf_new_from_file_at_scale
(filename=0x7fffc4577100
"/home/g/Work/Code/ef/gdk-pixbuf/svg/overflow-real-reap.svg",
    width=<optimized out>, height=<optimized out>,
preserve_aspect_ratio=<optimized out>, error=0x0) at
gdk-pixbuf-io.c:1372
#16 0x00007fffeafc7d19 in UpdateFilePreviewWidget
(file_chooser=0x7fffd9d53a30, preview_widget_voidptr=<optimized out>)
    at /build/firefox-mh9_e1/firefox-46.0.1+build1/widget/gtk/nsFilePicker.cpp:115
#17 0x00007ffff25273b8 in g_closure_invoke () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff2538d3d in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
...

It is interesting to note that rcx looks controllable:

(gdb) x/i $rip
=> 0x7fffbb7a4c0d <rsvg_pattern_fix_fallback+333>:        testb  $0x4,0xe4(%rcx)
(gdb) info registers
...
rcx            0xe5e5e5e5e5e5e5e5        -1880844493789993499
...

Fortunately, this issue is already solved in the last revision of
librsvg2 (AFAIK, this issue has no CVE, so please MITRE assign one if
suitable). Nevertheless, I reported such vulnerability to Mozilla more
than a month ago hoping that they will disable the svg support in the
open/attach widget. After some discussion, it was marked as WONTFIX.
While i understand why, i still feel it can be productive to discuss
this here.

(the same trick can be used to crash Chrome/Chromium, since the code
to open/attach an image is almost the same, so this is not a Firefox
specific issue)


Regards,
Gustavo

Attachment: boom.tar.gz
Description:


Current thread: