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

Sysadmins have been advised...

[Anonymous Coward]

to give their hyper-threading processors some Ritalin.

Re:Sysadmins have been advised...

[frankenbox]

Look out for that nasty Y2K bug as well...

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

[Saven Marek]

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?

Well if it happened like that, wouldn't it then mean dual core CPU's are even more so vulnerable?

And there are many of those coming out. I don't think I'll get one now I know what the problems are.

Re:This ought to be interesting

[cluge]

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.

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

[Chris Snook]

Unlike SMP, with HT you're interleaving two threads on the same physical execution unit. That means that there is data from another thread in registers at the same time that you're executing, without having enough instructions execute during a context switch to flush the pipeline. It also means that the other process's page table is in the MMU while you're executing. Even if their proof-of-concept attack doesn't work on some other operating systems, everyone needs to look over their code to make sure this isn't just an accidental effect that could change with increasing pipeline depths, different context switch logic, etc.

Re:This ought to be interesting

[gklyber]

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.

Re:This ought to be interesting

[Breakfast Pants]

It might seem like a good thing, but in reality hyperthreading is marketed primarily towards average desktop users. Their apps are by and large single threaded.

Re:This ought to be interesting

[brsmith4]

Well if it happened like that, wouldn't it then mean dual core CPU's are even more so vulnerable?

How so? Yet another broad sweep of the inference brush. What does HyperThreading have to do with dual cores? By your logic, all of the big SMP systems are also affected by this, which is simply not the case.

Re:This ought to be interesting

[Anonymous Coward]

According to XP Task Manager:

Firefox: 9
Visual Studio: 10
Outlook: 8
Gaim: 2
Explorer: 8

Re:This ought to be interesting

[hostyle]

I've possibly missed something but how does this effect FreeBSD/amd64?

Re:This ought to be interesting

[Taladar]

Intel cloned the amd64 instruction set for their processors so most of the software developed/patched for amd64 is also usable on their 64 bit CPUs.

Re:This ought to be interesting

[CaptnMArk]

Probably because Intel is implementing AMD64 now (they call it EM64T or something like that)

Re:This ought to be interesting

[timster]

Regular desktop apps tend to have lots of threads, but the issue is not how many threads exist but rather how many of them attempt to use CPU at the same time.

For instance, your web browser might spawn a thread to do a DNS lookup, since you wouldn't want the GUI to block during DNS. That thread hardly uses any CPU though. When your Web browser does real work, like rendering, it will usually be confined to a single thread.

Re:This ought to be interesting

[J Isaksson]

Another guess;

since both threads are scheduled on the same functional units, you can just profile how your own (lower priority) thread is scheduled to the units (ie which are busy at each time) and by that calculate which branches/calculations are made by the "main" thread.

This would be _very_ hard to counteract since being scheduled to free functional units is basically a feature of HT, not something you can change really.

Re:This ought to be interesting

[Drakonian]

I just watched his talk, and you are on the right track. Your workaround is one he suggested too. It's actually a timing based attack based on watching the cache misses in a spy thread to try and reverse the RSA public key. The interesting thing is this isn't Hyper-Threading only - it's possible on normal procs too that don't flush the cache between context switches. It's just that with HT context switches can be far more common.

Re:This ought to be interesting

[fitten]

Yes, but each context MUST have its own register set or it makes no sense at all. Perhaps the attack comes through the rename registers or somesuch. Each SMT (or HyperThread) context has its own set of registers and they don't share.

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

[Omnifarious]

Actually, my guess is a bit different. My guess is that it's a timing attack related to the fact that certain resources are being shared by two threads that wouldn't be shared in a dual core or multi-CPU setup. I'm betting you can get a detailed profile of each instruction another thread executes and how long it takes to run if you can get your thread running at the same time.

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.

Re:This ought to be interesting

[Drakonian]

Correction: I meant private key.

Re:This ought to be interesting

[DaKrzyGuy]

I'd guess that the attack has more to do with the shared data caches than with any of the 'core' CPU functionality.

Re:This ought to be interesting

[DaKrzyGuy]

Well if it happened like that, wouldn't it then mean dual core CPU's are even more so vulnerable?

Most dual core systems have at most a shared L2 and not a shared L1 cache. It might still be possible but a lot more difficult trying to do this exploit from L2 caches.

Re:This ought to be interesting

[aka1nas]

The problem with that is that HT mainly helps with multiple threads that use different execution units on the CPU. There is still only one set of execution units on a P4 with HT.

Re:This ought to be interesting

[klossner]

The interesting thing is this isn't Hyper-Threading only - it's possible on normal procs too that don't flush the cache between context switches.

Not really. The scheduler would have to run every few microseconds to let the "spy" process see what the "trojan" process is doing, and the scheduler would have to operate without modifying the L1 cache.

Re:This ought to be interesting

[imgod2u]

It's about shared cache and timing cache hits and misses. One thread can monitor the cache hits and misses of another thread (because access to a cache miss takes more time) and infer how that thread operated. This is as much of a problem on dual-core (with shared cache) as any SMT implementation. As noted in the paper, it's even a problem on normal systems that use paging.

Re:This ought to be interesting

[Drakonian]

Good point, thanks.

Re:This ought to be interesting

[darkain]

AFAIK, with HT enabled CPUs, some sections of the CPU are shared between the two active threads, such as possibly the ICACHE and DCACHE. on a SMP system, you would have seperate CACHE lines for each core. Because of this, you can have one side of the HT CPU encrypting/decrypting data, while the second side of the HT CPU is spying in on said data.

Re:This ought to be interesting

[XO]

but the machine required to actually do this, would be ten times more powerful than the machine that you're trying to steal the key from.

Yeah, ok.

Re:This ought to be interesting

[Chris Snook]

The paper wasn't out when this article was posted, so the parent's speculation was reasonable, and mostly correct.

Anyway, while it's theoretically an issue on paged systems, the time and space granularity there is far too coarse to do something so delicate as capture an RSA key. This attack can resolve to a cache line (64 bits) rather than a page (32768 bits), and doesn't have context switches trashing the timing resolution. Thanks to some insight about how OpenSSL performs RSA operations, this is fine enough resolution to determine individual bits, which probably isn't feasible with a paging attack.

Re:This ought to be interesting

[InvalidError]

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.

Re:This ought to be interesting

[InvalidError]

I would personally spin each flash and other widgets (such as animated GIFs) in their own threads to spare myself the trouble of having centralized coordination of their independant/unrelated refresh requirements.

As an FPGA/VLSI person/engineer, I like parallelism. As a coder, I am a multi-threading freak.

Most coders have a hard time getting used to inherent parallelism... when I taught digital design, the simultaneous nature of gate-level designs caused major mind blocks for many students at least up to half-way through the lab project.

Re:This ought to be interesting

[Omnifarious]

I was close, but not exactly right. I should've thought of the cache. I'm wondering if you could develop an attack based on the shared execution unit though. That would be interesting.

I should've thought of the cache.

Re:This ought to be interesting

[Omnifarious]

I'm still wondering if you could manage an attack based on the shared execution unit.

Side-channel and timing attacks are amusing voodoo to hit people with sometimes. It tells you a lot about how flexible they are in their thinking. I told someone that I thought you could do a keystroke timing attack against ssh, and they told me I was nuts. Then a few months later someone writes a paper on it. I was amused.

Re:This ought to be interesting

[nogginthenog]

I'm guessing it's more to do with reading the other CPUs cache rather than reading its registers.

Whoosh!!!

[EmagGeek]

Shit, did anyone see that blur???

Yeah, I think that was Intel's server market going right out the window at Mach 10...

Re:Whoosh!!!

[paulhar]

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

Re:Whoosh!!!

[CleverNickedName]

Actually, I think it was the article flying overhead.

Re:Whoosh!!!

[EmagGeek]

While a point, I think that a HARDWARE security flaw (that can't simply be patched) that allows something like, I dunno, stealing an RSA KEY, carries a bit more "blunder value" than a javascript security flaw that evades a popup blocker...

Re:Whoosh!!!

[mmkkbb]

Actually, Intel CPUs contain patchable microcode ROMs. You can see the option to enable it when you configure a Linux kernel.

Re:Whoosh!!!

[drsmithy]

I doubt it:

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

1. Most servers aren't multiuser (in the sense he's apparently talking about).

