XML entity vulnerabilities in 0.48.2 (r9819)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
New
|
Undecided
|
Unassigned |
Bug Description
Hi Inkscape team,
I reported this security issue back on 18th March, and the process to fix has clearly stalled somewhere. I'd not seen there was a sec issue reporting mechanism on LaunchPad, so here is a fresh attempt to notify. I'll send it to Secunia next Monday (28th May), which may result in public disclosure.
See below an email conversation with Ted from your team - scroll to the bottom for the vuln details.
Regards
Jon Hinks
blog.jondh.me.uk
Date: Tue, 17 Apr 2012 10:42:59 +0100 [17 Apr 2012 10:42AM BST]
From: Jon Hinks
To: Ted Gould <email address hidden>
Subject: Fwd: Re: Security issue in Inkscape XML parsing
Hi Ted
How're you getting on with this? Have you got a planned release date?
Best wishes,
Jon
----- Forwarded message from <email address hidden> -----
Date: Fri, 06 Apr 2012 22:53:59 +0100
From: Jon Hinks
Subject: Re: Security issue in Inkscape XML parsing
To: Ted Gould <email address hidden>
Hi Ted
Thanks for the reply. I was considering making the vulnerability public as per usual responsible disclosure process - happy to hold off, now I know you're looking at it!
I'm not a sec expert, but I'd say it might be worth getting advice on whether a notice should be posted prior to a fix. In my view, software sec advisories are always accompanied by an actual fix.
In this case, if it is possible to strip entities by default, then a lot of issues are fixed in one go (maybe a CLI option --allow-entities could be added, in case someone uses these?). I should think it is a trivial fix, but then I'm not a C++ programmer :)
Aside from the remote notification and arbitrary file stealing vulns, I should think XML bombs would be possible too (http://
Best,
Jon
----- Message from <email address hidden> ---------
Date: Thu, 05 Apr 2012 20:00:16 -0500
From: Ted Gould <email address hidden>
Subject: Re: Security issue in Inkscape XML parsing
To: Jon Hinks
Hey Jon,
Thanks for the info, trying to figure out if we need to do a security
notice for this or anything like that before fixing it. I've not done a
security update before.
Thanks again,
Ted
On Sun, 2012-03-18 at 13:22 +0000, Jon Hinks wrote:
Hi Ted
I found your contact details via the Inkscape launchpad.net, and would
like to report a security issue that I think deserves some attention.
Would you forward this to the developers outside your mailing lists?
An SVG file can be constructed that will notify the sender when it is
opened by reading and including the contents of a remote url. Also,
the contents of any arbitrary local file can be included as well,
which is an issue if a user were to save and redistribute an SVG file
that, unknown to them, contains this attack.
Here is a demo - just insert the <!DOCTYPE> directive into an SVG
file, and then create a textfield containing an entity reference (e.g.
&hackb;).
--- start of demo ---
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://
<!DOCTYPE svg
[
]
<svg
xmlns:dc="http://
xmlns:cc="http://
(rest of doc snipped)
--- end of demo ---
When a file of this kind is saved in Inkscape, the references are
replaced but the entities are removed. Thus, a hidden text field could
be used to take a copy of any local file that is safe to quote in XML.
I wonder if with a little extra research, even binary files could be
grabbed in this way? I briefly tried the php:// filter hack, but
couldn't get it to work.
As per the following site, the solution if entity loading is not
required (would it ever be?) is to turn off
'libxml_
www.idontplayda
I'm on Inkscape 0.48.2 r9819 on OS X 10.6.8. Do let me know if you
need any further info.
Best regards,
Jon
information type: | Private Security → Public Security |
cc Ted, who was involved in the original conversion.