1018310 - CSP style-src and img-src violations in SVG

Status: RESOLVED DUPLICATE of bug 886164

(Core :: Security, defect)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Date: Thu, 29 May 2014 17:02:00 -0700
From: Rennie deGraaf <[e-mail]>
To: <[e-mail]>
Subject: CSP style-src and img-src violations in SVG
-----//-----
CSP does not appear to be applied properly to SVG documents loaded in
iframes with the "sandbox" attribute.  When I loaded an SVG document in
a sandboxed iframe, I encountered the following CSP violations:
1.  In-line CSS was applied in violation of style-src: self
2.  External CSS from a different origin was applied in violation of
   style-src: self
3.  A child SVG document included by the first through an svg:image tag
   was loaded in violation of img-src: none
4.  A child SVG document included by the first through an html:object
   tag was loaded in violation of object-src: none.

These issues appear to have been fixed in Firefox 28.0.  However, they
still appear in the latest ESR release, 24.5.0.

I also found one further potential issue in all current Firefox
releases: if CSP img-src is 'none', Firefox still displays SVGs
embedded in the HTML.  Since SVGs encoded in data: URIs are blocked
(due to the lack of 'data:' in img-src), I feel that this is a bug.
I'm not sure if the proper behaviour would be for embedded SVGs to be
handled like data URIs or if there is a better way to apply CSP to
them.  Chrome does the same thing as Firefox with respect to embedded
SVGs.

Firefox does seem to correctly block both in-line and external
stylesheets according to CSP in all other cases that I tested,
including when loaded through img tags (external images and data URIs),
CSS background-image properties, object tags, embed tags, and
un-sandboxed iframes.  It only seems to err in the case of sandboxed
iframes.  It also seems to correctly block JavaScript from being loaded
by SVGs in all cases where I expected it to.

Chrome does not have the flaws relating to sandboxed iframes (although
it has its own flaws in other areas).  Internet Explorer doesn't
support CSP, so it doesn't have any flaws of this type.

I did not test if CSP is applied properly to other types of content
loaded in sandboxed iframes.

Note: I plan to describe these issues in my BlackHat talk this August,
so your prompt attention to them will be appreciated.


I tested the following browser versions:
Firefox 26.0 on Ubuntu 13.04
Firefox 26.0 on Windows 7 SP1
Firefox 27.0 on Windows 7 SP1
Firefox 28.0 on Windows 7 SP1
Firefox 29.0.1 on Windows 7 SP1
Firefox 24.5.0esr on Windows 7 SP1


REPRODUCTION CASE
Reproduction steps:
1.  To demonstrate this, set up an Apache web server using the
   configuration in the attached file "ffbug.test" (or equivalent
   configuration using another web server).
2.  Define the domains "dom1.ffbug.test" and "dom2.ffbug.test" in
   your hosts file.
3.  Serve the following files from dom1.ffbug.test:
       circle.svg
       circle-css.svg
       circle-css-cross-domain.svg
       circle-emb-circle.svg
       circle-emb-html-xd-circle-css.svg
       circle-emb-html-xd-circle-css-external.svg
       circle-emb-xd-circle.svg
       index.css
       index.html
4.  Serve the following file from dom2.ffbug.test:
       circle.css
       circle.svg
       circle-css.svg
       circle-css-external.svg
5.  Load http://dom1.ffbug.test using Firefox 24.5.0esr.  The first
   column of circles are SVG documents in normal iframes; all are gray
   as expected.  The second column are sandboxed iframes; in the first
   two, the circles are orange due to CSS being applied in violation
   of style-src, and the remaining four have quarter-circles in their
   lower-right corners due images or objects being included in
   violation of img-src or object-src.  The last column are SVG
   documents embedded in-line in the HTML, which are displayed in
   violation of img-src.  In Firefox 28 and newer, the issues in the
   second column have been fixed, but the issue with SVG embedded in
   HTML remains.

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: firefox-disclosure.tgz

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Firefox still displays SVGs embedded in the HTML

Sure.  We display tables embedded in the HTML too.

