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 658014 - crash on NULL dereference
crash on NULL dereference
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
git master
Other Linux
: Urgent critical
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-01 21:18 UTC by Christian Persch
Modified: 2011-09-08 23:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase.svgz (2.22 KB, image/svg+xml-compressed)
2011-09-01 21:24 UTC, Christian Persch
  Details
Store node type separately in RsvgNode (43.89 KB, patch)
2011-09-01 21:31 UTC, Christian Persch
none Details | Review

Description Christian Persch 2011-09-01 21:18:56 UTC
See comment 1.
Comment 1 Christian Persch 2011-09-01 21:23:40 UTC
From: Kees Cook <kees@outflux.net>
To: Christian Persch <chpe@gnome.org>
Cc: linux-distros@vs.openwall.org, security@ubuntu.com
Subject: Embargoed security issue in librsvg
Date: Fri, 26 Aug 2011 20:12:52 -0700

A private security bug was reported by Sauli Pahlman against librsvg
in Ubuntu. You are being emailed as the upstream contact. Please keep
linux-distros@vs.openwall.org[1] CC'd for any updates on this issue.

This issue is embargoed and has not been disclosed publicly. Ubuntu
is not interested in a specific coordinated release date (CRD), but
would like to give distros time to propose one. If you or members
of linux-distros@vs.openwall.org do not request a CRD by 2011-09-06,
the issue should be considered public. We ask that you keep this issue
embargoed until then[2].

It has been assigned CVE-2011-3146; please mention this in any changelogs.

Details from the currently private bug follow:
https://launchpad.net/bugs/825497

----
eog/librsvg crashes when attempting to call NULL while opening the attached
reproducer. Marking initially as vuln since i did not check whether the
call address can be changed to something else than just NULL. Backtrace:

Program received signal SIGSEGV, Segmentation fault.

Thread 3084393328 (LWP 17083)

  • #0 ??
  • #1 rsvg_filter_primitive_render
    at rsvg-filter.c line 85
  • #2 rsvg_filter_render
    at rsvg-filter.c line 499
  • #3 rsvg_cairo_pop_render_stack
    at rsvg-cairo-draw.c line 970

I've attached the reproducer to this email.

I took a further look at it, and it does look exploitable, but rather
unstable or at least application-sensitive:

When building nodes, librsvg will take all nodes, regardless of name. If a
name is unknown, it makes it a group (RsvgNodeGroup) -- see
rsvg_standard_element_start(). However, the filter renderer checks for
names, not object types, so if a name starts with "fe", it treats it as a
filter (RsvgFilterPrimitive), and rsvg_filter_primitive_render() will end
up trying to call ->render() off the edge of the allocated RsvgNodeGroup.

There needs to be some way to identify the child node type without relying
on ->super.type->str, since it could be anything.

It seems that ->render can line up with the contents of RsvgState, but it
depends on the g_malloc behavior of the other program threads, so
exploitation would likely be unstable, but possible:

(gdb) p ((RsvgNodeGroup*)0x7c1ea0)->super->state->personal_affine
$37 = {1, 0, 0, 1, 0, 0}
(gdb) set var ((RsvgFilterPrimitive*)0x7c1ea0)->render = 0xffffffffffffffff
(gdb) p ((RsvgNodeGroup*)0x7c1ea0)->super->state->personal_affine
$38 = {1, 0, -nan(0xfffffffffffff), 1, 0, 0}
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xffffffffffffffff in ?? ()

When reproducing from "convert", I was able to aim the dereference at font
text:
(gdb) x/s $rax + 0x88
0x61c6d8:    "w Roman"


Thanks in advance for your cooperation in coordinating a fix for this
issue,

-Kees


[1] linux-distros@vs.openwall.org is a private mailing list for
    distributors of operating systems to collaborate on security
    vulnerabilities and coordinate security updates.  Discussions 
    on linux-distros@vs.openwall.org are considered private and should
    not be made public, though the result of the discussions may be
    made public after the coordinated release date.
[2] Please do not release a fix, make public revision control commits,
    comment in public bug reports or otherwise disclose information
    about this issue until the coordinated release date. This gives all
    affected parties a chance to release a fix at the same time.
Comment 2 Christian Persch 2011-09-01 21:24:37 UTC
Created attachment 195442 [details]
testcase.svgz
Comment 3 Christian Persch 2011-09-01 21:31:20 UTC
Created attachment 195443 [details] [review]
Store node type separately in RsvgNode

The node name (formerly RsvgNode:type) cannot be used to infer
the sub-type of RsvgNode that we're dealing with, since for unknown
elements we put type = node-name. This lead to a (potentially exploitable)
crash e.g. when the element name started with "fe" which tricked
the old code into considering it as a RsvgFilterPrimitive.

CVE-2011-3146
Comment 4 Christian Persch 2011-09-02 21:41:12 UTC
I have received a request to post the patch to the "vendor-sec" mailing list. What list does this refer to? And would that be appropriate to do?
Comment 5 Kees Cook 2011-09-02 21:49:55 UTC
No worries, I've already sent a copy there (see the original email/report for the email address for vendor-sec).
Comment 6 Christian Persch 2011-09-06 06:55:51 UTC
Any feedback on the patch?
Comment 7 Christian Persch 2011-09-06 22:01:30 UTC
As I have received no request to keep this issue private after 06.09.2011, I have pushed the fix to the git repo and released librsvg 2.34.1.

Are there any objections against making this bug public now?
Comment 8 Vincent Danen 2011-09-07 05:08:05 UTC
No objections to making the bug public, but you might want to make the reproducer private.  Otherwise I would say if the fix is public, make the bug public as well.
Comment 9 Vincent Danen 2011-09-07 05:08:06 UTC
No objections to making the bug public, but you might want to make the reproducer private.  Otherwise I would say if the fix is public, make the bug public as well.
Comment 10 André Klapper 2011-09-07 08:40:01 UTC
Bugzilla maintainers can set specific comments or attachments to "private" which makes them only accessible to those 7 people that are listed as admins of this Bugzilla instance. If you want that, just tell us which one(s) so access can be restricted before removing the "Restrict Group Visibility" flag for the complete report.
Comment 11 Christian Persch 2011-09-07 09:28:57 UTC
That would be attachment 195442 [details]. 

However I'm not sure how useful hiding it would be, since comment 1 describes the problem well enough that writing a short reproducer is trivial, and looking at the patch will give you lots and lots more ideas for svg files that will hit this kind of bug.
Comment 12 Vincent Danen 2011-09-07 14:52:29 UTC
Ah, right.  The comments in the description are quite detailed.  I have no objection then to opening this up as-is.  Thanks.