[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