XML entity vulnerabilities in 0.48.2 (r9819)

Bug #1002439 reported by Jon on 2012-05-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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.


Jon Hinks

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,


----- 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://cwe.mitre.org/data/definitions/776.html). Again, disallowing entities by default would stop this.



----- 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,

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.

--- start of demo ---

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

                <!ENTITY hacka SYSTEM "file:///etc/passwd">
                <!ENTITY hackb SYSTEM "file:///etc/hosts">
                <!ENTITY hackc SYSTEM "http://aimee.jondh.me.uk/tmp/test.txt">
(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


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 (jonpad) wrote :

cc Ted, who was involved in the original conversion.

Jon (jonpad) wrote :

This vulnerability has been sent to Secunia (<email address hidden>). More information about their liaison/disclosure process here:


Jon (jonpad) wrote :

Ooh, some progress all of a sudden:

* Secunia replied, and said they will only assist in vulnerability investigation once it has been publicly disclosed , so they've dropped out of the process. Maybe they should be pinged once the vuln is public?
* I'd reported this to Ubuntu by email (ahem, on 1 May 2012) and today they replied to say they will look at this ticket.

Jon (jonpad) wrote :

Added Ubuntu Security as a subscriber to this ticket.

Jon (jonpad) wrote :

Ubuntu Sec Team - could I possibly trouble you for an update? I'm the only one to have commented on this ticket, and I think it deserves a response. If it is regarded as a low priority vuln, then fine; please let me know.

Marc Deslauriers (mdeslaur) wrote :

Ted, have you looked at this issue? Do you have a fix in mind?

On Sat, 2012-06-23 at 17:17 +0000, Marc Deslauriers wrote:
> Ted, have you looked at this issue? Do you have a fix in mind?

Yes, Jon talked to me about it. I think his proposed fix is reasonable,
unfortunately it disables a feature that some people might use, though I
haven't found anyone using it for good.

I think probably the "right" fix is to prompt the user with a dialog
that says: "Hey, this document wants to download random content from the
web, are you sure about that?" I was looking at that, but didn't find
an easy way to do it.

So, in a nutshell, I'm all for just disabling it and seeing who
complains. I'm betting I was just over thinking it.

Jon (jonpad) wrote :

Thanks both. This would need command line treatment as well; dialogue boxes won't work with --without-gui, of course. As per earlier comments, the system could ignore entities by default, and permit them with something like --allow-entities.

Jon (jonpad) wrote :

Hi Ted and Marc.

I will be blogging about this vuln in the next couple of days. I wonder, if a fix is proving difficult, whether a security advisory would be a good idea? At least people can then be wary when opening SVG files they don't explicitly trust (yes, they should anyway, but...!).

Best regards,


Jon (jonpad) wrote :

A security engineer for the Wikimedia Foundation got back to me today, and I hope he won't mind me adding part of his reply:

> I was able to reproduce your work with Inkscape, and I agree, this is
>something that Inkscape should fix. I tested a number of other viewers,
> and none showed similar behavior.

He says he'll look into filtering out entities on the server side, since Wikipedia publishes a lot of SVG images, and Inkscape is likely to be popular amongst contributors.

jazzynico (jazzynico) on 2013-02-21
information type: Private Security → Public Security
Jon (jonpad) wrote :

Thanks @JazzyNico - great news that a fix has now gone in.

A minor point: this "duplicate" ticket predates the other by a couple of months. Anything I could have done to have gotten it expedited, for my future reference? I wonder if I should have added a slew of random watchers to the ticket! ;-)

jazzynico (jazzynico) wrote :

> Anything I could have done

Jon, I think you've done well. The problem with security private bugs the Inkscape bug team doesn't receive notices, and thus the reports can stay unknown of the developers for very long...
That's something that must be fix with the Inkscape teams so that we are more efficient in the future.

Jon (jonpad) wrote :

Alright, many thanks.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers