GNOME Bugzilla – Bug 658014
crash on NULL dereference
Last modified: 2011-09-08 23:47:58 UTC
See comment 1.
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.
+ Trace 228314
Thread 3084393328 (LWP 17083)
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.
Created attachment 195442 [details] testcase.svgz
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
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?
No worries, I've already sent a copy there (see the original email/report for the email address for vendor-sec).
Any feedback on the patch?
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?
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.
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.
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.
Ah, right. The comments in the description are quite detailed. I have no objection then to opening this up as-is. Thanks.