login
Search
Colin Percival, a FreeBSD committer and security team member, has found a local exploit against the current implementation of Intel's Hyper-Threading Technology. "Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious security flaw," Colin explains. "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."
Colin will present the details behind the attack at BSDCan 2005 at 10:00 AM EDT on May 13'th. "At the conclusion of my talk I will also be releasing a paper describing the attack and possible mitigation strategies," Colin explains. The flaw affects all operating systems, and for a secure multi-user environment essentially requires that Hyper-Threading be disabled. More information can be found on Colin's web page on the topic. The formentioned paper can be downloaded here in pdf format.
Hyper-Threading allows multi-threaded applications to execute threads in parallel on a single CPU. Intel's website explains, "Hyper-Threading Technology enables this thread-level parallelism (TLP) by duplicating the architectural state on each processor, while sharing one set of processor execution resources. When scheduling threads, the operating system treats the two distinct architectural states as separate 'logical' processors. This allows multiprocessor capable software to run unmodified on twice as many logical processors."
From the BSDCan website, "Colin Percival is 23 years old and lives in Vancouver, Canada. He received his B.Sc. in Mathematics from Simon Fraser University at age 19, and is currently awaiting his D.Phil. in Computer Science from Oxford University." More recently Colin was elected to the Senate of Simon Fraser University.
Oh my god! This is big :(
Oh my god! This is big :(
Although I wouldnt lose sleep
Although I wouldnt lose sleep over this but any further infomation about this would be really appreciated.
Thanks
San
You think
You need local access ( the comms tasks and interrupt code will fluch the cache) and a system that runs very few threads and few interrupts ( the other tasks and interrupts will flush the cashe).
It sure is no reason to add code or hardware that will slow down the execution of real world loads.
I won't lose any sleep over it...yet
HT is a technology that has its supporters and its share of detractors. Until I see a published proof of the alleged security problem I won't be losing any sleep, disabling HT in my multi-processor machines, or worrying about the security of my crypto-keys.
I'm actually more worried about the rumors floating around regarding shortcuts for factoring large numbers and attacking public key crypto-systems by computing the private exponent component of keys.
PowerPC pawaaaa! :oD More po
PowerPC pawaaaa! :oD
More power, less trouble :o)
AMD pawaa
Waaaaaay more power, less trouble.
Microcode
Finally I have a reason to try out the Microcode feature in the Linux kernel...
Oh, this seems interesting. I
Oh, this seems interesting. I didn't know you could do that with production CPUs. Can you edit all instructions or just a few of them? And do you know of any editors for microcode?
Re: Oh, this seems interesting. I
You can't edit any instructions with it. It exists solely for uploading microcode published by Intel.
I'm actually more worried
I'm actually more worried about the rumors floating around regarding shortcuts for factoring large numbers and attacking public key crypto-systems by computing the private exponent component of keys.
security monitoring
Linux?
Any suggestions about the inpact on Linux Kernels?
I'd imagine the same in Linux
I'd imagine the same in Linux.
Relevant answers here.
Relevant answers here.
Any information on other OSes affected?
Any information on other OSes affected? What about the precious NT kernel?
Did you even read this? Read
Did you even read this?
Read. Comprehend. Post.
"The flaw affects all operating systems..."
OpenBSD do not support HT technology
All Operating system with HT technology, OpenBSD do not support it :-(
AFAIK it does not need specif
AFAIK it does not need specific support.
Running an HT processor as a SMP processor set gets you exposed.
But,
2.6 linux kernels contain special option to improve workability on HT processors. Thus, can this alleviate the problem?
A few weeks ago, there was a
A few weeks ago, there was a flurry of press relating to AMD's use of the 'Hyperthreading bit.' My assumption has been that this is acting in the fashion of either a 'License OK' or 'Enable something resembling SMP despite licensing' flag, riding on the existing 'goodwill' towards HyperThreading to ensure that, say, XP Home users can make use of the cores without an upgrade.
Can someone confirm whether this is correct, and that AMD has not actually implemented a vulnerable form of SMT on these chips?
(If a dual-core package reports dual CPUIDs, and each reports 2 logical CPUs despite a lack of SMT, this seems rather confusing, and suggests some minor annoyance when it comes to detection of vulnerable vs. non-vulnerable 'implementations.')
From what i'm seeing on that,
From what i'm seeing on that, it looks like AMD has just turned on the Hyperthreading bit to take advantage of code written to use Hyperthreading, as a dual-core proc can emulate that quite nicely. It shouldn't be vulnerable to any Hyperthreading exploits, however, as it is NOT Hyperthreading, just SMP.
Eww.
That's awful. That will cause software to inappropriately use HT optimizations when they're not needed on dual core chips.
You misunderstand
Software "optimized" for HT usually use multiple threads if they find the HT bit set, and use a single thread if not. If the bit is not set in the DC AMD64, the software will only use a single thread and the extra core will go to waste. So AMD set the bit so the program in question will use multiple threads which will run on both cores in the DC AMD64. It's as simple as that.
Not necessarily
I agree that using "HT" mode on a true SMP processor wouldn't be that optimal.
However, I'd suggest that any OS that supports HT also supports true SMP, and therefore is ulikely to be purely relying on the HT flag to determine whether or not to optimise for HT style multi-processing verses true SMP.
If the OS in question does purely rely on the HT flag, or rather, chooses not to take full advantage of the SMP hardware (and I'd suspect Windows XP might fall into this catagory), then at least having your SMP processor being used as a HT processor would be better than the other alternative, namely, having the OS consider that the CPU can only execute a single thread. Specifically in the case of the new AMD dual CPUs, I'd think that would mean that only one of the CPU cores on the chip would be used, which is a 100% waste verses the few percent that would be lost when running true SMP in HT mode.
Why not just use GetSystemInf
Why not just use GetSystemInfo?
SYSTEM_INFO sysInfo;
GetSystemInfo(&sysInfo);
DWORD numprocs = sysInfo.dwNumberOfProcessors;
Portable. Accurate. Reliable.
wow. is it...
PORTABLE???!
Portable among all recent Win
Portable among all recent Win32 systems, I'm guessing...
Exploit requires shared cache
The exploit described in the paper requires a shared data cache. Both the dual core processor designs from AMD and Intel have each core having 2 separate caches.
So, this flaw basically only affects machine with HyperThreading. Dual core processors are immune.
Not quite
The current "dual-core" from Intel is really just two separate CPUs wired together in the same package, so they have separate caches. Intel's REAL dual-core CPU is another year off and SHARES the data cache between the two cores. They practically crow about the fact that both cores get to see the whole cache compared to AMD's dual-core.
So while Intel's current offering is okay, their real dual-core chip will be vulnerable. Hopefully, by the time they actually ship it, they will have taken care of this issue.
What about other processors
After reading the article of Colin Percival, it seems that this flaw only concerns the platforms equiped with the Hyper Threading (so far Intel only ?) My question is, in the section of workarround and recommendations, the author suggests to turn off the HT mechanism, but can we not immagine a similar attack on other platforms ?
I'm thinking of ARM processors with Trust Zone technology and the third level privilege dedicated for the security...
Why would an ARM processor be
Why would an ARM processor be vulnerable? When did ARM (I presume you mean XScale now) get hyperthreading? :P
You always have to be careful with the less-capable CPUs - some of them don't have the hardware to enforce priviledges (user/kernel modes) and some don't have a virtual memory system -- for those processors, no data is secure. Just think about the original 8086 and the 80286 - with some effort you could implement a multiprocess OS but you will have absolutely no data security because the CPUs were lacking the basic hardware support.
ARM has MMU; TrustZone is a "secure" code area
The interesting vulnerability with ARM is if a similar trick lets you break the TrustZone security. Currently, the most likely uses of TrustZone are DRM implementations, which will use TrustZone to keep the DRM algorithm and keys secret. If it could be cracked, the keys and algorithm are exposed.
ARM TDMI series have no MMU,
ARM TDMI series have no MMU, But ARM***T and Strong ARM have.
HT mistake
I need more information about this~~~
where I more datail information?
Somebody know this please reply comment~~~
RTFA....
There's a link on the article to the research paper regarding this issue...Please rtfa... (f = fine :-) )
Does Intel reply on it?
Does anybody know what Intel said about this issue?
Other vulnerabilities?
After reading the paper it seems to me that there may be other vulnerabilities. I can certainly understand the author wanting to make a really strong case for a really bad vulnerability in order to kick everyone into gear ASAP, rather than spewing FUD about all sorts of other things... but if this algorithm allows a malicious process to see when another process is accessing memory, I imagine plenty of other algorithms are vulnerable.
For example, hash tables don't generally use a cryptographic hash function because there's no point. But this might (might) allow a malicious process to watch a hash table insert. You would probably be able to tell if there was a collision, for example. You might then combine this with an attack where you can choose the key to be inserted (perhaps you can cause a string to be inserted into a Python dictionary for example), and then observe which keys cause collisions. That would probably be easier than gathering hundreds of bits from a key.
These attacks would be very tricky to pull off, but a) we don't know that this is the first time this has been discovered and b) we don't have a good understanding of what kinds of programs are vulnerable.
IMO it is only prudent to disable hyperthreading for the time being, or maybe only allow threads belonging to the same process to run together.
The paper is available at her
The paper is available at here. Basically the claimed exploit is to starve the OpenSSH process of accesses to cache lines to get information of what cache lines get used. However, the paper makes a lot of assumptions which if exist can be exploited in other ways. One assumption made is that you can accurately measure the time taken when the other thread is executing specific sections of code. The author does not mention that there is a way to do this.
The section of code published uses the "rdtsc" instruction to measure time. The Intel Architecture spec clearly states that RDTSC is a non serializing instruction. This means that the time stamp returned can be a speculative one - one from before the cache access completed. Even if a serializing instruction were used before this; there is no specific way to ensure that this thread which is competing for the same resources with the OpenSSH process ensures that it gets them in a particular order. For example the 'long integer multiplication' instructions that the author refers needs to compete for the same ALU as that used by the OpenSSH algorithm. There is no suggestion in the paper that would indicate that the process can get this deterministically. If this were possible - there can be other exploits possible as well such as seeing how long do arithmetic operations take - and trying to determine what the other thread did during this time.
AMD64 - Rulezzz :) Intel - S
AMD64 - Rulezzz :)
Intel - Suxxx
Really! Even AMD32 =) If
Really!
Even AMD32 =)
If it's true, Intel gets royal pain-in-the-ass... %)
AMD forever
AMD forever