Re: Documenting Timing Attacks in Rendering Engines

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.

Many graphics libraries used in browsers today use, or can be made to use, display lists. So while this would not be a simple solution it would be a practical one. It would add complexity, but I think it would solve the problem of timing attacks in any page rendered content.

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

Received on Monday, 12 December 2011 20:51:43 UTC