Re: Documenting Timing Attacks in Rendering Engines

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.

Adam

Received on Monday, 12 December 2011 23:06:44 UTC