2. The workaround (of disabling HT) is trivial and won't have a significant impact for the majority of environment (proportionally very few servers are CPU bound).

Re:Whoosh!!!

[Anonymous Coward]

But since Intel has not yet responded to this, it's unknown whether the problem can be fixed that way. We'll just have to see after the official annnouncement.

Re:Whoosh!!!

[julesh]

This sounds to me like a flaw with the entire concept of hyperthreading -- I don't think a microcode patch could solve this.

Quick fix

[Junior J. Junior III]

I am counteracting the harmful effects of hyperthreading by eating a high-fiber diet. So far, I haven't had any problems.

Think!

[dybdahl]

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.

Re:Think!

[cahiha]

More importantly, there are few multiuser systems around where this would matter much anymore. An exploit of this requires being able to execute arbitrary code on the machine handling the data. Almost anything that handles sensitive data is firewalled and allows only admin logins and specific services.

Re:Think!

[Slack3r78]

I wouldn't be as worried about the best hackers in the world hitting my box as the best hackers in the world writing an app that every script kiddie in the world could use to attack my box.

Re:Think!

[Gyorg_Lavode]

Actually, I would say there are no computer secure against the best hackers around.

Re:Think!

[emidln]

My home computer has been secure for the last couple days. Not turned on or anything. ;)

Re:Think!

[CyberDruid]

The best hackers around break into your house while you sleep and turn it on.

Then they put spider eggs in your bed.

Re:Think!

[mattyrobinson69]

50 j00 m33n a11 1 n33d 2 b3c0me 5up3r-d00p3r l337 15 4 b453b411 b4t?!!!!!111!!!!one

how the hell do people talk like that without thinking, hmm, what's an A again?

for those who cant be bothered parsing that:

so you mean all i need to become super-duper 'leet' is a baseball bat?

Re:Think!

[m50d]

Dude, it's an exploit that allows taking crypto keys. It could quite well work for ssh. In which case, it's the perfect way to do privilidge escalation once you have a nonprivilidged account. The savannah compromise could have been done using exactly this method. (it was a kernel privilige escalation used instead)

Re:Think!

[cahiha]

Dude, it only lets you "take crypto keys" if you can execute arbitrary code. Yes, multiuser shell accounts are the most vulnerable, but they are not very secure to begin with.

Re:Think!

[cahiha]

This threatens SSL keys on shared web hosting servers. Great, that's only a few million people....

Few people who have SSL keys that matter serve them from shared web hosting servers with shell accounts and the ability to upload and execute arbitrary binaries. And that's pretty much what you need to take advantage of this exploit.

You can get your own, dedicated host for little more than a shared web host with shell access; if your SSL key matters to you, go and do that.

Not many details

[moz25]

Too bad there aren't any details, only an announcement for... tomorrow. I'd like to know how inherent this issue is in the CPU and to which extent the OS can be made to protect against it. Also, assuming he contacted Intel about it.. are they working on it?

I do have to say it's commendable that he spent 3 months on this for free. Now that's commitment :-)

Re:Not many details

[Dtyst]

And he is unemployed! Maybe Intel should hire this guy to do some security audit before their new CPUs hit them market? oh well, no intel CPUs in the enviroments I maintain, so I'm safe... :)

Re:Not many details

[geoff313]

I'm not sure which time zone you are in, but here in EST (the time zone where the conference is taking place) his presentation is starting in 1 hour and 45 minutes. Your details I would imagine will come sometime after that (when he is done). Happy friday the 13th!!! -geoff313

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.

Re:Not many details

[cahiha]

one would basically have to make sure that the other virtual CPU is idle before entering ring 0 at any system call

Probably not. For example, under UNIX, the bug changes nothing for two threads within the same program, or for two threads under the same uids. On systems with messy and unnecessarily complex privilege systems (like Windows), all bets are off, however.

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

If people care about HT at all...

Re:Not many details

[lukewarmfusion]

Wow. I had to read Slashdot to find out it was Friday the 13th today.

*sigh*

Re:Not many details

[J.R. Random]

I don't know what you mean by "not many details". The 12 page paper he links to describes how to use timing of L2 cache missing to determine what numbers Open SSL is multiplying. Overall, it's a pretty impressive demonstration of just how hard it is to cover all security holes.

All that speed....

[solafide]

just going straight to giving up all your private info. Thought this was a step forward. Now that I can open 25 windows of Macromeda products at one time, I find out that my key has gone to some random guy. Better go back to the slow old days.

Where's the details?

[tulimulta]

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.

Re:Where's the details?

[Anthony]

Maybe there are still unsold tickets for BSDCan05.

Re:Where's the details?

[hotdiggitydawg]

Come now... Google, Apple, et. al. all get Slashdotted for the most inconsequential stories, devoid of details. Why should the little guys miss out on some "Google Founder's cat stuck up tree again" Slashvertising?

Re:Where's the details?

[rpozz]

Apparently, he's also known about it for 6-7 months, which also make it smell of BS. 'Discoveries' worked on in secret for that amount of time almost always turn out to be a load of shit.

However, we will see.

Re:Where's the details?

[Threni]

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

Or before. What difference does it make. Now you're aware that some info will be released soon. Is announcing a new version of Firefox a `publicity stunt` too? This guy has a pretty good track record by all accounts.

Once again I'm amused by all the "If I were as smart as him, I'd have done this" style comments.

Re:Where's the details?

[archen]

I'm not sure what is really involved by this, but a FreeBSD security bulletin was released today addressing this topic (including a kernel patch and work-around) so I highly doubt this is simply a stunt.

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.

Re:Where's the details?

[rpozz]

That wasn't the point I was making, but never mind. I'd have thought he might have mentioned warning Intel, because if he didn't it makes him incredibly irresponsible.

Anyway, if you saw the talk, would you mind telling us what the vulnerability is?

Re:Where's the details?

[Drakonian]

Sure. It's a timing based attack on based on watching cache misses. If you have a Spy thread running on an HT processor that is also running OpenSSL for example, you can get a picture of the frequency of cache usage and from that reverse engineer the exponents and multipliers used in the RSA exponentiation. Note: You'd definitely need some cryptographic experience for this. From this, you can get about 310 bits of the 512 bit exponent and brute force the rest, which can be done in polynomial time.

The reason HT is vulnerable is because both threads share the cache and context switches can happen at any time. It could on normal non-HT procs too but the context swithces are more likely to flush the cache or not happen as often.

Re:Where's the details?

[rpozz]

OK, after Drakonian kindly explained what the problem was, I take that back.

However, given the amount of garbage found on the Internet, and that details in the article were rather limited, it was likely that it could be another hoax. Ironic that an AC is critisizing me for using a handle.

Re:Where's the details?

[cjmnews]

He posted them on his site a bit ago http://www.daemonology.net/papers/htt.pdf (Warning PDF)

Re:Where's the details?

[Frank T. Lofaro Jr.]

Their only solution is disabling Hyper Threading.

Heck, cutting the power eliminates all securiy holes too.

How about just not allow different UIDs on the core at the same time?

Processes aren't really expected to be safe from those of the same user (gdb can attach to them anyway, etc).

Re:Where's the details?

[cperciva]

How about just not allow different UIDs on the core at the same time?

That would be the ideal solution (assuming that you also check for setuid/setgid programs). Unfortunately, it's really hard to do that correctly due to problems of kernel data locking.

FreeBSD's policy on security fixes is that they must never ever break anything -- so if necessary (as in this case) a simple but suboptimal fix will be used instead of a complicated fix which might have the inadvertent side-effect of causing machines to crash.

Re:Where's the details?

[m50d]

Another bombshell hit the beleagured BSDCon community as a netcraft survey puts it below 1% of attended conventions. BSDCon has lost yet more marketshare, with unsold tickets running into the hundreds. The future looks bleak for BSDCon. In fact there is no future because BSDCon is dying. Bah, I can't be bothered anymore.

Re:Where's the details?

[shutdown -p now]

"Google Founder's cat stuck up tree again"

URL??? I couldn't find it on Googledot...

Re:Where's the details?

[Frank T. Lofaro Jr.]

Making sure security fixes don't break anything is good - I agree - no excuse to not install it.

They should release an optional update that keeps one secure and gets back some performance even if it risks breakage.

