[wp-trac] [WordPress Trac] #24251: Reconsider SVG inclusion to get_allowed_mime_types
WordPress Trac
noreply at wordpress.org
Sun Feb 28 17:45:27 UTC 2016
#24251: Reconsider SVG inclusion to get_allowed_mime_types
---------------------------+------------------------------
Reporter: JustinSainton | Owner:
Type: enhancement | Status: reopened
Priority: normal | Milestone: Awaiting Review
Component: Upload | Version:
Severity: normal | Resolution:
Keywords: early | Focuses:
---------------------------+------------------------------
Comment (by LewisCowles):
Replying to [comment:57 chriscct7]:
> Replying to [comment:54 LewisCowles]:
> > I tested this morning; WP does not protect against me uploading a
text-file renamed to .png, so there is probably very little to stop me
uploading a malicious payload in any format.
>
> That's not comparable to sanitized SVG upload. A PNG file, on render or
access, does not run scripts. An unsanitized SVG can contain JavaScript or
trigger remotely run code.
Actually as PNG's are binary, there have been numerous exploits including
code at the end of the file, using a remote server to serve alternative
binary content, they are every bit as vulnerable as an SVG file, albeit
through alternative methodologies.
> There's quite a few different ways SVG files can cause malicious output.
A good overview of some these issues is:
https://www.blackhat.com/docs/us-14/materials/us-14-DeGraaf-SVG-
Exploiting-Browsers-Without-Image-Parsing-Bugs.pdf
Most of the examples in that PDF are now patched and were browser
problems, not CMS problems, or SVG problems; Even the slides you show
mentions that many of the problems are not specific to SVG, and affect the
XML file format and HTML (See page 18/55 in your PDF).
> However, as those slides were presented 2 years ago, several new attack
vectors found over the last 2 years are omitted, as well as possibilities
arising from the new SVG 2.0 spec.
>
> > so there is probably very little to stop me uploading a malicious
payload in any format
>
> This would be a security bug. If you find or know a way to do this,
please email security@ wordpress.org so it can be fixed.
Every single "exploit" mentioned was either not a security bug, or has
been remitted... Again, leading me to conclude that any facts heard are
out-dated and nothing to do with any application system...
> > IT took virtually no time at all to build the PoC WP plugin to allow
uploads of SVG. Then WP released an update and the plugin had to be
modified.
>
> The plugin didn't fully sanitize SVGs at the time it was uploaded.
Moreover, the new SVG 2.0 also adds more places for JS to be placed in an
SVG file that the plugin doesn't account for.
I do not agree that it is the place of a plugin to sanitize SVG; it adds
needless complexity, which as said could be dealt with through education
of users. Using this same logic that an upload could contain malicious
code, we should ban plugins, themes, and user-input... It's
disproportionate to the problem space and puts unfair strain on WP to
expect it to roll it's own sanitization in-house when most will be
irrelevant in 3-6 months when browser vendors patch.
Using a different domain to serve assets
Only uploading in-house, or purchased SVG files
Using CSP
All mitigate existing known SVG attacks; it really is that simple.
On other comments, the PHP comment is in response to the notion that it is
reasonable that WordPress supports PHP 5.2 (it's not), I accept it is a
side-note, but as it came up, I felt I had to address it.
Wikimedia absolutely does not block uploading, or access to SVG files; and
WikiPedia serves a link to the original SVG file as a core function of the
system to allow the upload of SVG files, and provide visitor access to
said files. Don't try to twist this because they have a backwards-
compatibility fix to show SVG's in browsers that do not support them (IE
pre 2011 as per linked .pdf)
Whilst XSS in SVG could be annoying; a greedy regex could easily remove
the risk (Again I think if someone uploads a file, your job is to upload
it, not provide a virus / exploit remover in the CMS); it's like insisting
a car comes with life-jacket in-case someone drives into a river.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/24251#comment:62>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list