Hyperthreading Considered Harmful

cperciva writes "Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious security flaw. This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine. Administrators of multi-user systems are strongly advised to take action to disable Hyper-Threading immediately. I will be presenting this attack at BSDCan 2005 at 10:00 AM EDT on May 13th, and at the conclusion of my talk I will also releasing a paper describing the attack and possible mitigation strategies."

Comments

This ought to be interesting

[displague]

Doesn't Linux handle HT the same way it handles SMP? So even if there was a hole in HT, hardware-wise, software wise you would be just as protected as you would be on an SMP system?

Re:This ought to be interesting

[cahiha]

Well, I didn't see an explanation on the site... here is my guess what happened.

With HT, registers for multiple threads have to reside within the same CPU, whereas with SMP, they are physically in two different chips. Perhaps the registers used by HT are not properly protected against reading by other threads. The fact that SMP code was probably reused may be the cause of the problem: the code developed for SMP didn't have to deal with this situation before.

Guessing even a bit more, this may be hard to fix in software. If the hardware simply doesn't protect registers properly, then the kernel may have to clobber them to protect the information, but that may impose far too much overhead for HT.

However, a workaround might be to permit HT only for multiple threads within the same process. That would still give some speedups to compute-intensive processes that are written to take advantage of threading.

Re:This ought to be interesting

[uss_valiant]

Doesn't Linux handle HT the same way it handles SMP? So even if there was a hole in HT, hardware-wise, software wise you would be just as protected as you would be on an SMP system?

If you follow the article link you see that it only mentions *BSD and SCO unix variants. Not a word about linux or windows or any other x86 based OS.
I guess we will have to wait for his final paper which should be available in +12 hours or something like that.
Seems like he spent considerable time on this issue and he is unemployed. If you read his website, you probably come also to the conclusion that he sees this as an opportunity to get paid for his volunteer work. This /. announcement for his paper that will be available in a few hours can be seen as a great advertisement for his own work (no offence).

He could also have contacted AMD to get a little funding as they didn't jump on the HT train :)

Re:This ought to be interesting

[quarkscat]

Damn, Sam!

It sure sounds like this guy is on the up-and-up. When the full details are disclosed, I may (just maybe) forced to buy a new Intel system with HT -- imagine the possibilities!

Got some problem with pesky DRM? No problem! Run that nefarious application on the Intel HT box, and walk away with the keys. Sweet!

(Just need to make sure that that MSFT "Palladium" crap is turned off in the BIOS first, right?)

Re:This ought to be interesting

[Anonymous Coward]

This defeats the reason I turned on HT in the first place: when a windows process goes berzerk as it is inclined to do now and then, the system remains responsive enough for me to kill the offending process. I otherwise wouldn't think of taking the overhead of HT, which makes the system perceptibly slower.

How to exploit

[jabagi]

I'm curious to see how an exploit can be made out of this. Is it possible to assign one of the virtual CPUs to a "sniffer" for a prolonged period?

Reminds me of a bug in Michigan Terminal Service

[jesup]