So everyone is secure, and those that want some performance back can get it.

As for setuid and setgid, don't allow 2 processes on the core unless all of the uids/gids match.

Restrictive yes, but likely a good compromise.

I also like what someone else suggested: Only allow 2 processes to share a core if they are allowed to debug each other. That reuses security infrastructure quite nicely,

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?

Re:How to exploit

[mikael]

The Ars Technica page on hyperthreading with the Xeon might provide some clues. It lists which parts of the CPU are replicated, partitioned and shared.

One final bit of information that should be included in a discussion of partitioned resources is the fact that when the Xeon is executing only one thread, all of its partitioned resources can be combined so that the single thread can use them for maximum performance. When the Xeon is operating in single-threaded mode, the dynamically partitioned queues stop enforcing any limits on the number of entries that can belong to one thread, and the statically partitioned queues stop enforcing their boundaries as well.

...

The same can be said for the register file, another crucial shared resource. The Xeon's 128 microarchitectural general purpose registers (GPRs) and 128 microarchitectural floating-point registers (FPRs) have no idea that the data they're holding belongs to more than one thread--it's all just data to them, and they, like the execution units, remain unchanged from previous iterations of the Xeon core.

For a simultaneously multithreaded processor, the cache coherency problems associated with SMP all but disappear. Both logical processors on an SMT system share the same caches as well as the data in those caches. So if a thread from logical processor 0 wants to read some data that's cached by logical processor 1, it can grab that data directly from the cache without having to snoop another cache located some distance away in order to ensure that it has the most current copy.

...

You might think since the Xeon's two logical processors share a single cache, this means that the cache size is effectively halved for each logical processor. If you thought this, though, you'd be wrong: it's both much better and much worse. Let me explain.

Each of the Xeon's caches--the trace cache, L1, L2, and L3--is SMT-unaware, and each treats all loads and stores the same regardless of which logical processor issued the request. So none of the caches know the difference between one logical processor and another, or between code from one thread or another.

Re:How to exploit

[Anonymous Coward]

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.

more info at KernelTrap

[Anonymous Coward]

I read about this last night here at KernelTrap. They offer more info, evidently having talked to Colin...

Re:more info at KernelTrap

[owlstead]

From the article:

"The flaw affects all operating systems, and for a secure multi-user environment essentially requires that Hyper-Threading be disabled." /speculation mode on
Seems that this is pretty big. Since I cannot see the direct link between multi-user and hyperthreading, I must assume that processes may be able to read data from other processes. Let's hope they cannot change the data as well. I think it's pretty weird that he mentions RSA specifically, maybe thats a hint which part of the processor is affected. /speculation mode off

Re:more info at KernelTrap

[viega]

My guess is that this is going to be an application of a known (recent) result from djb, that hyperthreading can introduce some serious vectors for timing attacks. See this paper.

/. premature?

[feenberg]

Wouldn't it have made more sense for /. to wait a couple of hours before posting this? At least then there would the remote possibility that responses would be made after RTFA!

Re:/. premature?

[Spacejock]

There's only a remote possibility people will RTFA when it DOES exist. To calculate the possibility you're talking about will require hours of CPU time. Actualy, hours * ~1.5 CPU time, because for some strange reason my HT is now disabled.

This is SERIOUS!!!

[AltGrendel]

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.

Ooooo, I'm SCARED!

hmm..

[ebilhoax]

I will be presenting this attack at BSDCan 2005 at 10:00 AM EDT on May [Friday] 13th ...

Jason? Is that you? (or your evil geeky twin brother?)

Simple Solution

[JerkyBoy]

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?

Re:Simple Solution

[twohorse]

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?

To allow time for people to hear that theres a problem, and probably to allow a fix (apart from switching off HT) to be developed before exploits are out.

Re:Simple Solution

[macdaddy]

Isn't there a kernel arguement that can be dropped in via grub, lilo, or silo to disable hyperthreading?

Re:Simple Solution

[digitalchinky]

Yeah, but then you only get ONE penguin when the kernel boots up...

Encryption keys multiple penguins

Hmmm, tough choice.

Re:Simple Solution

[PDAllen]

You have to wait because this guy would like to at least give people a little while to patch the problem, before standing up and telling the world and all its skript-kiddiez how to exploit it?

if you want a guess - either via Sniffer Thread A can read registers used by Crypto Thread B running on the virtual second processor, or the branch predictor doesn't clear fully and can be made to disgorge its contents to thread A.

Re:Simple Solution

[Senjutsu]

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?

You don't. He's giving people a heads up, and some lead time to secure their systems by doing exactly what you describe, before he gives a presentation on the flaw, which will inevitably lead to some malicious jackass building an exploit out of it.

Re:Simple Solution

[m50d]

So that people have time to do that (disable hyperthreading) before it starts getting exploited.

Re:Simple Solution

[shutdown -p now]

Why do I have to wait until this guy does his conference presentation to find out what the exploit is, how it is implemented?

So you can now turn off HT and secure your box, but some blackhat cannot write an exploit meanwhile (without knowing all the details).

Is this a hyperthreading problem or..

[FidelCatsro]

is it a problem with the kernels use of it , that artical is rather vauge on the details. I have a xeon server running linux and will consider disabling the use of hyper threading for now ,but i cant justify doing that on the long term till more info is at hand.
if anyone has any more info on this i would be glad to hear it .

Re:Is this a hyperthreading problem or..

[Jondaley]

Ah, you are correct, AC.
The marketing language of "look like two processors" sounds fishy to me, but I have read a little more, and that it can actually execute instructions concurrently.

I still don't think it is as obvious as you imply, since there is overhead and contention when competing for the same processor resources. So, I suppose it depends on the types of processes/instructions that you normally run. It is worth further looking into, I do concede.

Re:Is this a hyperthreading problem or..

[imp]

The problem, as has been noted, is if you have users that you have secrets you want to keep from. If you do, and you use OpenSSL or any other crypto library that has asymetric cache properties of the 0 bits vs 1 bits, then you should disable HTT.

OpenSSL is reported to be working on a patch that fixes the issues that are raised by this work. It is unknown what other classes of code might be affected.

There's much discussion about other, similar things that one can do with shared cache and speculation about how other cache effects can leak information, so the full impact of this class of attach won't be known for some time.

Re:Is this a hyperthreading problem or..

[FidelCatsro]

Well its not connect to an outside line so it should be ok, and im fairly sure i can trust everyone here , but better safe than sorry as i do use OpenSSl . cheers

I was thinking of replacing it with an xserve anyway , suppose this will atleast give me something to present to the PHB that can eassily be blown out of proportion and push for that lovely new server i have had my eye on ;)

May I be first to say...

[game kid]

...I'm glad I'm stuck with a 1-gig Pentium III.

Re:May I be first to say...

[GregoryKJohnson]

Actually, it's substantially harder to type "GHz", because on a QWERTY keyboard it involves awkward pinky dancing, by which I mean a left-hand stretch to effect "G", continued left-pinky application to effect "H", and then a high-latency switch to "z" (since the left pinky must release Shift and hit "z", which involves round-trip latency with a weak finger).

By contrast, "gig" involves no shifting, no left hand switching between keys, and works in full duplex: you can begin to hit "i" while still releasing "g" and begin to hit "g" while still releasing "i". Moreover, "gig" rolls of one's congitive tongue better.

Power users such as myself realize this, and you would be well advised to refrain from commenting on matters about which you obviously have only a developer's inadequate understanding.

Re:May I be first to say...

[ignorant_coward]

It was a model made on a very early process. It's 1 gigagram.

Re:May I be first to say...

[Quattro Vezina]

That all depends on how you're typing in the first place.

I have no problems typing GHz. I hold the Shift key with my left pinky, hit 'G' with my left index finger, hit 'H' with my right index finger, let go of Shift, and press 'z' with my left index finger. The only time I make any sort of flub while typing GHz is when I either let go of Shift too soon or hold it down too long.

If you have problems typing GHz, you should really reconsider how you type.

Re:May I be first to say...

[GregoryKJohnson]

I've got a Microsoft Natural keyboard that places H about three inches from G, so reaching it with my left hand would be rather inconvenient.

Re:May I be first to say...

[GregoryKJohnson]

