[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Feb 2014 20:00:37 +0000
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and
1.19.12 release
On 28/02/14 18:26, cve-assign@...re.org wrote:
> The first CVE would, roughly, have a root cause of "does not
> recognize that a trust relationship with a specific external site
> is reasonably required for use of a namespace."
Please note that (unless XML is being used very weirdly here) these
URLs are not going to be dereferenced: "XML elements in namespace
'http://ns.adobe.com/Flows/1.0/'" merely describes a set of elements,
in the same way that "XML elements whose name starts with 'abc'"
describes a set of elements. The trust relationship that seems to have
been applied here goes something like this:
I trust that none of my users' SVG viewers will ever execute
JavaScript (etc.) as a result of seeing arbitrary
XML elements in the namespace <http://ns.adobe.com/Flows/1.0/>,
excluding any that I have specifically filtered out
which doesn't seem like a great approach.
(Analogously, you could say "my HTML sanitizer is going to allow all
HTML elements that start with abc, because I'm pretty sure nobody will
implement an element containing JavaScript that starts with abc"; that
also seems an undesirable way to go about it, because as soon as some
browser vendor decides that an <abcScript> element is their next great
new feature, you have cross-site scripting.)
If element is defined in the current SVG standard not to cause code
execution, it's reasonable to think that all non-faulty SVG viewers
will not execute arbitrary code for them; but extensibility means that
it is not reasonable to believe that no SVG viewer will ever execute
arbitrary code as a result of encountering elements that are *not* in
the current SVG standard. Counter-example; imagine that SVG 2.0 is
published tomorrow and adds a <javascript> element and an
onGyroscopeMotion attribute to the SVG namespace, and browser vendors
implement them. A blacklist-based sanitizer will not protect you from
that instance of XSS.
As with any extensible format that can contain scripting and will be
interpreted by browsers, if untrusted SVG needs to be made safe, then
sanitizing via a whitelist of known-good elements and attributes is
the only safe way to deal with it. In the case of SVG, that whitelist
is likely to be inconveniently long.
S
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
