W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: Summary of CSS shader security issues and proposals

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 6 Jan 2012 12:44:51 +1300
Message-ID: <CAOp6jLZQBUHM5ptO8pxpDxkvU2h+nbSjz8mP6iH0NCWRa5_x6Q@mail.gmail.com>
To: Vincent Hardy <vhardy@adobe.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>, Adam Barth <w3c@adambarth.com>
On Thu, Jan 5, 2012 at 11:55 AM, Vincent Hardy <vhardy@adobe.com> wrote:

> Method B seems difficult to implement fully. There are so many ways that
> cross-origin resources can affect rendering. Try enumerating them! Thus,
> neither method B nor C seem attractive.
>
>
> Method C is a fallback and I think most agree it is not ideal.
>
> For Method B, are you saying that it is not practical to detect cross
> origin usage and thus we cannot do either of B.1 and B.2?
>

"practical" is an imprecise term ... I say it creates a very large attack
surface that will be very difficult to completely defend.

My simple challenge is to spec out, even informally, the exact conditions
under which CSS shaders would be allowed by method B. Count how many times
you think you're done but someone comes up with a new case you hadn't
thought of :-). BTW it's not just about cross-origin resources; as we've
discussed, other sensitive data can be present in rendering that's not
related to origin checking.


>
> Method A sounds interesting. At least it's a more contained problem than
> method B. However, it's not clear to me that it's implementable at all. If
> you're compositing the Web page and you hit a shader that takes "too long"
> to run, AFAIK it's not generally possible to abort the shader and continue
> compositing the page. It seems that "behave as if the shader had completed
> its operation" can't be done. On the other hand "If a shader executes in
> less that MSET, then the implementation must wait until MSET has ellapsed
> [sic]" also seems difficult to achieve since GPU execution is highly
> asynchronous and pipelined.
>
>
> My understanding is that some of Method A may be difficult with current
> drivers but that with the hardening work happening on 3D drivers and new
> architectures, it will be possible.
>

I hope you're right, but I haven't heard that there's anything coming
that's better than a destructive reset on timeout, which will let the
browser keep running but we'll have to restart compositing from the
beginning, which is insufficient for Method A.

I certainly wouldn't want to depend on method A until someone has a
proof-of-concept that demonstrates it can work.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]
Received on Thursday, 5 January 2012 23:45:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 January 2012 23:45:26 GMT