[cairo-bugs] [Bug 92904] New: Large amount of uninitialized values in svg parsing and processing

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Nov 11 09:09:53 PST 2015


https://bugs.freedesktop.org/show_bug.cgi?id=92904

            Bug ID: 92904
           Summary: Large amount of uninitialized values in svg parsing
                    and processing
           Product: cairo
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: medium
         Component: svg backend
          Assignee: emmanuel.pacaud at lapp.in2p3.fr
          Reporter: gustavo.grieco at imag.fr
        QA Contact: cairo-bugs at cairographics.org

**This is a copy of a security report, please make this bug private as soon as
possible reproduced here since it affects cairo. After that, i will submit the
test cases to reproduce it.**

Hello,

We detected a large amount of uninitialized values in the parsing and
processing of svg files using librsvg and related libraries (e.g, libcairo)
causing undefined behaviors. Some of these issues are originated in librsvg,
some in libcairo and others (libpixman maybe). I haven't found a way to
privately report these issues to the cairo developers but anyway i think you
should be aware of this, since it affects almost every program using gdk-pixbuf
(yes, including Firefox and Chromium when you try to attach a svg in Linux).
These issues were tested in a fully updated Ubuntu 14.04 (with librsvg-2.40.2
and its dependencies). Other configurations/versions are likely affected.

Please find attached some small svg files to trigger the creation and use of
initialized values. Valgrind reports are also attached. You can reproduce these
issues using a gdk-pixbuf minimum example (available here:
https://github.com/CIFASIS/QuickFuzz/blob/master/bins/gdk-pixbuf.c). These svg
are taking forever to be rendered (possible infinite loop).

DoS is not the only possible attack: we also found that it is possible to use a
state-of-the-art fuzzer, american fuzzy lop, to discover interesting crashes.
In the instrumented mode, afl will look for new "transitions" in the control
flow graph of a program. If you collect many different test cases, you can find
some interesting ways of exploit uninitialized values (specially, in the
stack). We used rsvg-convert process the test cases with the undefined behavior
and after fuzzing for a few hours, afl detected this heap overflow:

Program received signal SIGSEGV, Segmentation fault.
rsvg_filter_primitive_erode_render (self=0x8115880, ctx=0x8162d10) at
rsvg-filter.c:2495
2495                        output_pixels[y * rowstride + x * 4 + ch] =
extreme;
(gdb) bt
#0  rsvg_filter_primitive_erode_render (self=0x8115880, ctx=0x8162d10) at
rsvg-filter.c:2495
#1  0x080c0575 in rsvg_filter_primitive_render (ctx=0x8162d10, self=<optimized
out>) at rsvg-filter.c:86
#2  rsvg_filter_render (self=0x81152e0, source=source at entry=0x8167608,
context=context at entry=0x80fb330, bounds=bounds at entry=0x8124d34,
    channelmap=channelmap at entry=0x80ea460 "2103") at rsvg-filter.c:530
#3  0x080d78c9 in rsvg_cairo_pop_render_stack (ctx=0x80fb330) at
rsvg-cairo-draw.c:806
#4  rsvg_cairo_pop_discrete_layer (ctx=0x80fb330) at rsvg-cairo-draw.c:853
#5  0x080ce488 in rsvg_node_use_draw (self=0x811fda0, ctx=0x80fb330,
dominate=0) at rsvg-structure.c:228
#6  0x080ccef0 in rsvg_node_draw (dominate=0, ctx=0x80fb330, self=0x811fda0) at
rsvg-structure.c:69
#7  _rsvg_node_draw_children (self=0x811f800, ctx=0x80fb330, dominate=0) at
rsvg-structure.c:87
#8  0x080ccef0 in rsvg_node_draw (dominate=0, ctx=0x80fb330, self=0x811f800) at
rsvg-structure.c:69
#9  _rsvg_node_draw_children (self=0x811b4b8, ctx=0x80fb330, dominate=0) at
rsvg-structure.c:87
#10 0x080ccef0 in rsvg_node_draw (dominate=0, ctx=0x80fb330, self=0x811b4b8) at
rsvg-structure.c:69
#11 _rsvg_node_draw_children (self=0x8113378, ctx=0x80fb330, dominate=0) at
rsvg-structure.c:87
#12 0x080ccef0 in rsvg_node_draw (dominate=0, ctx=0x80fb330, self=0x8113378) at
rsvg-structure.c:69
#13 _rsvg_node_draw_children (self=0x8111ea0, ctx=0x80fb330, dominate=0) at
rsvg-structure.c:87
#14 0x080cd5d0 in rsvg_node_draw (dominate=0, ctx=0x80fb330, self=0x8111ea0) at
rsvg-structure.c:69
#15 rsvg_node_svg_draw (self=0x81086e0, ctx=0x80fb330, dominate=0) at
rsvg-structure.c:323
#16 0x080ceb60 in rsvg_node_draw (self=0x81086e0, ctx=0x80fb330, dominate=0) at
rsvg-structure.c:69
#17 0x0808af0a in rsvg_handle_render_cairo_sub (id=0x0, cr=0x80fb900,
handle=0x80ff8f0) at rsvg-cairo-render.c:225
#18 rsvg_handle_render_cairo (handle=handle at entry=0x80ff8f0,
cr=cr at entry=0x80fb900) at rsvg-cairo-render.c:247
#19 0x0804ec8c in main (argc=1, argv=0xbffff6c4) at rsvg-convert.c:360

Unfortunately, such crash is difficult to reproduce in the original
rsvg-convert binary (remember that afl needs to recompile to instrumenting
binaries) but the uninitialized values are easy to spot using valgrind (such
report is also attached). Nevertheless, the possibility of finding
vulnerabilities is real and therefore these bugs should be fixed.

These test cases were found using QuickFuzz and afl.

Regards,
Gustavo.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo-bugs/attachments/20151111/8c22601d/attachment.html>


More information about the cairo-bugs mailing list