Hyper-Threading, Linus Torvalds vs. Colin Percival [crypto attack bug on hyperthreaded processors]

Slashdot ^ | May 18, 2005 | timothy

[HiTech RedNeck]

Hyper-Threading, Linus Torvalds vs. Colin Percival

Posted by timothy on Wednesday May 18, @08:17AM from the local-exploit-means-other-bad-things dept. OutsideIn writes "The recent Hyper-Threading vulnerability announcement has generated a fair amount of discussion since it was released. KernelTrap has an interesting article quoting Linux creator Linus Torvalds who recently compared the vulnerability to similar issues with early SMP and direct-mapped caches suggesting, "it doesn't seem all that worrying in real life." Colin Percival, who published a recent paper on the vulnerability, strongly disagreed with Linus' assessment saying, "it is at times like this that Linux really suffers from having a single dictator in charge; when Linus doesn't understand a problem, he won't fix it, even if all the cryptographers in the world are standing against him.""

[HiTech RedNeck]

This is being ballyhooed by some as a Linux problem, but it sounds like it would affect security on any general purpose multiuser OS running on a hyperthreaded processor. Basically the problem lets an unprivileged process sniff out a crypto key on an unrelated, uncooperating process. Colin Percival is claiming he has implemented a successful exploit against OpenSSL, using this vulnerability. Commercial co-users of a server (does FR fall into this category, or does it have its own dedicated machines?) would seem to have cause to be nervous.

[HiTech RedNeck]

spook-in-the-night bump

[jokar]

bump

[ConservativeMind]

I've read the paper about the BSD exploit and it is a real problem. It described multiple ways to infer what was being done on the rest of the processor with moderately high to perfect precision. The next unpatched exploit could allow this to happen, communicating the data flow over a reasonably fast connection (the process requires a lot of overhead to do the inferring, so the traffic can't be the full bandwidth).

Intel is already looking at the fixes necessary for a processor microcode patch, if possible (via BIOS upgrade).

The original paper was barely a dozen pages or so in PDF format.

[SoDak]

I use OpenSSL in financial services. I've heard about this exploit, but I haven't switched to the 64 bit kernel yet on my AIX boxes due to a legacy issue with the database. The way I understood it was that the vulnerability was only present while using 64 bit kernel, although I could be wrong. We have physical safeguards in place to minimize our risk anyway.

[HiTech RedNeck]

You can overwrite an Intel chip's microcode from BIOS? I guess that means you could turn a Pentium into a chunk of useless metal too, with a virus (by writing a junk microcode into it). Or, simply turn the Pentium into a trojan.

[SoDak]

Ooops, nevermind, wrong exploit. This is an intel issue. My warning was on PowerPC.

[HiTech RedNeck]

It looks to me like you'd have the problem if you shared the server with an untrusted party. If you have the server all to yourself, that's different.

[SoDak]

At many locations, I share the server with anywhere from 10 to 1200 users depending upon the size of the installation.

[LesbianThespianGymnasticMidget]

FreepGeeks©

Do I get to coin a phrase?

[ConservativeMind]

Part of the delivery package can have the encrypted code to update the microcode inside the processor. The BIOS itself is necessary to talk to any device (it translates code or OS drivers into the hardware language) and the BIOS update fixes bugs in the BIOS as well. If the bug exists at the BIOS level, all operating systems will have the same problem, for example.

BIOS updates have had processor microcode update capability for quite some time now, but processors rarely need microcode changed.

[HiTech RedNeck]

Huh, so someone would have to crack the microcode cipher to touch the microcode. This would still seem to me to be a holy grail of virus writers.

[ConservativeMind]

Well, yes, but neither Intel nor AMD publish their microcode instructions, along with not publishing their encryption methods.

The code is unique for each revision and model of processor out there, so a virus would have only the most limited ability to spread this way. And once the microcode was broken too badly, the virus would be stopped cold, so a writer would need to turn off access to HyperThreading or zero out more rarely used registers to be a nuisance.

[HiTech RedNeck]

The tinfoil implications are still fascinating. Any gummint with enough resources to eat the packaging off of a Pentium with a suitable acid and reverse compile the hardware they find, would be able to hack the hardware. You wouldn't want a microcode attack virus to kill the processor, but only to give you a backdoor to the machine, say by tapping out a code of an unusual sequence of instructions to the chip, whereupon the chip ups your privilege to supervisor level. Such a virus would work on Windows, Linux, Solaris... what have you.

[familyop]

The rest of the story is also important, IMO. After following the "recent Hyper-Threading vulnerability" link,...

~~~~~~~~~~~~~~~~~~~~~~~~~

http://it.slashdot.org/article.pl?sid=05/05/13/0520214&tid=172

Posted by CowboyNeal on Friday May 13, @08:07AM
from the not-just-for-performance dept.
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."

~~~~~~~~~~~~~~~~~~~~~

And there's the "serious security flaw" link,...

~~~~~~~~~~~~~~~~~~~~~

Hyper-Threading Considered Harmful [much more info]
http://www.daemonology.net/hyperthreading-considered-harmful/

[SoDak]

I suppose that term works.