Yeah. To type fast, you've gotta be activating the muscles that press the next key before you've fully released the current key. That's why it's faster to type "this"---which alternates fingers, and even hands---than "fred". (Try it: I bet you can type "this" in about the time it takes to type "fr".) I guess "full duplex" isn't quite the right concept, though. Maybe I meant something more like "DDR": you can type on the way up and on the way down. (BTW, I hope everyone realizes that my original post was being facetious: any difference in convenience would of course be tiny.)

Re:May I be first to say...

[toddestan]

Power users such as myself realize this

Ha! The true power users have a Dvorak keyboard! Though I must admit, the z key is still a bit of a pain. But I can easily nail the G and H keys with my right pointing finger.

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

You know you haven't slept enough when...

[TwentyTwo]

... you read that Hyperspace is considered harmful. I exepected TFA to be about gamma rays and aliens ... how disappointing :/

Extreme Edition...

[Sialagogue]

With Moore's Law still holding up, isn't it a little early to be using up names like "Extreme Edition?" So, I'd like to propose my own corollary to Moore's Law:

"The microprocessor industry will run out of hyperbole long before they run out of transistors."

Re:Extreme Edition...

[grouse]

Am I the only one that noticed that the natural acronym for Intel Pentium Extreme Edition is "I PEE?"

Re:Extreme Edition...

[ignorant_coward]

That's why new PCs come with those absorbant pads for your desk.

Re:Extreme Edition...

[KlomDark]

And they are really good for a C/RAP (Challenge/Response Authentication Protocol) too.

Re:Extreme Edition...

[hawk]

So there is an appropriate platform for WinCE after all . . .

:)

hawk

SCO....

[wpiman]

He alerted SCO to a flaw in their OS?

Traitor!!

Amazing- first time a major security violation doesn't have Microsoft all over it.

Re:SCO....

[MavEtJu]

He alerted SCO to a flaw in their OS?

cperciva told me he had contacted a lot of companies and OS distributions, but that there were only a few (four in this case) who replied to him about it.

Re:SCO....

[Petersson]

Well its not first Intel bug, few years before F00F bug happened on Pentium and Pentium MMX processors, which caused CPU to lock completely even from lowest user level allowed to run code.

Re:SCO....

[Wybaar]

Let's not forget the FDIV bug. Here's another article that discusses the details of that problem.

Re:SCO....

[cperciva]

He alerted SCO to a flaw in their OS?

Actually, I posted to vendor-sec. I was rather surprised when I got an email back from SCO -- I didn't think that they'd be on vendor-sec.

Re:SCO....

[Creepy Crawler]

Yep, just crank a debugger and run 0xfoofc7c8

Ouch.

Re:SCO....

[Fenris Ulf]

You could also type in a FOOF.COM file from the command line, and execute it.

COPY CON foof.com
[alt-240][alt-015][alt-199][alt-200]
^Z
C:\> foof.com

[machine hangs]

I smell a big recall

[hydroxy]

Remember when the 600mhz (right speed?) Xeon's had a very very small problem that had a like 1% chance of causing the system to crash? (kinda vague I know...) All those owners had the option of getting 850mhz Xeon's in exchange. (250mhz was a big deal back then). Maybe you should go pickup one of the chips and hope the company does something similar w/ this problem.

Re:I smell a big recall

[swv3752]

Nope, it will be turn off HT in the bios.

Re:I smell a big recall

[TeknoHog]

All those owners had the option of getting 850mhz Xeon's in exchange. (250mhz was a big deal back then).

42 % improvement is a big deal any time.

No details, I'll just wait

[ilithiiri]

'till 15:00 UTC today for the _full_ disclosure.
Before the full disclosure, can't say anything..

It is just an 'give me a job' attention grab

[nietsch]

the guy starts of with an Q&A even before he explains how it can be done, or what caused the flaw.

question 4 in his list:

Where do you work?

I'm unemployed. For the past three months, I've spent almost all of my time working on this security flaw -- investigating how serious it was, contacting all of the affected vendors, explaining how this should be fixed, et cetera. I simply haven't had time to go out and get a job -- and I decided that making sure that this issue was properly reported and fixed was far more important than earning some money.

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

Re:It is just an 'give me a job' attention grab

[Intrigued]

I don't see that.

If he can produce even a moderately effective proof-of-concept exploit (which apparently he has), someone with a little malicious creativity will find out a way to abuse it.

Also as a security professional, any gap, niche or irregularity in core security processes needs to be taken seriously even if nothing ever pans out in a real exploit.

As far as the attention grab, I don't begrudge the guy at all. If the exploit is bogus, he will have advertised to the world "I'm an idiot - don't hire me!". If it is valid, he has shown his worth and deserves some support.

Re:It is just an 'give me a job' attention grab

[kz45]

Where do you work?

I'm unemployed. For the past three months, I've spent almost all of my time working on this security flaw -- investigating how serious it was, contacting all of the affected vendors, explaining how this should be fixed, et cetera. I simply haven't had time to go out and get a job -- and I decided that making sure that this issue was properly reported and fixed was far more important than earning some money.

I think he might be mentioning this first because he's hoping a potential employer will be reading his website.

Google Adbar

[bLanark]

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

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

And I note that if you are a SCO user, you always had disabled hyper threading anyway. Not sure what to make of that.

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

Oh dear.

[Morky]

I guess I need to shut off hyperthreading on our app server before the users who can't sort an Excel spreadsheet have a chance to expliot the vulnerability.

Disregard Above Post

[geoff313]

Please disregard the above post, I read EST when the paper is in EDT. I am eagerly awaiting this paper though.

*shouldn't post to slashdot this early in the morning*

Re:Disregard Above Post

[Mold]

EDT is basically EST.

Eastern Daylight Time (UCT -4)

http://www.timeanddate.com/library/abbreviations/t imezones/na/edt.html

Re:Disregard Above Post

[operagost]

Well, eastern Indiana doesn't use daylight savings time, so they use EST all year. They're one hour behind everyone ELSE in the eastern time zone.

Access to CPU/memory Calls

[tronicum]

The point is that most servers system don't allow you to execute system calls which you could exploit.

You need at least root/administrator privileges to get stuff from the OS memory.

So before you can exploit the system you must have access to the system it self.

It is an "local" kind of "root exploit" if you can read from the system memory of other processes if the claim is true.

Uhoh..

[ceeam]

If true that should eclipse for good the DivBug of lore. Can't wait for exploits to appear. But then - brainwashed people buying PIV Intels will get whatever they deserve. [grin]

Re:Uhoh..

[Marthisdil]

But then - brainwashed people buying PIV Intels will get whatever they deserve

sigh - yet another one.....

Re:I know it's Off Topic but

[Quantum Skyline]

Select Windows. Then press F8.

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

[epine]

This is most likely the case, that it is a timing attack. In an OOO design one can gain a lot of information about which instructions schedule in what order based on the availability of different execution units. An early-out divider is especially vulnerable to leak data about input arguments in timing effects. I've forgotten most of the math I once knew about RSA. If the modulus computation involves the use of the hardware divider (not just the bit shifter), you could leak a lot of information about key bits in a big hurry.

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

[Scott Laird]

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.

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.

Re:Probably a Timing-Based Attack

[AtrN]

This got mentioned in comp.arch and Dan Bernstein pointed out others have mentioned similar things previously. The abstract mentioned reads,

Other People's Cache - HyperAttacks with HyperThreading - Dag Arne Osvik, Norway

We have investigated the use of memory caches of modern processors as side-channels for timing attacks against software implementations of cryptographic algorithms. In particular, we have successfully performed a new kind of attack where the attacker has no privileges other than being able to run on the same processor as the victim. That is, the attacker has no access to plaintext or ciphertext, and is not allowed by the operating system to communicate with the victim. In this scenario we have recovered 45 out of 128 key bits from AES encryption of English text in just one minute on an Intel processor with HyperThreading. Moreover, with regular known plaintext attacks we have achieved full key recovery.

Re:Probably a Timing-Based Attack

[iabervon]

