I presented details of how to exploit this security flaw at BSDCan 2005 in Ottawa on May 13th, 2005. For those who were unable to attend my talk, I have written a 12-page paper, Cache Missing for Fun and Profit, discussing this flaw and related problems, both realized and theoretical.
CVE: The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2005-0109 to the problem of information disclosure resulting from cache evictions in simultaneous multithreading processors. This is a candidate for inclusion in the CVE list, which standardizes names for security problems.
FreeBSD: This issue affects FreeBSD/i386 and FreeBSD/amd64, and is addressed in advisory FreeBSD-SA-05:09.htt.
NetBSD: The NetBSD Security-Officer Team believes that workarounds will be suitable for the majority of our users. Since this issue is a complex one, the 'right' solution will require a larger discussion which is only possible once this issue is public. This issue will be addressed in advisory NetBSD-SA2005-001, which will provide a list of workarounds for use until the 'final' conclusion is reached.
OpenBSD: OpenBSD does not directly support hyperthreading at this time, therefore no patch is available. Affected users may disable hyperthreading in their system BIOS. We will revisit this issue when hyperthreading support is improved.
RedHat: Updated OpenSSL packages that fix security issues are now available [...] The OpenSSL library has been patched to add a new fixed-window mod_exp implementation as default for RSA, DSA, and DH private-key operations. This patch is designed to mitigate cache timing and potentially related attacks. [Quoted from RedHat Security Advisory RHSA-2005:476-08. Note: I do not believe that the patch used in OpenSSL is sufficient to avoid disclosure of cryptographic keys on a hyperthreaded system, although it does block the very specific attack which I demonstrated in my paper.]
SCO: This affects OpenServer 5.0.7 if an update pack is applied and SMP is installed; it also affects UnixWare 7.1.4 and 7.1.3 with hyperthreading enabled, but hyperthreading is disabled in UnixWare by default. This is covered by advisory SCOSA-2005.24.
Ubuntu Linux: Since it is not possible to provide a safe patch in a short time, HyperThreading has been disabled in the updated kernel packages for now. You can manually enable HyperThreading again by passing the kernel parameter "ht=on" at boot. [Quoted from Ubuntu Security Notice USN-131-1.]
(Other vendors are affected, but they haven't provided any statements.)
UPDATE: There are some comments from Intel in an eWeek story about this issue.
UPDATE: Linus Torvalds has commented on this on the linux-kernel mailing list. He clearly doesn't understand the problem -- but in his defence, he's not a security guy. Hopefully the Linux developers who do understand security will talk some sense into him.
Probably not. This security flaw is primarily a problem for servers.
Not unless they also have hyperthreading.
As far as I know, this flaw only exists on Intel processors. (Of course, I don't know much about the CPUs used in Apple computers -- it is entirely possible that someone else could construct a similar attack there.)
Update: On June 6, 2005, Apple announced that they would start using Intel processors over the next two years. So while I do not believe that existing Apple computers are affected, future Apple computers might have a problem.
Some vendors haven't provided statements to me. This may be because they're too busy fixing the problem, or it may be due to corporate policies which forbid such disclosures. Either way, if there isn't a statement above, it's because I haven't received one. You may wish to check back later.
AMD64 is the name given to the 64-bit version of the x86 architecture developed by AMD. Recent Intel processors with "EM64T" use this architecture.
I'm unemployed. For the past three months, I've spent almost all of my time working on this security flaw -- investigating how serious it was, contacting all of the affected vendors, explaining how this should be fixed, et cetera. I simply haven't had time to go out and get a job -- and I decided that making sure that this issue was properly reported and fixed was far more important than earning some money.
Money is always good. In all seriousness, I'd like to spend a few months writing a completely new cryptgraphic library which is designed from the ground up to be immune to this attack, as well as all other timing attacks. If you think you or your company could offer me some funding to allow me to do this, please let me know.
I don't hate Intel -- in fact, I think Intel makes great CPUs, and I have an Intel processor in every computer I own. (Not that I have anything against AMD; it just happened to work out this way.) But as someone who works in the field of computer security, I don't play political games: If I find a vulnerability, I'm going to report it and work with vendors to fix it, regardless of what the problem is or who it affects.
As a computer security researcher, I'm not concerned with assigning blame; rather, I'm concerned with making sure that systems are secure. At this point, the fastest and easiest way to fix this problem is via the operating system, so that is what I have recommended. While Intel can fix this problem on its future processors, I do not see any way for them to fix this problem on existing processors without a complete recall (similar to the result of the famous FDIV bug), which would be pointless when the problem can be so easily fixed via the operating system.
Feel free to contact me with any questions about this security flaw. I can't guarantee that I'll be able to reply to everyone -- I have no idea how many emails I'll get -- but I will make an effort to address every serious question I receive either via personal email or on this web page.
December 2004: Proof-of-concept exploit written and tested.
December 31, 2004: FreeBSD Security Officer Team notified of upcoming security issue.
February 2005: First draft of paper completed.
February 27, 2005 - March 18, 2005: Other security teams and vendors (including Intel) contacted.
May 13, 2005 @ 00:00 UTC: Official public disclosure that a security flaw exists in Hyper-Threading.
May 13, 2005 @ 15:00 UTC: Full details released.