1745643 - SVG images are potential webshell and a threat to both server and client.

Status: RESOLVED DUPLICATE of bug 1018790

(Core :: SVG, defect)

Description

[Dhiraj Kumar]

Attachment: samsdog.svg

Steps to reproduce:

Issue is with how browsers render SVG files and how already placed mitigations could be bypassed easily.

This issue is not browser or app specific as any service that handles these files carelessly are prone to exploitation.

SVGs as a threat to both server and client.

Ability of SVG files to launch an attacks likes XSS is well know because these file allows HTML/JS/XML to be embedded inside the file and mitigations are already in place to counter this threat for example if an attacker is able to upload a SVG payload in a profile picture than in most probable scenario that payload won't run because of it being present inside a <img> tag.

   <img class="samsdog" src="samsdog.svg" />

but a simple bypass exist as you can copy the url of the uploaded image than open it in the next tab and thereby executing the file with its embedded payload.
Due to SVG files allowing HTML/JS/XML inside its structure , these files are not just a threat to client side but also to the server as they posses the potential to compromise the server as it is all subject of attacker's creativity and availability of required server environment as these files gives a lot of attack surface against both server and client. (https://github.com/allanlw/svg-cheatsheet)

POC

1. visit https://beeceptor.com/console/burpsuit and refresh the page.

2. Put a pass.txt file in same directory as samsdog.svg and run the samsdog.svg in your browser and you can see a HTTP GET hit on beeceptor and also can see browser loading pass.txt.

3. As you can see a svg file opened in new tab act as some HTML file present on server with ability to execute JS and XML, basically it can act like a shell and can compromise a server if the server environment is favorable in addition of launching various attack against client itself like XSS and malware delivery.

mitigation:

• don't allow http://xxx/file.svg to be executed as it is threat to both server and client, only treat it as image file like it is treated in <img> tag.
• only allow its full functionality within iframe,object,embed and nothing else as developers generally don't put these files inside these tags from direct user upload and sandbox is also there.

Comment 1

[:Gijs (he/him)]

SVGs have, to my knowledge, always worked like this, and if websites are allowing people to upload arbitrary SVGs and serve it without their own safeguards, there's not much browsers can do without breaking compatibility.

I don't think there's any point this staying security-sensitive, and I'm not even sure there's a point to keeping the bug open - Dan?

Comment 2

[Sergey Galich [:serg]]

I think if site owner decided to put pass.txt that can be served to browser, it doesn't matter if SVG or other methods were used. Browser asked for pass.txt and server happily gave it.

Comment 3

[Robert Longson [:longsonr]]

Basically the same as bug 1018790 (and that's public).

Comment 4

[Daniel Holbert [:dholbert]]

Agreed, yeah. This is a known issue with SVG, which can't really be addressed without breaking compatibility. Google searches for "best practices upload svg xss" turn up all sorts of discussion of this. I don't think there's anything on this report that's distinct from those known/public issues.

Spitballing: perhaps there could be some way for sites to "opt-in" to forcing all SVGs on their origin to an image-only mode, via a CSP in the HTTP headers, or something to that effect.

But in the meantime, this is indeed a dupe of bug 1018790.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

Spitballing: perhaps there could be some way for sites to "opt-in" to forcing all SVGs on their origin to an image-only mode, via a CSP in the HTTP headers, or something to that effect.

Note that sites can already at least disable scripts in user-provided SVGs, by sending an appropriate CSP as an HTTP header from whatever origin they host this content on; e.g. content-security-policy: default-src 'none'

Comment 6

[Daniel Veditz [:dveditz]]

As you say "this is well known" and doesn't need to be hidden. For example, it's mentioned somewhat casually in https://www.sitepoint.com/why-hosting-your-svgs-is-hard-and-how-to-beat-it/

It's relatively easy to neuter these files by using a Content-security-policy that disables scripts or uses the sandbox directive. At least, it is if you can rely on all visiting browsers supporting content-security-policy. If browsers today made some change to make SVG safe-by=default by requiring some kind of opt-in to the powerful feature, sites still would be afraid to host user uploads because all the old versions of browsers (a lot of people) would still be vulnerable. And meanwhile some number of sites would now be broken in new browsers because they host SVG images that rely on scripts to work properly.

Maybe we can use this bug as one to add some telemetry probes so we have some idea of how much SVG is actually used, and how often it's loaded as a document vs. as an <IMG>. And of the ones loaded as a document, how many require script execution?

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Veditz [:dveditz] from comment #6)

Maybe we can use this bug as one to add some telemetry probes so we have some idea of how much SVG is actually used, and how often it's loaded as a document vs. as an <IMG>. And of the ones loaded as a document, how many require script execution?

I spun off bug 1745835 for this hypothetical telemetry.