[webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)

[Rik Cabanier]

This might no longer be true, but isn't it the case that shaders are
designed to take the same amount of time to execute, no matter what input
they get?
ie if you have an if/else block, the time of the shader would be whatever
block takes the longest. This was done so you can schedule many of them at
the same time without having to worry about synchronizing them.

Rik

On Mon, Dec 5, 2011 at 3:34 PM, Chris Marrin <cmarrin at apple.com> wrote:

>
> On Dec 5, 2011, at 11:32 AM, Adam Barth wrote:
>
> > On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrin <cmarrin at apple.com> wrote:
> >> To be clear, it's not the difference between white and black pixels,
> it's
> >> the difference between pixels with transparency and those without.
> >
> > Can you explain why the attack is limited to distinguishing between
> > black and transparent pixels?  My understanding is that these attacks
> > are capable of distinguishing arbitrary pixel values.
>
> This is my misunderstanding. I was referring to the attacks using WebGL,
> which measure the difference between rendering alpha and non-alpha pixels.
> But I think there is another, more dangerous attack vector specific to CSS
> shaders. Shaders have the source image (the image of that part of the page)
> available. So it is an easy thing to make a certain color pixel take a lot
> longer to render (your "1000x slower" case). So you can easily and quickly
> detect, for instance, the color of a link.
>
> So I take back my statement that CSS Shaders are less dangerous than
> WebGL. They are more!!! As I've said many times (with many more
> expletives), I hate the Internet.
>
> I think the solution is clear. We should create a whole new internet where
> we only let in people we trust.  :-)
>
> -----
> ~Chris
> cmarrin at apple.com
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111208/ee672d9d/attachment.html>