Re: Documenting Timing Attacks in Rendering Engines

On Dec 12, 2011, at 1:33 PM, Adam Barth wrote:

>>>> ...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?

Those still exist? :-)

I guess the real question is how can the author know how many cores a system has? Because if he can discover that then we have another bit of information being leaked. 

But aside from that, I think for the most part a single processor system usually has a second processor, in the GPU. So you can still decouple the most expensive part of the rendering (including the GLSL execution) from the web thread. So I think it's still possible to isolate the timing.

> 
>> 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?

I have evidence that you can effectively decouple application performance from rendering. It happens in every iOS device. And WebKit decouples compositing from layout, style resolution and rendering. Neither of these has been used to prove that timing information is not leaked. That's not why they were done. But on iOS smooth scrolling is maintained even during expensive layout of a page, so in they way the two are isolated.

> 
>>> 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

But none of these papers are trying to state that it's impossible to hide timing information, just that there are clever ways to extract timing information. For instance, the first paper you cite says "Our results demonstrate that timing attacks against network servers are practical and therefore security systems should defend against them.". And we are currently discussing how to accomplish that defense.

More than anything else these papers are trying to convince a skeptical audience that you can actually derive useful information from examining the timing of a system. I think we have all now gotten over that hurdle and are on to the "should defend against them" part.

> 
>> 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.

So you should specifically refute this proposed solution. For instance, if we weren't rendering at all (including not running the GLSL shaders) and were simply placing drawing commands in a list and then discarding that list, do you agree that no timing information would be leaked? If so, do you not think it's possible to hide the operation of the processor of that command list from the author? I think both are possible.

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