image-src applies to <img> resources, not to markup in the document itself.

Is the version here really 31, given that the report says this is fixed in 28, just a problem on ESR 24?

Comment 3

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Boris Zbarsky [:bz] from comment #2)
>
> Is the version here really 31, given that the report says this is fixed in
> 28, just a problem on ESR 24?
>
I'll try to get more info from the reporter or get them involved in the bug directly.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

I'm with bz here about the inline SVGs.  See also 763879 comment 62.  Seems only to be an ESR problem.  

It's likely the fix for the sandbox issue was in bug 886164 (landed for Fx 28).

Comment 5

[rennie.degraaf]

Boris/Sid: There isn't a CSP rule to restrict showing tables.  There is one to restrict showing images, and it already has a way to restrict showing one form of images that are included in-line in HTML: data URIs.   Does it make sense for "img-src: none" to deny data URIs but not this?  I don't think so, but that may be a problem with the CSP spec.

Comment 6

[rennie.degraaf]

With regard to version: I did not test any beta releases, nightly builds, or anything like that.  I originally found the issue using Firefox 26, then got busy with work and didn't report what I had found.  By the time that I got back to it, you had released new versions that seem to have fixed the problem (good job, by the way).  Since the main issues are still present in the latest ESR release, I reported it anyway.

Comment 7

[Sid Stamm [:geekboy or :sstamm]]

While the effect of data: URIs and content may be similar for the purpose of images, the fact that images loaded from data: URIs is a side-effect of URI-based content filtering.  I don't think it's a core feature of CSP to be able to block data: images, since it's not external loading and it's not scripted.

What type of security benefit would we realize or what attack would be blocked by blocking inline SVGs?

Regardless, the spec is silent on this, and just like we don't block ASCII-art-based images on a site, I don't immediately see a reason we should interpret 'img-src none' to extend beyond URI-based image loads.  Perhaps it would be helpful to clarify this in the spec via W3C.

Rennie: since the core of this bug is the failure of CSP inside sandboxed iframes, I'd like to dupe this to bug 886164.  If we want to add inline-SVG filtering to CSP, this should be a new (non-security-sensitive) enhancement bug.  Can you check that the SVG-in-sandboxed-iframe bits of this report are fixed in Fx 28 but not in 27 (likely by bug 886164)?  You can get a copy of 27 here: ftp://ftp.mozilla.org/pub/firefox/releases/27.0.1/

Comment 8

[Daniel Veditz [:dveditz]]

The CSP spec is pretty clear that inline SVG is part of the document and should be treated as such, not as an external image load.

The CSP-in-sandbox issues are a duplicate of bug 886164. The severity of this bug does not really rate back-porting to the ESR branch. It's not an added security risk to users, it's just that CSP does not provide a site quite as much protection against their own bugs as it should (but still a lot more than browsers that have no CSP at all like IE).

Note that there has been recent discussion in the W3 WebAppSec working group about how to reconcile differences between a document's CSP and an SVG-as-<img> CSP (if any). There are implementation differences between Firefox and Chrome on this point and the intersection of the two specs is somewhat ambiguous:
 * you could argue that the document CSP should apply just as it would to an inline SVG
 * you could argue that the SVG is a separate document context like an iframe and that
   its own CSP should apply (but that assumes the SVG content can't "leak out" into the
   containing document).

http://lists.w3.org/Archives/Public/public-webappsec/2014Apr/0019.html

That's not this bug though and we should just wait for the spec issue to be settled.

Comment 9

[rennie.degraaf]

Daniel: Can you point me to where the CSP spec says that inline SVG should be treated as part of the document?  I must have missed that.

Comment 10

[rennie.degraaf]

Sid: I already checked; the sandboxed iframe issues appear in Firefox 27 and 24.5esr but not in Firefox 28.  Sorry if I wasn't sufficiently clear in the original report.

Comment 11

[Daniel Veditz [:dveditz]]

We don't need to use the more restrictive component-specific security groups unless a bug is sec-high or sec-critical