Re: Documenting Timing Attacks in Rendering Engines

I'm not sure what more I can say to convince you.  If you want to
invest effort into trying to obfuscate the timing signal, that's your
choice.

My prediction is that you will later be sad because your efforts will
result in a defense that doesn't prevent these attacks.  Whether you
believe me is immaterial because someone (possibly me) will just
demonstrate the attacks on your implementation later.

Adam


On Tue, Dec 13, 2011 at 4:46 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Dec 12, 2011, at 3:33 PM, Adam Barth wrote:
>
>> ...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.
>
>
> Maybe we can't make any progress in this discussion. I pose potential
> solutions and you berate them (and me). I'm pretty thick skinned, so there's
> no damage done. But it's not very useful.
>
>> 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.
>
>
> Maybe, but until you engage in a productive dialog, how can we know if it's
> so hard that the problem can't be solved in this way?
>
>
>> 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.
>
>
> Sorry, but I don't see any research here that says it can't be done. Just
> that it's a real problem to consider. Are you saying that you personally
> have experience trying to solve this problem in the context of the web? If
> not, shouldn't we try to engage in a conversation to see if we can solve it?
> Do you have some information that convinces you that this approach is
> unworkable in this context, or just some aging research in some not very
> related areas? I really want to engage in this discussion.
>
>
> 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.
>
>
> That's very vague. Technically, once I have placed sensitive data on my hard
> drive that information can't be hidden from an attacker either. The web is
> secure not because attacks are rendered impossible, just improbable. This
> seems like the same case. If we can keep the timing information sufficiently
> obfuscated I believe we will have a solution to the problem.
>
>
> 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.
>
>
> Please don't say that anymore. None of the papers you cite say this problem
> is unsolvable. If you don't want to engage in trying to solve it, please say
> that. For my part I will say that it's fully possible that there will be a
> showstopper problem with this approach. But it won't be because of some 30
> year old cryptography papers.
>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>

Received on Wednesday, 14 December 2011 01:24:42 UTC