Re: Documenting Timing Attacks in Rendering Engines

On Mon, Dec 12, 2011 at 3:21 PM, Chris Marrin <cmarrin@apple.com> wrote:

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

Yes.


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

Your argument is approaching the ridiculous.

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

We're talking about isolation for the purpose of security.  That's much
harder than isolation for the purpose of interactivity.

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

If you want to try to build such a system, please be my guest.  I'm trying
to save you a bunch of effort by explain that we have 30 years of security
research that says it can't be done.  If you ignore that research because
you don't understand it, you're just going to end up wasting a lot of
resources.

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?


Yes.  I believe that if you do not execute the GLSL shaders, then the
sensitive information will not enter the timing channel.


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.


If you feed the sensitive information as input to GLSL shaders, then those
shaders will take different amounts of time to execute based on the
sensitive data.  Once that happens the sensitive data is in the timing
channel.  I claim that once the information is in the timing channel, it
can no longer be hidden from the attacker.

I've got 30 years of security research on my side.  As far as I can tell,
you've just got your opinion on your side.

Adam