W3C home > Mailing lists > Public > www-svg@w3.org > July 2010

Re: SVG Security ISSUE-2071 (was: Announcement: Last Call WD of SVG 1.1 Second Edition)

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 7 Jul 2010 21:27:40 +0200
Cc: Thomas Roessler <tlr@w3.org>, robert@ocallahan.org, "www-svg@w3.org" <www-svg@w3.org>
Message-Id: <297F3F8E-B6DB-4817-BC13-63E1729C6C57@w3.org>
To: Doug Schepers <schepers@w3.org>
Doug,

reviewing the discussion, it sounds like you're dealing with a violation of a relatively important instance of the same origin policy.  So this is indeed an issue that's worth addressing quickly, given increasing deployment of SVG.

I don't know enough about SVG's details to give you a full assessment of the proposed solution; however, it seems to me that the basic approach -- i.e., any mechanism that knows how to read pixel values will fail (or return a fixed value) for any pixel that's under a different origin's control -- is the right direction to go into.
--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)







On 24 Jun 2010, at 01:49, Doug Schepers wrote:

> Hi, Thomas-
> 
> We have an issue with some SVG functionality that we are trying to close in on an erratum for, possibly in SVG 1.1 SE.
> 
> The issue is here:
> http://www.w3.org/Graphics/SVG/WG/track/issues/2071
> 
> ROC proposes a solution below, and I wondered if we could get your assessment of the threat and of the solution.  If you need more details, I will be happy to schedule a call with you.
> 
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
> 
> 
> Robert O'Callahan wrote (on 6/23/10 10:54 PM):
>> On Wed, Jun 23, 2010 at 9:49 PM, Doug Schepers <schepers@w3.org
>> <mailto:schepers@w3.org>> wrote:
>> 
>>    SVG2 seemed like a good place to solve that, because we could look
>>    at that class of security risk more comprehensively, and come up
>>    with a robust and broad solution.  I also don't want to hold up the
>>    SVG 1.1 SE publication, because it needs to be finished so we can
>>    move on to more pressing matters; we know there are still
>>    outstanding issues in SVG 1.1 which the 2nd edition doesn't deal
>>    with, but SVG 1.1 SE is not meant to be definitive... it's a
>>    snapshot that incrementally improves SVG 1.1, and we will have to
>>    keep maintaining SVG 1.1 for a long while, even as we move forward
>>    on SVG2; this is only the first of a series of updated editions of
>>    SVG 1.1.
>> 
>> 
>> Yeah, but this is not just any old issue. This is a security issue and
>> it involves features that Web browsers are implementing.
>> 
>>    I do recognize the importance and urgency of this issue, though.
>>      So, here's my proposal for resolving it:
>>    * we publish SVG 1.1 Second Edition as is
>>    * we immediately begin work with browser vendors and security
>>    experts to find a reasonable solution for ISSUE-2071 that doesn't
>>    cripple content authors while plugging the security hole
>>    ** we publish a new errata for SVG 1.1 SE, putting forth a proposed
>>    solution, which will ultimately be published as SVG 1.1 3rd Edition
>>    ** we include the solution in early drafts of SVG2
>> 
>>    We could do this over the next couple months, I think.  I will put a
>>    priority on it, personally.  How does that strike you?
>> 
>>    [1]
>>    http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes
>> 
>> 
>> That would be adequate. However I think if we just had a discussion
>> right now, we could get a solution right now and put it in SVG 1.1 2nd
>> Edition. I don't think minimizing "class 3" issues should be a goal in
>> itself; minimizing incompatible changes certainly should be a goal, but
>> here we have a situation where we clearly do need to make an
>> incompatible change. Right now we can probably still make a change that
>> would be incompatible with the previous spec but compatible with all
>> shipping implementations, but that window of opportunity could close
>> anytime.
>> 
>> Here's a proposal:
>> 1) 'pointer-events:painted' should treat images with a different origin
>> to the containing document as completely opaque.
>> 2) 'pointer-events:painted' should treat "mixed-origin" images as
>> completely opaque. A "mixed-origin resource" is a resource containing a
>> subresource with a different origin to the resource itself, or a
>> subresource that is itself mixed-origin.
>> 
>> Rule 1 prevents leaking information about the contents of images from
>> other origins. This is actually a different problem to the one I raised,
>> but it's serious (e.g. for <canvas> we have a taint flag that blocks
>> recovery of other-origin image data).
>> 
>> Rule 2 prevents leaking information about the contents of resources from
>> other origins.
>> 
>> The only spec difficulty I see here is defining exactly what the
>> subresources of a resource are. However, it would be far better for a
>> proposal like this to get into the spec ASAP even if it's not perfectly
>> defined than to leave this issue completely unaddressed; the latter
>> would be a classic case of making the best the enemy of the good.
>> 
>> We'll actually need to extend canvas with an analogue of rule 2 when we
>> add the ability to paint SVG images into the canvas; that's not your
>> problem, but it means that even if this proposal isn't adopted for SVG,
>> we'll need to define something like "mixed-origin images" anyway.
>> 
>> Rob
>> --
>> "He was pierced for our transgressions, he was crushed for our
>> iniquities; the punishment that brought us peace was upon him, and by
>> his wounds we are healed. We all, like sheep, have gone astray, each of
>> us has turned to his own way; and the LORD has laid on him the iniquity
>> of us all." [Isaiah 53:5-6]
> 
> -- 
> 
Received on Wednesday, 7 July 2010 19:27:43 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:45 GMT