This is not the case (and it would be difficult for a security flaw of this sort to escape notice, because if there was some way of getting values out of the cache that aren't in your address space, it would happen all the time accidentally).

It turns out to be based on figuring out how much of your cache has been invalidated, which corresponds to how much memory the other process has used, which, for OpenSSL, is different depending on whether it used a multiply or a sqaure, which depends on bits in the private key it is using.

It is essentially similar to the power analysis attacks on smartcards, except with memory usage instead of power consumption.

Re:Probably a Timing-Based Attack

[m50d]

I think it's using the registers, which would make it a lot quicker. If the cpu hasn't reached another execution unit, they might not have been flushed from logical cpu 0, so a thread on logical cpu 1 can read them.

Re:Probably a Timing-Based Attack

[Scott Laird]

Yeah, but that'd be a visible CPU bug, and it wouldn't have made it past Intel's validation in the first place.

In other news..

[peterprior]

...it appears Windows XP Starter Edition may be the most secure option after all...

Re:In other news..

[marat]

Guess how Longhorn will make malicious software that gets onto computers without the users' knowledge 'a thing of the past'? You know it's very hard not to notice that something running in parallel on 286.

No details given...

[nietsch]

So he has gathered a few advisories (without details) and promises to release a whopping 12 page report after this ueber important conference?

I am presenting details of how to exploit this security flaw at BSDCan 2005 in Ottawa on May 13th, 2005. Following my talk, I will be releasing a 12-page paper on this website discussing this flaw and related problems, both realized and theoretical.

granted there is nothing wrong with this guys ability in marketing. As as techie this creates two reactions in me:

1. Get that f*ing market droid out of my news
2. Show me the code

Re:No details given...

[Ed Avis]

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.

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.

Re:stupid paranoid people

[varmittang]

Yeah, true that this maybe over kill for normal users since a virus or trojan wont be able to exploit this and infect the masses. But the US government has been known to use more Intel hardware than AMD or PPC hardware. So it does pose a possible security risk for those people that do have highly sensitive stuff being processed on Intel hardware.

Re:stupid paranoid people

[psbrogna]

I'm not sure I follow your logic.

"Lets face it, a trojan, worm or whatever isn't going to use this obscure method"

Why not?!

"And why would someone target your PC unless you had some really valuable information. They wouldn't."

Some significant % of the millions of potentially vulnerable PC's out there do have really valuable information on them...

Re:stupid paranoid people

[Anonymous Coward]

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.

Re:stupid paranoid people

[wtarreau]

It's not about your cheap PC, nobody cares about it. It's that there are companies which rely on high-performance servers for data bases/proxies/caches/directories, etc... on which it would become a real problem if an intruder could steal certain information such as private SSL keys. Moreover, a campus administrator not necessarily want his students being able to steal his root password.

Again, every inter-process vulnerability don't affect your windows PC you start up to read your mail and browse the net. You can go back to your porn sites, dad won't know.

Article in a nutshell

[john_anderson_ii]

Hyperthreading is teh suck because I found a flaw.

I'm not going to tell you how it works until I get a chance to stand up in front of a buch of people and sound smart. In the meantime you can disable HT.

I can write.

The flaw affects BSD's and OpenServer for sure.

I'm unemployed, so give me money to find more flaws.

Intel rocks!

Yup...that's pretty much it. Or did I miss something?

Re:Article in a nutshell

[zalas]

"I found a flaw in Hyperthreading, but the margin of this notebook is too small for me to write what it actually is, so I'll leave it as an exercise to the reader."

Re:Article in a nutshell

[huge colin]

On a system where security is very important, it doesn't matter if HyperThreading cures cancer and freshens your breath while you sleep -- if there's a security problem, you can't use it.

opportunity to get paid for his volunteer work

[dpilot]

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.

Re:opportunity to get paid for his volunteer work

[Threni]

> he's a better risk for a job offer than a reformed black-hat.

Presumably if he doesn't tell you he's an ex-black-hat, or if he never got caught, then you wouldn't know?

Re:opportunity to get paid for his volunteer work

[dpilot]

touche'

But it sounds like he's a BSD developer, so that establishes some background, (less likely to be just a black-hat) and I suspect this HT thing will establish some name recognition. In his shoes, I'd hope to parley this into a job offer.

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:Same Guy?

[merdaccia]

Your post made Firefox crash. Please close your tags.

hohum

[BigBadBus]

Don't you think you're carrying this Friday 13th theme a bit too far?

Too Scary ! Not !

[drhodus]

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

Re:Reminds me of a bug in Michigan Terminal Servic

[Gothmolly]

Are you talking about Connect?

God, memories dialing into the NIM, getting the 'Call cleared...' message every night when it kicked everyone off, spamming 'acm acm acm acm' at the prompt so you could get back on before anyone else... the good old days.

On the other hand

[MountainMan101]

I'd be willing to bet he's right. He is currently awaiting a doctorate from the University of Oxford, which is commonly held as the finest academic institution in the world.

(I'm not biased by having spent the past 7 years there)

Re:On the other hand

[stephentyrone]

nah, not really:
http://ed.sjtu.edu.cn/rank/2004/top500(1-100).htm

even the british don't think so:
http://www.thes.co.uk/statistics/

is oxford very, very good? yes. i'm visiting now, and it's a great place to be. commonly held to be the finest in the world? that's a stretch.

Re:On the other hand

[BigBadBus]

...and even a few years ago, even York University beat Oxford.

Of course I'm not biased by having a DPhil (PhD to you and me) from the place.

Re:On the other hand

[babbage]

And this isn't the first time he has come up with some interesting research that has been mentioned on Slashdot before. Sure, he seems to be a little arrogant, but with his record so far, I think he's earned the benefit of the doubt here...

Re:On the other hand

[IdleTime]

Thank you for the list. Nice to see I'm educated at one of the worlds top 100 uni's...

Re:On the other hand

[Drakonian]

This guy is a smart cookie. I just saw his talk. He doesn't come across as arrogant at all. I think his exploit is plausible. It's a timing attack but could allow you to discover a 1024-bit private key in under 5 mins or so if you know what you are doing.

Re:On the other hand

[aftk2]

Tommy: "A lot of people go to college for seven years..."
Richard: "Yeah. They're called doctors."

Re:On the other hand

[EWIPlayer]

"I graduated from the best university in the world! Now I'll put that prestigious degree to good use by reading slashdot all day..." It's good to know that the best universities aren't always turning out the best grads :)

Single Chip Multi Core

[hackus]

Anyone working on MultiCore CPU's on a single chip yet?

Is there a way to access registers on one core directly from another without a supervisor bit requirements?

Vector based systems I have been familair with use a sharded memory context exception handler for that sort of thing.

I think multicore CPU instruction sets are going to be interesting to look at as soon as I get my hands on one.

One more 4U chassis to add to the rack of equipment in my living room. :-)

-hack

Simplest Solution

[Loualbano2]

Most machines let you disable it in the BIOS, which would have to be the simplest way of turning it off possible.

You can't win for losing

[FreeUser]

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.

Re:Three months huh

[ignorant_coward]

If he gets it, that means he found a job in three months technically without looking for a job. Not a bad strategy for people who can pull it off (but people like this tend to _not_ be unemployed, unless they got hit by a beancounter somewhere).

Re:Another hit for Intel

[Anonymous Coward]

But wait, a security issue that doesn't affect Microsoft? The sky is falling...

HT Explot PATCH:MST-00013

[fishpick]

Microsoft has issued a patch in response to this "significant" security threat
You can download RIDDILIN.EXE to address the hyper-thread exploit from their update site...
Bill Gates assures me in a very personal email, installing this patch will fix the flaw, send me $5 for every other person who installs it... and Intel's stock will go up too. It's win-win...
Everyone should do it...

SCO Unix variants...

[Per Abrahamsen]

As we all know, this includes Linux :-)

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

Re:Timeline - WTH?

[cperciva]

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

They were. I've clarified the page somewhat now, but "Other security teams" includes Intel.

Re:Timeline - WTH?

[quantum bit]

Free binary security updates for FreeBSD [daemonology.net]

Aha! You're the FreeBSD-Update guy. I thought the name sounded familiar. (mailing list junkie that I am)

Definitely an interesting topic. Reading the paper now -- I would never have guessed you could get enough timing information (or enough resolution) to recover that much of an encryption key...

I've always said hyperthreading was bad news for performance, guess it's bad for security too :p

Re:Timeline - WTH?

[quantum bit]

Aha! You're the FreeBSD-Update guy. ...and porting makefs too. Heh, I use that in my soekris build scripts ;)

Re:Timeline - WTH?

