SVG MIME Type (image/svg+xml) is misleading to developers

[paragonie-scott]

https://www.w3.org/TR/SVGTiny12/mimereg.html

I'd like to propose the deprecation of image/svg+xml as the MIME type to describe SVG files. My reasoning is as follows:

• SVG files can contain executable code (JavaScript).
• Developers expect an image/* MIME type to mean data, not code.
• A failure to separate data from code is a fundamental problem to software security. It turns up in:
  • Buffer overflows
  • SQL injection
  • Cross-site scripting
  • XML External Entities
  • Xpath injection
  • LDAP injection

The end result is that, due to the misleading MIME type for SVG files, most developers who don't know this nuance will accidentally handle them in such a way that makes Stored XSS vulnerabilities possible. It happened to us, and it's been a known problem for years.

The simplest solution is: move to application/svg+xml.

This signals to developers that "this can contain executable code" and also makes naive MIME whitelists (that force a download rather than display/execute directly when a MIME type is absent) based on the image/ prefix less vulnerable.

Alternatively, we could fork into two MIME types:

• image/svg+xml which is not allowed to contain JavaScript, and if it does, is never executed
• application/svg+xml which is allowed to contain JavaScript (maybe reserve the svgx file extension for these?)

[gsnedders]

What practical effect does deprecation of image/svg+xml have, and how does it address concerns about scriptability of the format?

Given the underlying XSS problems are caused by how browsers' implementation of SVG, and merely changing the spec to say image/svg+xml is deprecated does nothing to change their implementation. Realistically, image/svg+xml is unlikely to ever go away. Now, the question is any change can ever be made to the scriptability of that Content-Type, and similarly I suspect that it won't be plausible, which would make any deprecation or reduction in scope unlikely to ever be implemented.

[paragonie-scott]

I thought the intent would be more clear from the forking suggestion, but the goal is to make image/svg+xml NEVER allow code execution. If you need this "feature", make it available under a separate format (demarcated as "application/foo" rather than "image/foo", possibly as a svgx file rather than svg).

As the standard exists today, it's a security foot-cannon for developers.

[thomassmailus]

My concern, knowing that there is a valid security concern, is that the security zealots in corporations wanting to clamp everything down... will allow different treatments of different types of the 2-3 types of diagrams that are all SVG graphics, such that the ones with code are marginalized and strangled off by security paranoia.. which would kill the ability to use SVG in many diagram contexts.

[paragonie-scott]

security zealots
security paranoia

It's difficult to have a level discussion when participants are classified as zealots and ascribed with a mental health disorder right out of the gate.

will allow different treatments of different types of the 2-3 types of diagrams that are all SVG graphics, such that the ones with code are marginalized and strangled off by security paranoia.. which would kill the ability to use SVG in many diagram contexts.

Partitioning into two types still allows SVG (as most people use it) to endure such paranoia.

• SVG with JavaScript -> arbitrary code execution and a huge risk to the end user; block it!
• SVG without JavaScript -> no significant risk to the end user, let it through.

As it stands now, the best solution to prevent SVG-assisted stored XSS payloads is to:

1. Forbid SVG files entirely, or
2. Cripple their intended functionality (serve as text/plain with no-sniff, force a download, etc.), or
3. Attempt to write a fork of HTMLPurifier or Stauros that sanitizes SVG files to remove all JavaScript.

1 is the easiest for the backend, but the worst for the frontend. 3 is the easiest for the frontend (you can still use SVG, just not with embedded JS). 2 is what I'm currently doing in my projects, as a stop-gap measure. But eliminating the risk for myself doesn't help address the danger embedded in the standards. Hence, this Github issue.

Most security folks will prefer to just outright forbid all SVG files today when they hear of this risk. Changing the standard doesn't make SVG less acceptable to them. My proposal allows non-ECMAScript-burdened SVG files to still be tolerable by information security professionals.

[gsnedders]

I thought the intent would be more clear from the forking suggestion, but the goal is to make image/svg+xml NEVER allow code execution.

My intent was to get at how you intend on getting browser vendors to ship that (breaking) change? Browser vendors are unlikely to ship such a breaking change just because the spec has changed (over concern about how many SVGs will be broken as a result), and the security issue exists as long as browsers support script execution on image/svg+xml. Browser vendors are incredibly adverse to breaking content, and changing browsers is going to be far harder than changing the spec here.

[thomassmailus]

It's difficult to have a level discussion when participants are classified as zealots and ascribed with a mental health disorder right out of the gate.

Implying things not stated by pulling content out of context doesn't help either. Nor does it change the reality experienced on the ground in the corporate world, where we would be passing notes on paper for maximum intellectual property security if they had their way.

• SVG with JavaScript : this is SVG
• SVG without JavaScript: this is crippled SVG and makes it useless for smart technical diagrams and documentation.

If SVG is just to be a web graphic arts format and has no desire to become a full vector graphics file format, by all means, fragment away. We can always go WebCGM.

Seems like XSS is a problem with XSS and not SVG with JavaScript. Throwing out the baby with the bathwater is the wrong approach.

[paragonie-scott]

Seems like XSS is a problem with XSS and not SVG with JavaScript.

SVG with JavaScript is a subset of XSS vulnerabilities.

[paragonie-scott]

In the news: http://securityaffairs.co/wordpress/53650/malware/svg-images-locky.html

[BigBadaboom]

If anyone is interested in seeing one of these SVG files, someone posted
one to StackOverflow today

http://stackoverflow.com/questions/40710399/malicious-javascript-embeded-in-svg-what-it-does

On 22 November 2016 at 04:42, Scott notifications@github.com wrote:

In the news: http://securityaffairs.co/wordpress/53650/malware/svg-
images-locky.html

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#266 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAzSYAG2AdtCMBk_bEc_TzAnaQYCaPo8ks5rAbvugaJpZM4J7108
.

[nikosandronikos]

We chatted about this in our telcon on 27th October 2016.

The justification for the suggestion is totally valid. But we think that suggesting a mime type change is unlikely to be accepted. Content Security Policy is the preferred way to tackle these kind of issues.
This work is not in scope of the SVG working group for the next year. Therefore, we suggest raising a thread on the Web Incubator Community Group (WICG), in the SVG category. The WICG is intended as a place to develop ideas prior to standardisation, and it's frequented by most of the spec editors and browser developers. You're likely to get a better discussion on WICG since this topic crosses many technical areas.

@paragonie-scott Are you happy to create a thread on WICG? I would suggest stating the problem (with no implied solution), then if you want to suggest a change to mime types, do that in a follow up post on the thread.