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

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

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

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.

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.