[shutdown -p now]

Why pre-announce a vulnerability?

To give you time to secure your servers.

hooray !

[maharg]

I have 2 Dell 6650s, loaded with 4 HT Xeons and 32Gb RAM each. However, I had to disable HT on them as the license for the application I'm running allows 8 cpus only; when it detected "16" cpus across the 2 servers, it refused to start. So this news actually makes me feel better about the fact that `top` only shows 4 cpus on each box :o)

Re:hooray !

[Creepy Crawler]

Yeah, Oracle sucks, dont it?

Re:hooray !

[maharg]

Verity K2 actually. But yes.

Bah... my ancient Sparc II scoffs at x86

[HighOrbit]

[humor]
What is this x86 hyperthreading that you speak of fearing? My venerable (read:ancient) 64-bit Sparc II scoffs at your toy x86. Ofcourse, the aforementioned Sparc is only 1/2 the speed of your P3, but it stills scoffs.
[/humor]

Seriously, the SPARC architecture is an open specification that, unfortunately, does not get enough respect. It has been 64-bit since almost forever, something that is only now becoming common in the x86 world. I noticed that the flaws were noted on SCO-ware running on x86. I wonder what other Unix/unix-like varients are affected. IIRC, Sun claims that their x86 and Sparc code base are a single tree. I wonder if the fix for all the affected OSes will required scads of architecture unique kernel hacking versus keeping a single tree.

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:Security is a real-time embedded application

[jmorris42]

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

Dude. Do you realize just how many SSL certs are running on servers at hosting companies that are virtualized and shared between unrelated customers? Want to make a guess how many are Intel CPUs vulnerable to an attack like this? So yea, you might not need to worry, I only need to worry a tiny bit, but for some people this is going to be a major annoyance.

Re: On the gripping hand

[Jacob Martin]

I'm a graduate of the University of Cambridge, which is *even more* commonly regarded as being the finest academic institution in the world. (It regularly tops the league tables here in the UK). Those guys and gals from the other place aren't a patch on us Tabs, especially in the sciences.

Re:Article summary

[TrappedByMyself]

"I discovered a security flaw, details to follow, please give me money"

Absolutely...

[Kjella]

...RSA is vunerable to timing attacks (why we have blinding in software). It's a wonder noone has thought about this earlier though, I remember reading about the military considering virtual machines (i.e. one physical machine could be on both classified/unclassified systems). One of the reasons they didn't was the ability to tap/signal through spinlocks and other timing data. I always thought this was a "well-known but too unlikely to be interesting" weakness, but I guess not. Maybe I should have published a paper myself.

Same user

[nnappe]

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.
Perhaps even better: processes[threads] belonging to the same user

Re: On the gripping hand

[MountainMan101]

That's a joke. Fenland Polytechnic (aka Cambridge Uni) doesn't even offer a proper science course. They have Natural Sciences - designed to ensure that after 3-4 years you STILL have no specific knowledge and are only fit for PhD at a crappier university or a job in the city.

Tabs! Those who don't know their arse from the elbow.

Re: On the gripping hand

[zootm]

I'd make the case for Edinburgh, but it only beats other places in certain specialist areas, and this pissing contest has gone too far anyway!

Hyperthreading performance with numerical models

[Orp]

This is only tangentially related to the security issue, but I found that disabling hyperthreading on a cluster of dual Xeons running Linux greatly improved performance with a distributed memory (MPI) numerical model. Short summary: even if you only run your model on physical CPUs, hyperthreading will apparently bounce jobs around in a somewhat random way. Not sure if it's a hardware issue or a software (Linux) issue.

Here is a link which goes into detail

gdi i'm starting to hate computers...

[cryptocom]

i'm goin back to a notepad and a playstation...all i need is the original Descent, Gran Turismo 2, and Metal Gear Solid and I'll be happy for the rest of my existence.

Does this effect travel...

[Gilmoure]

...through the Star Gate?

This better be good

[SenFo]

Cause if it's not, you're gonna look like such a doofass ;-)!

Hard Changes

[Doc Ruby]

That's going to be hard to patch. As more HW becomes untestable for NP-complete problems like security holes, reconfigurability (field reprogrammability) might become a necessary security measure. Of course, that creates another avenue for attack. Intractability is a harsh (multi)taskmaster.

Not quite

[Anonymous Coward]

"which is commonly held as the finest academic institution in the world."

Only in Oxford.

Everywhere else its pretty clear its Cambridge.

HYPErthreading

[SolusSD]

Hmm, slows things down on occasion, opens your system to attack.. its a feature! go figure.

Re:In that case...

[SpinJaunt]

