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

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, 23 June 2010 23:49:23 UTC