On MTS (IBM mainframe OS used at universities in the 70's/80's and probably into the 90's) there was a bug where when process switching, the FP registers of the last process to run were stored in a world-readable page of memory. The RPI ACM used this to create an inter-process communication program -- actually a 'chat' program (MTS had no inter-process communication other than files at the time).

Probably a Timing-Based Attack

[Sunlighter]

My guess is that this is a timing attack. While thread 1 generates an RSA key, thread 2 times itself performing various instructions. If thread 1 is using the FPU to do a multiply, the FPU won't be available for thread 2 right away, so there will be a measurable delay. Thread 2 can then determine when thread 1 is running multiplies.

If my hunch is correct, an OS could fix this by allowing a process to enter a "secure mode" which would force the other thread on the same CPU to be idle when that process was scheduled.

Re:Probably a Timing-Based Attack

[casualgeek]

... an OS could fix this by allowing a process to enter a "secure mode" which would force the other thread on the same CPU to be idle when that process was scheduled.

Wouldn't that "secure mode" then become some sort of DoS attack? What if an arbitrary user process request repeatedly this mode, just as to slow the rest of the system to a crawl? I know there is now perfect solutions though...

Re:Probably a Timing-Based Attack

[MoogMan]

It is more likely that there is some inherant cache leakage from Logical CPU 0 to Logical CPU 1. Therefore, a process running on CPU 1 could continuously snoop data that CPU 0 is read/writing as its doing its calculations. e.g. In-between an operation at a FPU, being stored in the cache ready to be processed in a different unit.

stupid paranoid people

[Anonymous Coward]

Some of these "security risks" that people propose are just ridiculous. I mean, I know there are a tiny amount of people who actually follow these risks religiously, and do everything they can to fix them, but they are basically paranoid freaks. Unless your the DOD or have some super top scret evidence, then this means SHIT to you. Lets face it, a trojan, worm or whatever isn't going to use this obscure method of capturing and RSA key that may or may not work. It would take the work of, well, one of those paranoid freaks. And why would someone target your PC unless you had some really valuable information. They wouldn't.

Sorry, for the incoherent rambling, Im just fucking sick of these "Oh no, new vulnerability" things popping up all the time. The NATURE of computers is that they are INHERINTLY insecure, just as DRM will always be worked around.

Same Guy?

[Bananatree3]

This is the same guy who calculated the 1 Quadrillionth hexadigit of Pi (no, not digit. It is in base 16). His project was called PiHex. According to his currently short but illustrious trackrecord, along with this current announcement, he is destined for being a big-name IT security guru.

Re:Not many details

[cnettel]

Speculation would say that it's quite hard to fix in the OS. If this is some kind of general flaw allowing access to all memory the another thread is allowed to access, one would basically have to make sure that the other virtual CPU is idle before entering ring 0 at any system call. That, in turn, could maybe be accomplished by sending an interrupt somehow to the other CPU, but a system call is supposed to be cheap.

What Intel might hope for is that this is fixable in microcode. If not, well, then there's real trouble.

Timeline - WTH?

[kenh]

The timeline for this "project" is just amazing:

Disclosure timeline

• Late October, 2004: Initial discovery.
• 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 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 to be released.

Why wasn't Intel notified over the past SEVEN MONTHS ?

Why pre-announce a vulnerability?

This sounds like an attempt to build himself up at the cost of others who use these processors - assuming this is a real vulnerability.

My laptop has an HT processor, and I am absolutely unconcerned about this vulnerability, since he said it only relates to servers ;^)

Let me pre-announce a few more entries for his "disclosure timeline":

• May 13, 2005 @ 15:05 UTC: (His) web server squeals like a stuck pig from the /. load
• May 13, 2005 @ 15:12 UTC: First substantive post to /. regarding this vulnerability - summary, nothing to see here, move along

Security is a real-time embedded application

[gvc]

Some of the most effective hacks/espionage come from exploiting "secondary channels" for information.

For example, I know of one hack from the good old days that involved placing a password across a page boundary. The OS compared the password to a plain text version character-by-character, so faulted if the characters up to the page boundary were all correct. Observing the disk access light (or the time to reject the password) provided character-by-character cracking.

Of course, password checking is now more sophisticated, but so is cryptanalysis. I think people that use encryption for real are well aware that there's an exposure in doing so on any time-shared system, or any system that can be observed in any way by a potential cryptanalyst.

I would guess, based on the sparse information presented here, that this is the nature of the attack. If - and that's a big if - you can cause an adversary to be scheduled in just the right way, you may be able to capture part or all of a private key by observing timing artifacts of the hyperthreading implementation.

This may be good security research, but unless I were protecting state secrets, I'd wait and evaluate the risk relative to other security risks that we find acceptable. I would also guess that the exposure is minimal compared to other high-tech and low-tech potential information leaks.

Re:Where's the details?

[Drakonian]

I just saw the talk. Have you considered that he TOLD Intel about it months ago but they wouldn't listen/didn't care? It's not easy to get the ear of a big company when you have discovered a major flaw in their product.

L2 covert channel without shared memory possible

[Anonymous Coward]

after reading his paper at http://www.daemonology.net/papers/htt.pdf i think his point is that with htt enabled it's possible to have a covert channel between threads/processes with _shared memory_. that's not specific for htt and page-sharing threads - several months ago i wrote a covert channel implementation for arbitrary processes over a (non-htt) pentium 4 l2 cache that _do not share_ any memory pages. i am not going to make that code public.

disclaimer: this post is just supposed to be a small "fuck you, we were already using that technology and we even have a superior implementation!" to the so-called security expert community.

Re:Google Adbar

[cperciva]

Did anyone else notice the Intel advert for "Hyper Threading Linux" at the top of the google ads on the article page?

I put adsense onto most pages on daemonology.net, just because I can't see any reason not to (given that the ads are reasonably inobtrusive).

This particular time, however, I had a very specific reason for putting them on: I wasn't sure if my server would be able to handle the load, and this way if there is too much traffic then I might be able to afford to get another server.

I wonder how much revenue he'll get from this announcement?

So far, not enough to rent a server. (But so far my server seems to be doing fine.)