I am glad I am stuck with a Pentium 2 350 MHz :(

Re:So does anyone know...

[hartz]

Only similarity is in the abbreviation.

Re: On the gripping hand

[Lodragandraoidh]

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.

Re:So does anyone know...

[anno1602]

Hyper Transport has nothing to do with Hyper Threading. Hyper Threading means processor support for several (usually two) execution threads at once. Hyper Transport is a bus technology to interconnect pocessors, RAM, motherboard chips, PCI bus and the like.

AMD's Hyper Transport is similar to Intel's Hyper Threading, but in my books, superior.

That's like saying that the computers from Apple Computers are similar but superior to the computers from Apple Records. Notice how Apple Records makes no computers? Just because they start with the same word does not mean two things are the same.

You are very dangerously wrong.

[Anonymous Coward]

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?

Re:So does anyone know...

[Slashcrap]

I'm curious since AMD's Hyper Transport is similar to Intel's Hyper Threading, but in my books, superior.

Hyper Transport is a bus protocol. Hyper Threading is a means of maximising the use of the execution units on a CPU.

The only similarity is that they both start with the same letters. As such, I'm afraid that calling Hyper Transport "superior" makes you sound like a fanboy.

Re:Nah...look for him in a van by the river...

[trixillion]

You're a fool and a troll and I'd hazard that this guy would pass the opportunity to work with someone of your intellect.

I disable it anyway

[doombob]

Hyper Threading Causes me problems anyway.

2 or 3 months before notifying other vendors?

[chrysalis]

December 31, 2004: FreeBSD Security Officer Team notified.
February 27, 2005 - March 18, 2005: Other security teams contacted.

Why notify FreeBSD and then wait 2 or 3 months before notifying other possibly affected vendors (at least other BSDs)?

This is really not a mature attitude.

Re:2 or 3 months before notifying other vendors?

[cperciva]

Why notify FreeBSD and then wait 2 or 3 months before notifying other possibly affected vendors (at least other BSDs)?

Two reasons. First, because I'm part of the FreeBSD Security team -- I'm required to notify them about potential issues.

Second, because if I contacted lots of security teams with what I had on December 31st, they wouldn't have listened: "Umm, hey guys, there's a problem with hyperthreading. I've convinced myself that it is real, but I don't really have any evidence to give you, so you'll just have to believe me..."

Re:2 or 3 months before notifying other vendors?

[chrysalis]

I'm really not convinced that they wouldn't have listened, or that waiting 2 or 3 months helps to have them listen.

Maybe posting your early ideas on crypto-related newsgroups would have helped in order to quickly get a paper about cache timings attacks so that people can protect their servers as soon as possible.

Re:So does anyone know...

[http101]

well, i can certainly blame it on marketing. keeping consumers in a daze without knowing wtf they're getting is kinda pissing me off lately. i see by definition the words are different, but still, i'm only relaying what i've been told as a consumer. frankly, the idea of intel and amd going head to head and constantly "one-upping" each other is stupid. thanks for clearing the confusion up. i'll be sure to keep using my 486 with Hot Tounging technology.

Re:Nah...look for him in a van by the river...

[Anonymous Coward]

He's 23, and he's getting a PhD; I wouldn't call that lack of ambition.

Re: On the gripping hand

[jrumney]

About time you updated your knowledge with a bit of "2 pints of lager and a packet of crisps" and "Teachers".

Paper

[cperciva]

My paper is available here.

Have fun reading, I'm going back to the conference.

Re:Paper

[patchvonbraun]

Read the paper. Yet-another side-channel cryptanalytic attack. Congratulations, you're now in good company with the likes of Paul Kocher and David Wagner. Side-channel attacks are often notoriously difficult to close, and equally hard to find. In order to mount such an attack, however, you need to be able to launch a "spy" program, which in many (but, granted *not all*) cases isn't possible--assuming that your server system is secure against attacks that would allow launching of arbitrary software remotely.

Mirror before the paper gets slashdotted

[An Audience of One]

http://www.cl.cam.ac.uk/~mjj29/htt.pdf

The paper from the talk has now been released, I've mirrored it in case the site gets hit.

Paper is here

[cmpgn]

http://www.daemonology.net/papers/htt.pdf

paper is up

[mzs]

Cache Missing for Fun and Profit

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:Hyperthreading performance with numerical model

[BigZaphod]

In at work, we also disabled hyperthreading on several Linux Java servers with dual Xeons and performance improved pretty dramatically.

This is such BS.

[functor]

The paper describes how he did it -- he's taking advantage of the fact that a processor with HyperThreading allows both threads to use the same cache, and specifically allows one thread's memory accesses to evict the contents of cache lines formerly carrying data accessed by the other thread into memory. (This, by the way, is by design -- HT processors are supposed to allow the thread to share execution resources, including functional execution units and caches, to maximize resource utilization. Cutting the cache in half to be doled out between the threads will make the processor perform more like a Celeron.)

The exploit is performed via prior knowledge of the data structures and algorithms in use by the victim thread. By being able to infer parts of the key from the layout of recent memory accesses performed by the other thread, the attacker is able to recover some of the key. The layout of accesses is inferred by timing memory accesses in a pattern designed to make the cache thrash and figuring out what relative addresses might have changed recently.

To say that this would be a difficult exploit on a multiuser system running many different threads from many different processes would be a great understatement. Under a controlled environment with a thread whose use of data structures and algorithms is known in great detail, it's feasible to pull it off. However, "in the wild" it's likely to be much, much more challenging.

The paper is now available

[Anonymous Coward]

The paper is now available at:
http://www.daemonology.net/papers/htt.pdf

Paper

[YakDaGringo]

Link from KernelTrap

Athlon 64 implements hyperthreading

[tannhaus]

I'm sure we'll have to wait for the final article, but if this is a problem with hyperthreading, does it affect athlon64? He doesn't say that it does, but he doesn't say that it doesn't either. So, I'm wondering if he even TRIED the exploit on an athlon64.

Re:Athlon 64 implements hyperthreading

[DarkHelmet433]

The FreeBSD/amd64 kernel runs on Intel's EM64T cpus which implement hyperthreading.

Re:Athlon 64 implements hyperthreading

[tannhaus]

The dual core athlon 64s have the hyperthreading bit turned on so they can take advantage of some optimizations made for hyperthreading. Does the problem affect them in these "optimizations" or does it just affect intel hyperthreading.

Accurate timing required?

[nick8325]

The attack uses the RDTSC instruction to find out how many clock cycles are taken to perform its operations.

There is a flag on x86 that can disable RDTSC for user-mode code. As far as I can see, it would be much, much harder to do a similar attack without a fairly accurate clock-counting instruction like this.

I'm not sure though - could someone who knows more about these things comment on how fine-grained the timing needs to be to detect cache misses? Can the bits be recovered slowly over a long period of time?

Right

[StarKruzr]

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.

Because, of course, who needs community? People are awful. I'd much rather stay in my mom's basement with my ...For Dummies books and only leave the house to stare in the window of the hot chick next door at 11PM.

Re:Right

[gowen]

People are suspicious, inconsiderate, exciteable, and mostly intolerable.

Hey! You take that back! Some of my best friends are people!

Re:i can hardly contain my excitement

[setantae]

Those words aren't in the research paper.

My take on the paper...

[kenh]

The paper is here http://www.daemonology.net/papers/htt.pdf and I've skimmed it.

My takeaway is that if a process knows another thread is calculating an SSL key, it can get an advantage in figuring out the SSL key.

It won't "get" the actual key, but with sufficient "bits" of info, the calculation can be rendered fairly trivial.

I'm not familiar with these types of security reports, but let me say that to me, it sounds much like saying that with a careful analysis of the LEDs on the front of my IMSAI 8080 my private data may be revealed.

There seems to be so many other things that feed into this vulnerability (like, a minimal number of processes running, knowing the code is being executed, that the thread and the "cracker" software run on different "logical" CPUs at the same time, etc...) that this is a very, very, small issue - damn near purely theoretical.

If the author can say, "Run this code on your server, calculate an SSL key, and this piece of code will reveal your SSL key" then we have a real vulnerability. As I read it, the author is saying "Run this code, calculate an SSL key, and you may be able to infer a percentage of the bits that comprise your SSL key".

I will repeat, I only skimmed the paper, and I'm not familiar with these types of reports, but that is what I walked away with - if I am wrong, I invite the correction.

Re:My take on the paper...

[cryptoguy]

Many systems are idle for some period during the day / week etc. Someone who can gain unprivileged access during that time can "cause" the system to perform an RSA key operation while simultaneously running the spy program. That's exactly what the writer did. For some systems this presents a new threat. For others it's not an issue. If your root password is found in a standard dictionary, you should address that first.

not only numerical...

[fraxinus-tree]

HT is good only when you have 2 different (from CPU point of view) tasks to run, using different core parts - for example, ray-tracing (lot of floating point) and xml parsing (lot of integer / string operations).

Give the CPU 2 similar threads and you are much better with disabled HT

Not sure for the explanation, but performance issues are a matter of fact.

HT needs 1M L2 cache to avoid suckage

[jhantin]

I've tried HT on both the 3.0c [Northwood, 512k L2] and 2.8e [Prescott, 1M L2] P4 models, both with identical hardware otherwise [1Gb dual channel DDR400, 875P chipset, nvidia fx5200, 120Gb 7200RPM ATA133 WD disc]. It's really nice on the 2.8e, but you fall in the cache miss tar pit on the 3.0c. With HT turned on the 2.8e actually feels faster than the 3.0c ever did, especially under heavy load, and is nearly impossible to bring to its knees whatever I throw at it.

Back on topic: This attack doesn't really shock me that much; covert channels are a fact of life in any multi-user machine, and anything that needs bulletproof security should be on isolated hardware. Attacking an RSA implementation by analyzing cache performance is a truly sweet hack though... my propeller-beanie spins in admiration. :)

If it's a timing attack, why pick on HT?

[DrPizza]

Timing attacks are pretty hardware independent; they're more a trait of algorithms (requiring table lookups and hence cache hits and misses). Sure, one could create processors without data caches, but would one really want to?

The only real solution to such timing attacks is to disable multitasking; anything that can replace cache lines can disclose information. Hyperthreading may be a little "worse" in that it can make the cache contention a bit worse, but the problem exists with hyperthreading disabled.

Re:If it's a timing attack, why pick on HT?

[bradkittenbrink]

You're absolutely correct, and as the article describes, information can certainly leak throught virtual memory page fault timing attacks. The reason he singles out hyperthreading is that the bandwidth of information leakage is too low to be realistically exploitable for most other multithreading channels. In hyperthreading, the bandwidth of the leakage is actually high enough to allow eavesdropping of about 300 out of 512 rsa private key bits, which makes it relatively easy to optimize your factoring algorithm and obtain the entire private key. Yes hyperthreading is only a little worse than other multitasking, but it happens to be just worse enough to allow for a real exploit, or so he says.

Re:If it's a timing attack, why pick on HT?

[DrPizza]

No, being merely "constant time" isn't good enough, as djb also points out.

Most DES and AES implementations are "constant time". The problem is they use lookup tables, which can be driven from cache, thus altering the timings of the function. In other words, they introduce a kind of data dependency--because whether a given portion of the lookup table is cached or not depends on the offset being looked up. Precomputed tables are used to provide constant-time operations, yet actually have the effect of introducing timing problems.

As far as I can tell, the only solutions are to either provide a mechanism for encryption operations to gain exclusive use of processor resources (which means no context switching allowed at all) and be written to ensure that their lookup tables fit in cache and never suffer contention, or to use encryption algorithms that don't use lookup tables at all.

Of these solutions, only the second is even remotely practical.

Re:If it's a timing attack, why pick on HT?

[DrPizza]

Er. Lookup tables *are* used to make high performance constant-time algorithms. That's, you know, the entire problem.

VMware ESX servers have an out

[JohnZed]

For those who use VMware ESX server, note that you can prevent one virtual machine from using this attack on another virtual machine in the same physical system. You can set sched.cpu.htsharing=none in a VM's config file to effectively disable HT for this vm only. You can also try:

sched.cpu.htsharing=internal for an SMP VM to disallow it from sharing a package with vcpus from another VM, but allow the two vcpus from this VM to share. More is explained in the hyperthreading (8) man page and in the HT whitepapper: http://www.vmware.com/pdf/esx21_hyperthreading.pdf

If you have only a single VM with untrusted users on a given box, you could set that VM to "none" sharing while allowing other VMs to continue to take advantage of HT.

I don't know how many Slashdotters use ESX, but you've got it admit it has some pretty cool features.

Yeah

[blue trane]

and there's no community possible on the web, none at all, absolutely.

Re:Yeah

[StarKruzr]

Real life > web.

If you don't agree, I'm not sure we've got much else to say to each other.

Colin Percival's Paper Now Online

[SenFo]

Here's the much awaited paper from Colin:

http://www.daemonology.net/papers/htt.pdf

Re:It is just a statment

[Master of Transhuman]

And why it is just a claim is explained in posts above yours...in other words, it's a security issue which means you don't blab it until you have it nailed down and some sort of remediation possible.

Considering things harmful considered harmful....

[Rinzai]

Well, whatever you do, don't do aspected-oriented programming (that was Considered Harmful two weeks ago) on a Hyperthreaded CPU.

I'm pretty sure that will Destroy the Entire Universe (sm), or at least sour the milk a full week early.

Hey, I have nothing useful to contribute intellectually, but sniping is my hobby, so....

Details now given.

[BrakesForElves]

Well, I just read the paper, and I applaud Colin on several levels. First off, the theory of the attack is rock-solid and well-written. Secondly, he describes very implementable OS work-arounds, crypto library fixes, and finally chip design corrections which will totally eliminate the security hole.

This is one of the best thought out, best written papers of its kind that I have read in my over thirty years of work in the engineering field.

The paper is now online...

[cryptoguy]

... see

http://www.daemonology.net/papers/htt.pdf

He describes an attack on the RSA secret key in an OpenSSL system. By knowing how OpenSSL performs modulus arithmetic, he is able to distinguish many bits of p and q in the modulus by observing L1 cache hits and misses in a simultaneously running process. Assembler code is provided...

Wow, this gentleman seems pretty accomplished ..

[phpCypher]

I wonder why he doesn't use linux ...

obligatory...

[Pan Sola]

This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine There are NO unprivileged user on my Windows XP box, you insensitive clod!

Re:Reminds me of a bug in Michigan Terminal Servic

[jesup]

No, MTS - Michigan Terminal System. Created at Michigan State I believe; ran there, Waterloo, RPI, and 8 or 10 other universities (maybe more). Used to run 100-175 users on a 370/3033 and later a 370/3091(?) 4-CPU system. At RPI, the main computing center (VCC, Voorhees Computing Center) was (and is) an old chapel, with 20' stained glass over the terminals.

VERY different than MVS.

Probably the only OS that came with a full PDP-8 simulator as a system command - and the PDP-8 simulator was used once to break the security of the OS. Really. A buffer-overrun attack.

Also announced by Adi Shamir in February

[time961]

During the Cryptographer's Panel at the RSA conference, Adi Shamir made a short reference to this vulnerability. He confirmed in subsequent e-mail that of course he had a working implementation, or he wouldn't have mentioned it in public, and that a presentation would be forthcoming at the Eurocrypt 2005 rump session next week in Denmark.

I was sore disappointed that the press didn't pick it up then, because I thought it was the most interesting item in any of the keynote talks at RSA (although the hash function flaw announcements came a close second).

Cache contention as a covert timing channel has been explored at least since 1983/84 (when I encountered an instance of it during a TCSEC project and was gently shooed away from exploring such a "sensitive" topic). The precision targeting of this particular attack is really slick.

Re:Also announced by Adi Shamir in February

[cperciva]

During the Cryptographer's Panel at the RSA conference, Adi Shamir made a short reference to this vulnerability.

Yes, we seem to have discovered the problem independently. (Until today I wasn't sure if we had discovered the same problem -- Adi Shamir didn't reply to an email I sent him about this -- but I got an email from Eran Tromer after my paper went online.) ...a presentation would be forthcoming at the Eurocrypt 2005 rump session next week in Denmark.

I don't want to pre-release their results, but Shamir, Tromer, and Osvik decided to demonstrate the attack in a somewhat different way. I think it demonstrates how dangerous this attack is that two people independently discovered the attack and came up with different entirely practical targets for it.

Linux not likely vulnerable

[lpq]

The hyperthreading covert information leakage is unlikely to be a problem in Linux since Linux doesn't have true "threads". Each thread is represented by a process and the author states that multiple processes wouldn't be able to use the Processor L1 cache due to process switching overhead.

This exploit also uses a few "small" [sic] bits of handwaving:

1) Ability to syncronize the two separate processes. This was done for the author's example by using a debugger, "spy" to "know" when openssl was started and when it ended (p6).

