Re: Documenting Timing Attacks in Rendering Engines

On Mon, Dec 12, 2011 at 12:58 PM, Chris Marrin <cmarrin@apple.com> wrote:
> On Dec 12, 2011, at 11:57 AM, Adam Barth 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.
>>>
>>> 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.
>>
>> While tempting, this approach doesn't work.  For example, the web page
>> can create one WebWorker for each CPU core and measure how fast these
>> workers run.  The background thread that does the rendering will need
>> to be scheduled onto some CPU core, and it's performance
>> characteristics will be different depending on whether it is dropping
>> frames.
>
> Before declaring that it won't work, I think we need some sort of proof. In the case you bring up, it would be a simple matter of preventing web workers from getting assigned to the same CPU as the rendering thread and thus any timing leakage would be avoided.

How would that work in a system with a single core?

> Once you can decouple the web thread from the rendering thread there are many techniques you can use to isolate the timing of each. I believe you can ultimately isolate them enough to make timing attacks impractical.

Do you have any evidence to support this claim?

>> In general, I don't believe any approach that involves hiding the
>> sensitive information after it has entered the timing channel can
>> work.  We have 30 years of implementation experience in a wide variety
>> of settings that has taught us this lesson the hard way.
>
> Sorry, but I don't understand what you're saying here. What "timing channel" are you talking about? Can you give me an example or two that has come up in the past 30 years where this lesson has been learned? And I'm talking about cases where the rendering loop was not directly in line and therefore the obvious culprit.

Perhaps the most famous example is this paper:

"Remote Timing Attacks are Practical"
http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Among other interesting topics covered in the paper, particularly
on-point are their results about interprocess and inter-virtual
machine timing attacks.

Another famous example is this paper:

"Cache-timing attacks on AES"
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

These are fairly recent examples from the cryptography literature.
There are also a large number of examples from the systems literature.
 The earliest reference I could find in a brief search was this
description of a 1976 timing attack in multics.

http://www.multicians.org/timing-chn.html

> While it's important in this discussion to recognize that there is a real problem to be solved, it's equally important to keep an open mind about how it might be solved. If you're saying that there is no way to isolate the timing of the rendering operation from probing by the content author, then you are effectively saying that there is no way to ever solve this problem. I don't think that's the case.

If there is a solution, I believe it will involve preventing the
sensitive data from entering the timing channel, not by trying to hide
the information after it has entered the timing channel.  More
specifically, I believe we will not be able to defend against these
attacks if we allow sensitive data to be given as input to GLSL
shaders.

I will note, however, that I don't know of any way to fix the
vulnerabilities in this feature.  For that reason, I can only explain
why candidate solutions don't work.

Adam

Received on Monday, 12 December 2011 21:34:17 UTC