Re: Documenting Timing Attacks in Rendering Engines

On Dec 12, 2011, at 3:05 PM, Adam Barth wrote:

> On Mon, Dec 12, 2011 at 2:56 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> On Dec 12, 2011, at 1:06 PM, Gregg Tavares (wrk) wrote:
>> On Mon, Dec 12, 2011 at 11:48 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>> On Dec 12, 2011, at 10:23 AM, Adam Barth wrote:
>>>> I'm happy to start talking about solutions once folks stop pretending
>>>> this vulnerability doesn't exist.
>>> 
>>> One solution would be to hide the amount of time it takes to render from
>>> the content author. This is theoretically possible if you render in a
>>> different thread than the one in which JavaScript is running (the web
>>> thread). For instance, the web thread could construct a list of commands
>>> used to render the page and then pass that list to another thread or process
>>> for the actual rendering. While rendering is happening in that other thread,
>>> the web thread can continue, generating a new display list for the next
>>> frame.
>>> 
>>> You'd still throttle the web thread to the display refresh rate to avoid
>>> generating more display lists than could possibly be useful. But the actual
>>> rendering could take an arbitrary amount of time without affecting the rate
>>> at which display lists are generated. Since shader execution time is purely
>>> a rendering artifact, the author would never know how long it has taken.
>>> 
>>> The downside of this approach (other than additional complexity) is that,
>>> if rendering is slower than the display refresh rate, more display lists
>>> would be generated than rendered. These would simply be discarded, but the
>>> browser would be doing more work than it does today when under heavy
>>> rendering load.
>> 
>> 
>> In this particular case I think the problem boils down to
>> requestAnimationFrame. It's only going to give you frames as fast as it
>> takes to render and one way or another you can use that to get your timing.
>> (I don't think setInterval/setTimeout would be any different). At some point
>> the JavaScript or HTML renderer will be throttled waiting for this other
>> process to do work. You just need to figure out how much work to give it to
>> find that throttling point and then use that to adjust how long rendering
>> takes.
>> 
>> 
>> rAF need not know anything about the rendering process. As far as the author
>> knows the system is running at 60fps no matter how complex the page. In fact
>> nothing that the author can see needs to know about it. As far as the author
>> is concerned he is rendering to a display list at 60hz (or whatever the
>> display rate is), and as long as creating that list doesn't give back any
>> timing information (which it shouldn't), there should be no way to know how
>> long a given rendering operation will actually take.
>> 
>> Maybe you're concerned that the web thread would sometimes need to block on
>> the rendering thread. By definition that would never be allowed. The final
>> rendered image would be "output only". This of course would not be possible
>> if you needed to read back the image, as you're able to do with canvas. But
>> obviously any such read back would be disallowed when the canvas (or any
>> other object whose image is processed by content code) contains pixels from
>> the rendered page.
> 
> It doesn't matter if one blocks on the other.  They're competing for
> the same resources, which means one thread (either the web thread or a
> worker thread) will be able to observe how many resources the
> rendering thread is using.  That information contains the sensitive
> information we are trying to hide.

And so you have to isolate the threads so they're not using a shared resource. In my last message I mentioned two ways to do that. One is to isolate the rendering on a separate processor and the other is to use a GPU and prevent the web thread from seeing when the rendering operation is finished.

-----
~Chris
cmarrin@apple.com

Received on Monday, 12 December 2011 23:23:54 UTC