2) quite another bit of handwaving with "On an otherwise quiescent system" (p6)

3) On a trusted OS, how did "trojans" and "spy" programs get loaded? On such systems, it is usually not the case that even compilers are availabe let alone the ability to load programs on demand.

On a trusted OS, a trojan might, at best, be loaded by a low-level browswer/download process. On a MLS, the user doing the downloading doesn't (or shouldn't) have administrative access to allow a trojan or a spy access to realtime functions like "process debugging", and "process scheduling" (perhaps including the "sched_yield" function.

It is quite likely that on a properly configured MLS system, web browsing would be done at a lowest level of priviledge, where only previously installed programs are allowed to run -- i.e. you can't download a trojan and have it be runnable. Anything downloadable to a writable partition has the "noexec" bit set. This is not user-changeable by a user with Mandatory Access Control's in place (often used with MLS to prevent privilege elevation).

4) It's unlikely that a MLS secure system with MAC (vs. Discretionary Access control, or DAC) would even be hooked up to the internet.

The whole bit describes an unlikely scenario in a MLS(usually MAC) system.

None of this means the author hasn't done his homework and there isn't a risk
of covert channels using this means, but in the real world, super secure systems shouldn't be running code that hasn't been rigorously examined and proven to some "Effective Assurance Level" (EAL).

The whole bit of caching could be extended to the Linux block cache, but in such a scenario, to provide true Level Separation, different priviledge levels likely wouldn't use the same block devices -- and hopefully, Processesors could have a bit as to whether to divide the cache/processor or to allow cache sharing (which would benefit performance for most apps).

Also, I might ask -- how would two different threads of the same process get two different levels of security clearance -- that just seems like dangerous programming and such a program would likely not be approved for most MLS systems.

It is a good paper, and it raises good issues to be aware of, but in practice it doesn't seem easily implemented.

However -- that stated -- there have always been known information leakage problems on multi-user computers. Simply measure latency in key echo's, network pings and program performance. All of these can be used to leak bits of information.

As for getting 310 bits out of 512...who's using 512 byte RSA keys these days? Bruce Schneier, in 1995 listed 1280-2048 bits for an RSA key.

Some symple preventive measures for now: 1) don't allow different threads in same process to have different security levels. 2) don't run untrusted programs on a "secure" system. 3) providing L2 cache separation _might_ be useful for some small number of government users trying to run an MLS on one machine, but it seems it'd be more assurance for them to use two separate processors in two separate machines physically separate machines running at different security levels.

Sorry if I've overlooked anything in my assessment. In no way did I mean to step on any toes. :-)

-l

"Considered Harmful" Essays Considered Harmful

[millennial]

See?
Really, what's the point of these anymore? We need some essays about things that actually cause harm, not confusion or frustration.
Ingesting Ammonia Considered Harmful
Chemical Burns Considered Harmful
Improperly-Handled Chainsaws Considered Harmful
The Government Considered Harmful
etc. etc.

Peer review?

[gvc]

The work was not published in a crypto or security forum. For that matter, it was not published - where's the paper? Where's BSDCan's list of expert reviewers and description of their review process? Where're the thousand cryptographers that disagree with Linus?

Without the paper to judge, without any testimony from any security authority, and without any obvious remedy, what would be gained by starting to generate kernel hacks at this time?