Information Security with Colin Percival (O'ReillyNet) [LWN.net]

Interesting

Posted Jul 24, 2005 22:50 UTC (Sun) by bojan (subscriber, #14302) [Link]

I found this bit most interesting:

Finally, the head in the sand prize goes to Linus Torvalds. On Monday, May 16, three days after I published all the details of my attack, Linus wrote that he would "be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it (and as to the covert channel, nobody cares). It's a fairly interesting approach, but it's certainly neither new nor HT-specific, or necessarily seem all that worrying in real life." I really don't know where to start with this, except perhaps to say that I'm very glad that Linus isn't responsible for keeping my computer secure.

I haven't been following this at all. Anyone knows if the issues mentioned in the article have been addressed in Linux kernels?

Interesting

Posted Jul 24, 2005 23:03 UTC (Sun) by dlang (subscriber, #313) [Link]

the attack consists of figuring out what another process is doing based on how much of it's timeslice it acutally uses. the attack is that with hyperthreading this time can be determined more precisely, but it only works if the attack program gets scheduled exactly properly in respect to the target process.

I also don't remember any 'fixes' for the 'bug' other then not scheduling different users processes to run at the same time, which is an extremely heavy penalty to take to prevent an attack that only works under such narrow conditions.

Interesting

Posted Jul 24, 2005 23:25 UTC (Sun) by bojan (subscriber, #14302) [Link]

Thanks for the info. I gather if one wants to be very safe, disabling HT support should do the trick, right?

Interesting

Posted Jul 25, 2005 7:07 UTC (Mon) by Wol (guest, #4433) [Link]

And there was apparently quite a discussion over this, but the reason Linus had his "head in the sand" was the consensus that

THE FIX BELONGS IN THE SECURITY LIBRARIES!

In other words, it's not a kernel problem at all. With which I would agree. Encryption is a user-space process, and IT SHOULD NOT TRUST THE KERNEL. If your algorithm leaks information, it's not a secure algorithm. Fix the algorithm, and the kernel doesn't need to care.

Cheers,
Wol

Interesting

Posted Jul 25, 2005 18:27 UTC (Mon) by papik (guest, #15175) [Link]

I think that it is a problem that is similar to many other: I remember that a while ago there was someone recording the noise of the CPU, some other measuring the time it took a smartcard and the power it consumed. Maybe a solution would be to make some fake computation, like when you fail entering a password, and the system waits some random time.

Cache map side channel

Posted Jul 26, 2005 4:14 UTC (Tue) by xoddam (subscriber, #2322) [Link]

The particular vulnerability on hyperthreaded processors (which is also applicable, to a lesser extent, to multiple CPU cores which share a cache) is that the actual locations of the memory (code and data) one process is using are easily deducible by the other. This reveals far more information than "CPU noise" and load.

Direct-map caches allow the attacking process to discover (using *its own* timing, not some generic load average) which cache lines have been flushed.

Linus is correct to say that meaningful exploits require significant access already: knowledge of the exact processor and configuration, the ability to trigger cryptographic calculations in privileged processes, and the ability to run arbitrary binary code.

It is disingenuous, though, to say that the security flaw is vapour. It isn't.

Interesting

Posted Jul 25, 2005 19:15 UTC (Mon) by huffd (guest, #10382) [Link]

Ooh, wouldn't it be really neat if you could actually get the eploit to work instead of blowing off your head full of steam?

Information Security with Colin Percival (O'ReillyNet)

Posted Jul 27, 2005 6:07 UTC (Wed) by tyhik (subscriber, #14747) [Link]

I would say the argument that "you should listen to me coz' I've written a 12-page article that nobody's managed to refute" is a really weak one, if the publication media is his own web page. I have no experience how science is done in CS field, but in many other fields the refutability of a paper is tested by submitting it for publication. When published, there are at least 2-3 referees, who haven't managed to refute it. If the threat is real, it shouldn't be a problem for Colin to publish it in a top journal. Therefore, get it published, kid, and people will listen to you.

Information Security with Colin Percival (O'ReillyNet)

Posted Aug 8, 2005 17:50 UTC (Mon) by anton (guest, #25547) [Link]

In general, referees don't accept a paper if they cannot refute a claim in it, and don't reject a paper if they can refute some claims. Technical quality is just one aspect in selecting papers; other very important ones are relevance (does the paper deal with an interesting problem?) and originality (does the paper do something new, or is it just a variation of earlier work?). It also depends on the publication how high the standards are that are applied, and there are a lot of subjective factors there (usually the referees will give different evaluations, and give different reasonings for their evaluation).

Acceptance of his paper by some academic publication does not show that Colin Percival has demonstrated a vulnerability that is exploitable in the wild, just that he has done some work that was good enough to be accepted. For what he has shown, read his paper (I have not), and consider whether the setup he used for his experiments could be arranged by an attacker.

My impression is that the danger from this kind of attack is smaller than other dangers that receive less attention; but if I were writing crypto code, I would certainly try for more uniform memory access patterns, so the memory accesses cannot leak information about keys.