Slashdot Mirror
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."
Somehow I doubt it. If every time a securty issue was found with a product people binned it then we wouldn't be running Linux, Windows, Firefox, IE, WiFI, etc...
Not all multi-user systems are designed to be secure against the best hackers around, and there is often bad cost/benefit at following all security recommendations as soon as you hear about them.
Give us some more facts, so that we can think for ourselves.
Not much to read yet. Seems more like a publicity stunt by the author. This could have been posted *after* the details have been published.
We will have to wait to see if this security flaw affects the linux kernel. BSD and BSD related kernels are affected for sure. See below taken from the link.
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.
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.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
Recompile your kernel with hyper-threading disabled. Simple question: Why do I have to wait until this guy does his conference presentation to find out what the exploit is, how it is implemented? I have to admit that this is one time when RTFA didn't work. Anyone have any more information?
Always do right. This will gratify some people and astonish the rest. -- Mark Twain
question 4 in his list:
I get a slight hunch that is not as serious as it sounds. the cliche use of that tilte is an indication too.
Now lets read the reast of the article...
This space is intentionally staring blankly at you
I'd sooner guess that by presenting a paper at a conference, he's hoping to turn this into a job offer. There are any number of stories about black-hats mending their ways, and getting security jobs. Here's someone trying to start out as a white-hat, doing things the right way to begin with. Seems to me that if he's on the mark, he's a better risk for a job offer than a reformed black-hat.
The living have better things to do than to continue hating the dead.
I think the FreeBSD team is being overly cautious about this issue. They now have disabled HTT by default on all of there release trees stating the reason is because information leakage is possible. This is not ture when anyone can just change the crypto method they are using to something like an RSA method using a FFT(Fast Fourier Transform). There are other methods possible too such as just forcing the HT sibling to go idle for a period of time which would allow the crypto program to run without leaking any information.
-DR
I think he is giving the world some warning that the security hole exists and that after the conference exploits for it may appear in the wild (if they don't exist already). Vulnerabilities are sometimes announced this way: for example the OpenSSH team issued a mysterious warning saying that everyone running sshd should turn on privilege separation. A little while later they disclosed an exploit in the current sshd and made a new release with a fix. It happened that if you had privsep turned on you weren't affected by the exploit. The warning gave most admins a chance to secure their systems, but didn't give any details of the exploit.
Now, you might not think this guy is credible and so wait for him to 'show you the code' before applying the suggested fix. That's up to you.
-- Ed Avis ed@membled.com
Limiting hyperthreading to single processes is a good idea anyway. Since the multiple threading units share the same cache, you'll get better cache coherency by doing this.
My personal guess is that it's a timing attack based on CPU performance counters--both threads can read the performance-counting data for the CPU, so they'll have access to a ton of details data. This includes things like branch prediction, which may be enough to *slowly* reconstruct all of the bits in an RSA key that's used over and over.
the reason comes tomorrow. Oh, and you should also give me all your cash today because it is obsolete, more details to come tomorrow.
Yes. While I am a "full-disclosure is better than not" guy, you (or others like you) would be screaming even louder about how "irresponsible" this guy would be if he had released the "reason" today (said "reason," BTW is a proof-of-concept exploit, one that malicious jerks will probably adapt to their desires after it's released).
Oh yes sysadmins, disable hyperthreading because some poster on slashdot said so. This is just too gay.
Not as asinine as clueless AC posts like yours, modded up as "insightful" by equally clueless people who happen to have moderation points today. The guy is awaiting his doctorate at one of the world's most prestigious universities, has an excellent track record, and has chosen a conservative but less-controviersial approach in disclosing this issue.
All of which you would have known, if you'd bother to read TFA rather than spouting off nonsense here.
The Future of Human Evolution: Autonomy
Question is, is seperation between threads in Ring 0 ( Kernel threads ) and other rings enforced? Or is it all one big information free for all?
Normally, when a CPU runs a thread, it's flushed for the next thread to run. This enforces a pure environment, and data seperation between threads ( and thus users, processes, and kernel space ). There are some additional protections for things running in diff rings.
But here, this implies that all running threads share the same cpu, and in some cases, there is no seperation, especially in the case of registers. Now, one could read info from another thread, but it'd be difficult to do, you'd have to do it a chunk at a time, etc.
Now, since to the CPU, there is notion of users, then it's possible different threads from processes from different users could be runing in the same proc at the same time, leading to the possibility of even more snooping.
Unless some sort of special protection is given to ring 0 threads, then it's even worse!
What's worse though, is one thread may be able to corrupt the state of another. You may not be able to get root, but writing random data into another programs state is a potent DOS.
While DRM as a concept is inherently flawed (if you can access the information, you can copy it), computers are not inherently insecure. Most vulnerabilities are due to bugs or design flaws; the ones that aren't are based on something that just wasn't expected previously (e.g. timing-based attacks - which this one might be).
This particular problem affects people running multi-user servers; I assume you've never been the admin of such a system. You need to be pretty paranoid to keep such systems secure, and even then there are occasional compromises.
Oh, and as for worrying about PC security - everybody should worry about remote exploits and viruses. Spammers and others love to lots of your basic home PCs as zombies.
Alan Turing went to Cambridge and earned a fellowship there. That is also where he conceived the idea of the Turing machine - the basis of all programmable computers.
Where you get your education is immaterial. More important is what you do with it.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
The point is that the people who are capable of crafting an exploit for this or any similarly obscure security flaw are also capable of 1) packaging their exploit in such a way that far, far less capable people can perform it and 2) disseminating their packaged exploit very widely. A mega-corp wrote WinXP so that any rube can run it; why would a tricky in-CPU exploit be different?
He's 23, and he's getting a PhD; I wouldn't call that lack of ambition.
Yes, by all means, let's deride advanced education as being worthless and a foolish pursuit. It's much better to try to learn everything by yourself and reinvent the wheel rather than participating in a community environment of study.
...For Dummies books and only leave the house to stare in the window of the hot chick next door at 11PM.
Because, of course, who needs community? People are awful. I'd much rather stay in my mom's basement with my
+++ATH0
Here is another possibility:
Quad-threading.
This way, the spy/trojan threads would not be able to presume anything about what else is being executed along with them unless they happened to be the only other running processes.
Of course, quad-threading on a P4 would be futile given that it has only a three-ways instruction decoder and integer execution units. If Intel replaced the AGUs by one extra complex ALU and two additional simple ALUs, quad-threading would become practical... though the six-ways instruction decoder and register files might not.