Bugzilla – Bug 987877
VUL-1: CVE-2016-6163: librsvg: svg pattern linking to non-pattern fallback leads to invalid memory access
Last modified: 2024-05-22 14:20:10 UTC
from http://seclists.org/oss-sec/2016/q3/7 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 ... > Use CVE-2016-6163 for this specific "read out-of-bounds in librsvg2 (a > dependency of gdk-pixbuf used to render svg images)." From http://seclists.org/oss-sec/2016/q3/18 > If I correctly bisected with the reproducer, then the fix should be > around > https://git.gnome.org/browse/librsvg/commit/?id=0035e95118a60c0cd3949c2300472d805e16a022 > (2.40.7). References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6163 http://seclists.org/oss-sec/2016/q3/16
Created attachment 683200 [details] reproducer
Reproducer does not work for me
bugbot adjusting priority
I have a repository for the backports to librsvg-2.26.0 here: https://gitlab.suse.de/federico-mena/librsvg/tree/suse-2.26.0-to-2.40.16 This is the codebase for 2.40.16 backported to 2.26.0, and adjusted to work with GTK2 (the new version uses GTK3). This takes care of the CVEs. It builds out of git, but I'm having trouble with the RPM. I'll keep working on this.
Submitted to SUSE:SLE-11-SP1:Update with id 126310. Submitted to SUSE:SLE-11:Update with id 126411.
Federico - can you take this...
(Sorry, I mistyped the request number above; it was meant to be 126410.) I'm adding some extra patches to librsvg for SLE-11:Update - apparently gtk2 and glib are too old there and don't have certain symbols.
Submitted to SUSE:SLE-12:Update - https://build.suse.de/request/show/238214 This is an update to librsvg-2.40.21, with fixes for all the CVEs since 2016. I think this is linked into SLE-12-SP1:Update - will this update in SLE-12:Update make it there, too? Next, I'll look into an update for SLE-11:Update, which has librsvg-2.22.3.
Submitted for SUSE:SLE-11:Update - https://build.suse.de/request/show/238366 When this and the 238214 above get accepted, we'll have up-to-date librsvg packages across all code streams, security-wise.
Cleaning up GNOME CVE backlog. The fix has been submitted but declined for "codestream is EOL". Assign back to security team.
All done, closing.