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

Another hit for Intel

[Anonymous Coward]

Man, talk about getting hammered...Itanium, AMD, and now this....

Re:Another hit for Intel

[Anonymous Coward]

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

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

[Anonymous Coward]

I believe that it would take years to EFFECT an operating system and chipset combination. Much less time to AFFECT the same.

Have a nice Friday.

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

[Anonymous Coward]

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

*BSD must have stolen the code from SCO, queue the legal team.

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

[Anonymous Coward]

Unfortunately that would take away the edge that HT CPU's have on multitasking. It may not be much, but some apps might take a pretty big performance hit. You do what you have to to secure yourself I guess though.

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]

> Doesn't Linux handle HT the same way it handles SMP?

Yes, but the processor doesn't. This is a flaw in the protection rings of the processor. It has nothing to do with the OS. Yes, Linux would be vulnerable.

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.

Re:Whoosh!!!

[Anonymous Coward]

i think you're wrong, bitch

Re:Whoosh!!!

[Anonymous Coward]

i cunt cur

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.

Re:Quick fix

[hotdiggitydawg]

Careful what you eat... hyper-threadworms are so much harder to get rid of than normal threadworms...

Re:Quick fix

[Anonymous Coward]

Ahh so, your pipeline is clean :-)

It is just a statment

[Anonymous Coward]

The linked article has no information on how this attack is possible and why it is only limited to HT sytems and why is not possible in a SMT.
Should we discuss every claim in the universe before seeing any details in slashdot just because someboyd is going to a conference?

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.

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!

[Anonymous Coward]

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

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.

Sorry closed.

[Anonymous Coward]

This thread has been closed by SlashDot System Administrators. :P

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.

Re:All that speed....

[Anonymous Coward]

Do you honestly have a multi-user system where you set up random people with user accounts? Or did you bother to RTFA?

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?

[Anonymous Coward]

I think the guy didn't learn ANYTHING from Sklyarov vs Adobe case. Instead of distributing papers after the talk, a couple of men in black suits will grab his sorry curious ass and haul it to the release-of-trade-secret bay in southern seas. :)

Re:Where's the details?

[Anonymous Coward]

If companies cared so much about the DMCA, they would seek to have all security hackers arrested. God forbid someone find a flaw that does society a net positive good thing.

Talk about selective enforcement.

It just struck me that the DMCA is entirely a PR vehicle. Use it to show 'toughness' against computer crime, ignore it completely when it gets in the way. Very convenient. This reminds me why it's generally better to have fewer laws than more.

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?

[Anonymous Coward]

I ran this guy's PiHex program 5-10 years back. He's smart and not full of shit. Probably way smarter than you, dude. He does post here on Slashdot sometimes too by the way.

P.S. He uses his real name. You use a handle. Whose reputation for "BS" is more at stake?

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?

[Anonymous Coward]

And the security bulletins from FreeBSD, NetBSD and OpenBSD are BS too, eh?

The weird thing is, other than the 3 big BSDs, the only other advisory is from SCO, of all people - when normally their advisories come out late by 6 months to a year or more. (check the version string of ftp.sco.com...)

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.

Hahahahahahaha!

[Anonymous Coward]

Oh shit!!!

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!

Re:This is SERIOUS!!!

[hotdiggitydawg]

Don't worry, the $699 licence fee you paid covers technical support. Of course, you did pay the fee, right? RIGHT?

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

[Anonymous Coward]

Privilege elevation exploits don't need this kind of secrecy. This is just a lame publicity stunt.

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]

I haven't seen the attraction of hyperthreading. My father said that it is great because now he can read his email (at work) while running his compiler, rather than the compiler taking up all of the CPU.

I said he should just lower the process priority of his compiler (or raise it on his email client).
Then, the compiler can use 100% of the CPU when he isn't surfing the web on company time...

I got a machine that has it, and I turned it off in the BIOS. I have been meaning to do some comparisons, to see if I can notice.

Re:Is this a hyperthreading problem or..

[Anonymous Coward]

Right... There's no attraction at all in having processes able to share the processor more efficiently. No attraction at all in having two processes able to execute some instructions concurrently.

You seriously need to get yourself a clue or stop posting when you have no idea what you're talking about.

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

[Anonymous Coward]

Ok, then think about it some more. You've already got contention between processes for processor time. This helps to aleviate the problem by letting your threads share different portions of the processor. Additionally you've got an extra set of registers so it eliminates a hell of a lot of PUSH/POPing when switching between two threads.

On my load (concurrent compilation jobs) clock time on a run is decreased by about 40%. Nothing to sneeze at.

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

[Anonymous Coward]

1 gig? 1 gig of what? 1 gig of cache? Wow, that's some mighty PIII, indeed.

Do you realize, of course, that GHz and gig have the exact same number of letters, don't you?. Then why be an idiot and say utter crap like "1-gig Pentium III" when you could have saved yourself the embarassment of looking like, well, idiot, by spelling it correctly, while taking the exact same effort?

It mystifies me, really.

Re:May I be first to say...

[gklnx]

Course you can throw that away and just get a 1 gig G4.

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

[Anonymous Coward]

full duplex?

Re:May I be first to say...

[Anonymous Coward]

just hold the shift key with yer right hand, and hit ghz with yer left. obviously you need to have the coordination to release the shift key at the appropriate time...

Re:May I be first to say...

[Anonymous Coward]

"just hold the shift key with yer right hand, and hit ghz with yer left"

I imagine that's what most people do. Maybe the GPP has an aversion to breaking the typing "rules"

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

[Anonymous Coward]

Granted, TFA is light on details, but the author is fairly clear--the OS'es listed are the ones that have REVIEWED and RESPONDED to his alert. It is NOT a complete list of all potentially affected OS'es.

I'd be willing to be Windows is indeed affected--they're just not listed because Microsoft hasn't officially put out a press release.

As noted earlier, this may well be a hardware exploit, which would mean most OS'es are vulnerable (and would make a patch other than "disable hyperthreading entirely" quite difficult).

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.

How many people does this bug actually affect?

[Anonymous Coward]

My guess is not that much. This isn't some bug that allows a user to send a specially formated TCP/IP packet to create an admin account and remote access. This is an exploit and security bug, but it's not another winnuke.

No details, I'll just wait

[ilithiiri]

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

Re:No details, I'll just wait

[Anonymous Coward]

Before the full disclosure, can't say anything..

erm...

Re:No details, I'll just wait

[Anonymous Coward]

show me the code, baby

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.

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

[Anonymous Coward]

Eeeh, as someone who's hired people with and without PhDs, I'm not overly impressed. A PhD from Oxford is nice enough (although Cambridge has a better reputation in the hard sciences), but there are plenty of equivalent degrees around the world. Lots of engineers from MIT or CMU or Hopkins et cetera, and it's just the beginning of your qualifications anyway, just a ticket that proves you're not clueless.

A good working attitude would count for a bit more to me. This guy. . .I dunno, I wouldn't hire his ass. Who needs a prima donna? I'd feel more comfortable with a solid team of very good engineers than one arguably more clever person with a serious self-esteem issue. Just my 20 millibux.

Suggestion for the presentation

[Anonymous Coward]

If you can't get a polycarbon suit, I would suggest a skintight outfit, preferably in black, with silver-gray accents, when the three Blue faces show up onstage, and you will commence giving them a thorough ass-whipping, Matrix-style.

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.

Re:Oh dear.

[Anonymous Coward]

They will find a way. Trust me. Remember the infinite monkeys? Morons are MUCH more effective than monkeys.

Other than that, it's a good thing our dev server is dual-Opteron.

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

[Anonymous Coward]

If you don't have anything to add to this article other than spout a load of fanboy shite, then please don't bother. Dickhead.

i can hardly contain my excitement

[Anonymous Coward]

important though this issue is, no doubt ...

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

... i'm FAR more impressed by your PERSONAL achievement, and am sure that your PERSONAL, INDIVIDUAL presentation will reflect the glory of your .... (tails off into symantic rant). er, some humility in order? i don't give a toss about WHO spots an issue; i care about the merit of the issue itself.

Re:i can hardly contain my excitement

[Anonymous Coward]

For the person who tagged this as flamebait, it is generally considered bad banners to refer to the words "my", "I" in a research paper.

A more polite phrasing would be:

A presentation about this attack will be made at BSDCan 2005 (10:00 AM EDT on May 13th), and at the conclusion of the talk, a paper describing the attack and possible mitigation strategies will be distributed.

Re:i can hardly contain my excitement

[setantae]

Those words aren't in the research paper.

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

[Anonymous Coward]

Huh. Funnily enough, the exact same type of problem I spotted in Google Web Accelerator last week.

Re:Probably a Timing-Based Attack

[Anonymous Coward]

Not really. The secure-mode process would only hog the whole CPU during its assigned timeslices. Other process could still run in HT mode in their own timeslices. So if you had 3 processes and #2 was in secure mode, the OS could schedule (2, idle), (0, 1), (2, idle), (1, 0), (2, idle)...

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.

Re:I know it's Off Topic but

[xintegerx]

I'll try it right now. So instead of enter, I press F8?

Re:I know it's Off Topic but

[Anonymous Coward]

www.linuxquestions.org

You have to register, but it is worth it because you get answers to questions pretty fast.
Slashdot users may help you, but a site like this is better geared for it. Good luck!

Three months huh

[apache guevara]

Spent 3 months doing this for free ....

And then ask for company funding in the very next FAQ. Hmm...have to wait till tomorrow for the grand unveiling then (if there is one)

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:I know it's Off Topic but

[Anonymous Coward]

Enjoy ..

http://service1.symantec.com/SUPPORT/tsgeninfo.nsf /docid/2001052409420406?OpenDocument&src=sec_doc_n am

http://service1.symantec.com/SUPPORT/tsgeninfo.nsf /docid/2001052409420406?OpenDocument&ExpandSection =2&Src=sec_doc_nam#_Section2

Re:I know it's Off Topic but

[Anonymous Coward]

Hold control when windows starts booting (as soon as you select the option in grub/lilo

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.

Here is how it works:

[Anonymous Coward]

He's going to run a program in which the user can choose a random number, then he will put a stethoscope up to the processor at which point he will pull out a slide rule, do a few calculations, and let the user know what number they picked. Only if hyper-threading is enabled of course...

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

[Anonymous Coward]

Dumbfucks like you are the reason why 90% of all email traffic now consists of viruses and spam.

Re:stupid paranoid people

[Anonymous Coward]

this submitter - who, by the way, seems WAY too keen on how clever HE is - seems to be suggesting that i IMMEDIATELY take down a full company of people(s) doing good, productive work on a machine(s) that are in their default hyperthreading state, dick with their machines late on a friday afternoon, spend all weekend catching up with the caveats/retractions in his no doubt TERRIBLY clever presentation today, realise then that this is far less of an issue that the submitter has presented and go back to where i was : all because someone might -just- be able to catch a glimpse of an RSA.

clearly this is completely ridiculous.

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

[Anonymous Coward]

Actually, I believe its the spammers and virus writers who are responsible for all the spam and viruses spreading around. And what the HELL does this have to do with spam? This "exploit" the submitter found is rediculous...all it does it theoretically allow some computer genious to sneak a peak at an RSA key...it doesn't automagically let you set up zombie pc's that spam their asses off.

YOU sir, are the dumbfuck. But hey, don't let me stop you wasting your pathetic life waiting for the newest and most obscure "security vulnerabilities" show up, and spending all your free time (because you have nothing better to do) fixing useless problems on your stupid Linux boxes.

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

[Anonymous Coward]

Some of these "security risks" that people propose are just ridiculous.

People used to say that about opening email attachments. Some clueless people still do.

And why would someone target your PC unless you had some really valuable information.

An old PHB used to say this whenever I talked about security, until our web servers started saying "hacked by Chinese".

Why would somebody target your PC? a) they don't have to do so specifically, it can be automated (isn't that the whole purpose of computers?) and b) some people have a lot of spare time.

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.

Re:stupid paranoid people

[Anonymous Coward]

They won't be targeting you, or your machine, per se, but "they" do collect zombies where ever they can. Infect half the windows world with a virus that has a chance of netting an SSH login key, and the'll likely be scoring a few root or admin passwords.

Also, there a few other instituitionally paranoid occupations that care. Almost any financial institution (e.g. banks, brokers, credit card co., and perhaps an e-merchant or two) will have people paid to be serious about security. Most other $BIG_CORPs will too.

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

[Anonymous Coward]

Don't mod the parent down. It's actually fairly accurate.

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.

Re:Same Guy?

[Anonymous Coward]

This is the same guy who calculated the 1 Quadrillionth hexadigit of Pi (no, not digit. It is in base 16).

This might not be as impressive as it sounds. There are algorithms that allow you to find base-16 digits in pi without calculating any of the preceding ones.

The BBP formula is one he mentions, and Bellard's formula that was actually used is listed at MathWorld under "Pi Formulas."

If he'd actually come up with one of these, I would be very impressed. As it is, it sounds like he just put the brute force behind it.

Re:Same Guy?

[Anonymous Coward]

he is destined for being a big-name IT security guru.

Just as soon as you finish sucking his dick.

Correction

[hotdiggitydawg]

Hmmm, looked into this further and actually you're not covered. See, the $699 fee is per CPU, and since the problem occurred on a second, virtual CPU, it's outside SCO's obligation to support you.

In addition, SCO are now aware that you have not purchased a licence for this second, virtual CPU, and are sending a squadron of jackbooted fascist lawyers around to your house to collect your nuts, left leg and firstborn son...

hohum

[BigBadBus]

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

On the other hand...

[Anonymous Coward]

this could really be an exploit that only runs when HT is turned OFF... which the nervous among us will do having read the teaser.

OK, I'll take my tinfoil hat off now.

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.

Re:I know it's Off Topic but

[Anonymous Coward]

Hold Ctrl.

I'll get right on it

[Anonymous Coward]

Yeah.. I'll disable HT right now so I can relive the 1gig days. Seriously, who cares. If you're one of those people that have data on their machine that needs to have an RSA key, then you're not allowing more than one person to use the same machine anyways.

To the average consumer, this means dick.

Security people should take off their tin foil hats and learn that not everyone is a paranoid freak like they are. As long as I'm safe from hackers on the internet, virii, and spyware, I could care less.

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

[Anonymous Coward]

Couldn't cut it eh?

Re:On the other hand

[Anonymous Coward]

I love the smell of ad hominem in the morning!!

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

[Anonymous Coward]

COngrats, you just set a record for excessive use of links in a comment. It is like trying to read one of the annoying keyword ad laced articles you see on the web nowadays.

Re:On the other hand

[Anonymous Coward]

It's never made the Playboy list for partiest school. Please support your claims in the future.

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

[Anonymous Coward]

You failed to finish your sentence:

"which is commonly held as the finest academic institution in the world...for private-school and crammer- educated inbreds who will spend 3 years studying social science and 3 weeks in their job at the merchant bank forgetting it."

I'm not biased, I just hate posh twats.

Re:On the other hand

[Anonymous Coward]

It's a 'nice' troll... not a great one.

It needs much moar credibility and slightly less pomposity.

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

[Anonymous Coward]

University of Oxford, which is commonly held as the finest academic institution in the world

Ah, but he was at Wadham, so he's probably not that reliable...

Re:On the other hand

[Anonymous Coward]

Gee, how convincing. Harvard takes #1 with 100 points out of 100, followed by Stanford with 77.2. How do I interpret this? Is Harvard really at least 29.5% better than every other school in the entire world?

I'm going to be going to school #9 in the fall, so I don't have much reason to complain. I will admit that I was rejected by #2, but I didn't even want to go to #4, nor to high-and-mighty #1. I considered #5 but it just wasn't right for my specialization.

This chart is almost totally useless except to influence the weak-minded into valuing your education at #N over anyone else's at #M.

Re:On the other hand

[Anonymous Coward]

How is that when it takes less than 1 second to encrypt my messages?

Re:On the other hand

[Anonymous Coward]

Hmmph. Nobody calls *me* doctor.

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

Re:On the other hand

[Anonymous Coward]

Haha. #2's graduate engineering programs are well-known for being easy to get into. They do their filtering at quals time.

More info

[Anonymous Coward]

He also uses the name Bananatree3 on Slashdot.

Q&A

[nashy-nunu]

Thos Q&a were pretty funny. I wonder how does that guy eat? I don't think that by spending so much time working on security flaws, gives much time to find a sugar mama!

Try F6

[Anonymous Coward]

You're welcome

Re:I know it's Off Topic but

[Anonymous Coward]

Nooooooooooooooo you press enter, then immediately start tapping F8 like mad, using two hands. Most of the time Windows will boot normally, but try it again a few times: A normal person should get the "safe mode" menu in less than 5 tries...

When you hyperthread, terrorists win

[Anonymous Coward]

nt

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

Re:Single Chip Multi Core

[Anonymous Coward]

Multicore CPU instruction sets? What are you talking about? Multicore CPUs look exactly like multiple CPUs from the perspective of software.

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.

AMD prime choice for security sensitive systems

[Anonymous Coward]

This makes AMD processors the obligatory choice for security sensitive systems. Without hyperthreading those Pentiums and Xeons are... not worth the money and risk.

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:You can't win for losing

[Anonymous Coward]

The guy is awaiting his doctorate at one of the world's most prestigious universities, has an excellent track record

everyone i met whilst i also was gaining doctorate and track-record at one of the world's most prestigious universities was an egghead without enough common sense to live in the real world. the freshmen were far better than the grads. the last person you need crying 'wolf' about his pet peeve is some eloquent nerd about to look for a top IT job straight out of grad school.

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?

[rpozz]

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

That's a good point. I wonder how many HT processors used for servers have been sold in the past seven months. If this isn't a load of shit, he's caused problems for an awful lot of people entirely for his own benefit.

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.

err...slashdot?

[Anonymous Coward]

is slshdot hosted on an intel processors ? i see too many threads here. uh - oh.

You insensitive clod!

[Anonymous Coward]

Surfing the Internet with good ol' Windows for Workgroups 3.11 is the way to go. No open ports out of the box, not even the infamous port 139!

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.

Re:Bah... my ancient Sparc II scoffs at x86

[Anonymous Coward]

Huh? The SparcStation 2 (Sun4c design) only had a 40MHz 32bit processor. Sparcs weren't 64 bit until The Ultras (Sun4u design) came about. If you want to mention a kickass CPU at the time you should have mentioned the MIPS r4000, at the time almost no computer (even SGI's workstations) even used them in 64bit, only as a 32bit processor that could do 64bit integers and floating point numbers very fast...

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.

Heck, I'll post the exploit before 10:00!

[Anonymous Coward]

Just plug this in and...

Re:Reminds me of a bug in Michigan Terminal Servic

[Anonymous Coward]

Oh dear, they found this issue again in PC's. Next someone will be disclosing diagnostic modes in graphics cards that provides direct DMA access or better. How about SQL server, and interrupting a runas thread, and inserting/substituting another token . old hat. Eventually they will find there is no cheap solution, unless extra bits are sacrificed. Even when IBM fixed this in the 80's , deadly embraces popped up every so often.

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.

This story neglects one danger of hyperthreading..

[Anonymous Coward]

The danger of making people stupider by thinking intel has had dual core processing for the past 3 years that ht has been available..

Google dual core and hyperthreading once, and look for the message boards etc that are full of people claiming HT=Dual core... hell, I even have an IM from a guy who's been working on linux and nt systems for 2-3 years now calling the HT chips dual core.

Yes, the real threat of HT is that it makes people stupider. Scenario: linux/nt junior admin- 'Ohh my computer doesn't bog down to a crawl when windows tries to redraw a window... it must have magical dual core technology to not do that!' me: 'baka ranger, it's just reordering it's pipeline to allow out of order execution'
--;

So does anyone know...

[http101]

...if this affects AMD processors with Hyper Transport technology? I'm curious since AMD's Hyper Transport is similar to Intel's Hyper Threading, but in my books, superior.

Re:So does anyone know...

[hartz]

Only similarity is in the abbreviation.

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.

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:So does anyone know...

[Anonymous Coward]

Well, let us quickly compare the technologies. They are both two words, and the first word in both is identical. This does not bode well for AMD. The second word in both starts with a T and in addition, they are both nine letters long!

However, "Transport" has a completely different dictionary definition than "Threading". I think that is of minor consequence after looking at the previously mentioned evidence.

It is my professional opinion that AMD's Hyper Transport is just as vulnerable, if not more so, as Intel's Hyper Threading to this security problem. To fix this I suggest a name change to "Hyper Trolley" or "Hyper Carriage".

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:So does anyone know...

[Anonymous Coward]

I'd love to know what evidence you have that Hyper Transport is superior to Hyper Threading.

Mainly, because they are two completely different things.

Re:In that case...

[SpinJaunt]

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

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.

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

Re: On the gripping hand

[Anonymous Coward]

As a Yank everything I know about the English school system I've learned from watching episodes of The Young Ones and Ab Fab.

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

[xxxJonBoyxxx]

This fellow is Intel's bitch: he wastes three months of his life to fix a major corporation's problems and he will get no compensation for his efforts. Maybe he hopes Intel will give the good dog a milkbone, but any human being with sense of self-worth would probably do something less demeaning. Nevermind about the van - given his lack of ambition it's probably going to be a laptop and a blanket under an LA freeway bridge.

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

Advice for Sony

[Anonymous Coward]

I hope Sony read this.

M$ try to use their OS and Office money to pay for all these hardware (like the 3 IBM processors). Also, they try to use commodity hardware such as standard DVD drive to keep their cost down.

So what you should do, Sony?

1) Use standard component as much as possible to keep the cost down.

2) Use Linux on your box. Put OOo 2.0, FireFox, calendar, and abunch of things on it. Make sure it's internet ready. No set up needed.

3) Make Linux starts up as fast as possible.

This will cut down the number of OS and Office M$ will sell. This offense is the best defense.

With 5 to 10 Million PS3 shipped, you'll have a huge market share on Desktop. Now, use your business talent as much as you can on it (like make deal to ship other's software as well).

Also, another killer manuver, after you release PS3, give out a CD for free to install in all you 30Millions PS2. This CD has all the Linux OS and softwares and what not.

4) Make sure it can connect to keyboard, mouse and use TV (or HD TV) as the monitor.

5) Make sure to have an online market place to distribute games, free softwares, etc. And don't forget to charge fee for the download.

6) Be early/ontime to market. That's one of the most important thing in business.

I bet someone at Intel knew about this

[Anonymous Coward]

Intel engineers are smart guys. I bet one or more of them thought about this before they ever released any processors with it, but were told to shut up or lose their jobs.

I hate it when companies are run by their marketing departments.

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

[Anonymous Coward]

Abstract:

Simultaneous multithreading -- put simply, the sharing of the execution resources of a superscalar processor between multiple execution threads -- has recently become widespread via its introduction (under the name "Hyper-Threading") into Intel Pentium 4 processors. In this implementation, for reasons of efficiency and economy of processor area, the sharing of processor resources between threads extends beyond the execution units; of particular concern is that the threads share access to the memory caches. We demonstrate that this shared access to memory caches provides not only an easily used high bandwidth covert channel between threads, but also permits a malicious thread (operating, in theory, with limited privileges) to monitor the execution of another thread, allowing in many cases for theft of cryptographic keys. Finally, we provide some suggestions to processor designers, operating system vendors, and the authors of cryptographic software, of how this attack could be mitigated or eliminated entirely.

Re:Paper

[owlstead]

Mod parent up?

Re:Paper

[Anonymous Coward]

Interesting. Does this do anything on Windows platform? I can't see any mention of this on the comments, nor on the documents or the other sites?

Imho it isn't even ethically right not to inform them as well in advance as had been done with the rest.

Re:Paper

[Anonymous Coward]

Thank you!

That was an excellent read, even for those of us that didn't get our CS degrees at 19.

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.

Re:Paper

[Anonymous Coward]

I am thinking "Windows Terminal Server" ...

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.

Simple, low impact fix

[Anonymous Coward]

"permit HT only for multiple threads within the same process" may be overly restictive. All you need is to make sure all the threads have the same owner or "user ID" It is likely usless to spy on something you already have access to. For a typical home/hobby machine this is a very small restriction.

Re:Simple, low impact fix

[Anonymous Coward]

Process boundaries and chroot jails are useless if information like this is allowed to cross them.

This is not a hardware problem

[Anonymous Coward]

This guy is full of BS. No exploit code, only lots of talk of L1/L2 cache. This is all theory and most of it BS. This is not a hardware problem. Now he has a google ad running on his site. If anything, he found a kernel problem with BSD.

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

[Anonymous Coward]

What are you smoking? The Athlon64 is a totally different design and has nothing similar to the Pentium 4's hyperthreading.

Re:Athlon 64 implements hyperthreading

[DarkHelmet433]

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

Re:Athlon 64 implements hyperthreading

[Anonymous Coward]

What does this have to do with the Athlon64 suposedly (which it doesn't) implementing hyperthreading?

The Athlon64 does NOT use HyperThreading.

Re:Athlon 64 implements hyperthreading

[Anonymous Coward]

So fucking what? You can take a 386 targeted kernel and it will run on every damn x86 processsor from the 386 forwards.

I love it when dimbulbs, especially idiot BSD zealots, who have zero clue about computer architecture come in here and start blathering on as if they do know what they are talking about. Just becuase they have the same ISA does NOT mean they are the same fucking hardware design. I bet you are just some pimply faced high schooler who thinks you are uber l33t with computers and better than everyone else becuase you use BSD which somehow makes you better than everyone else.

Get a fucking clue, moron.

If you can show me where the Athlon64 has Hyperthreading technology, I will eat my own shit and take pictures.

Shotgun mouthwash please.

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

[Anonymous Coward]

Because, of course, who needs community? People are awful

Truth be told, they are. People are suspicious, inconsiderate, exciteable, and mostly intolerable. They're also easily led by major media and do very little thinking of their own. The only thing which makes it possible to coexist with the vast majority of the population is that they're so completely incompetent that they're also fairly predictable. This makes it easy enough to run between their little social games, achieve whatever public objective (grocery shopping, for example) is necessary and return to a more sane environment.

I'd much rather stay in my mom's basement

The parents' basement joke is now officially beaten to death.

Re:Right

[gowen]

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

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

+5 so choice

[Anonymous Coward]

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

thats some phat ass roflcopters you got spinning there

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?

[Anonymous Coward]

As djb pointed out, cryptography can be made immune from timing attacks by implementing it using constant-time (not data-dependent) operations. Granted, doing without precomputed tables is very expensive, more so for some algorithms than others.

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?

[Anonymous Coward]

Huh? Lookup tables are not constant time on modern machines, therefore neither is any algorithm that uses them.

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.

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

[Anonymous Coward]

I think we're in violent agreement. AES with data-dependent table lookups isn't a constant-time algorithm, though the author may have wanted it to be.

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.

Cache missing?

[Anonymous Coward]

"For those who were unable to attend my talk, I have written a 12-page paper,
Cache Missing for Fun and Profit, discussing this flaw and related problems,
both realized and theoretical."

1. Cache Missing
2. ?
3. Profits!

Quick Summary

[Anonymous Coward]

This is a timing attack. One thread can work out what regions of memory the other thread is accessing by timing how fast it can read those regions itself; if the other thread has read them it will get them quickly because there will be a cache hit.

Similar attacks are possible between processes in a uniprocessor machine, but because hyperthreading is so much more fine grained the amount of information that can be revealed is much greater.

In the paper he has a diagram where he shows, in the form of a grid of boxes of different shades of grey, some measured parameter varying over time while the other process is doing an OpenSSL cryptographic operation. A pattern is readily apparent. By looking at details in the pattern it is possible to spot different memory access patterns that depend on the cryptographic key. He is able to determine 310 bits of the 512 bit key, which is sufficient to allow a brute-force attack.

It would be quite possible to automate this process, i.e. write a "key sniffer" program that would wait for and then decode this pattern.

So on a machine where some users don't trust others, and where a predictable operation like cryptography is being carried out, hyperthreading should be disabled, or some O.S. level countermeasures (i.e. only scheduling processes with the same owner at the same time) should be emplyed.

And he is looking for a job.

That's WHY you can disable RDTSC

[Anonymous Coward]

High-resolution timing is widely known to be a covert channel. Which is exactly why Intel included an enable flag for the RDTSC instruction. If idsabled, only the kernel can execute it, and user software has to ask the kernel for high-resolution timing, and the problem can be controlled.

Excellent technology demonstration of spying on a program *not* designed as a covert transmitter. But you might want to RTFM before pointing the finger at Intel...

Re:Disable hyper threading today....

[Anonymous Coward]

What, straight people don't care about security? Bigot.

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.

Re:Yeah

[Anonymous Coward]

Believe it or not, nobody enters an alternate universe when they log in. The people writing comments here are just as real and alive as the people outside your door, just farther away. Unless you're role-playing, the web is simply part of real life.

According to the article...

[Anonymous Coward]

...this was first discovered in October of 2004!!! Way to take your time buddy. It took longer than the 3 months you mentioned...

Colin Percival's Paper Now Online

[SenFo]

Here's the much awaited paper from Colin:

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

Poor choice of name!

[Anonymous Coward]

The siren call of "FOO TECHNOLOGY CONSIDERED HARMFUL!!!!!@#!@ROFLS" has been beaten to a pulpy death over the years. However, it typically refers to some opinion that FOO tech is intrinsically bad. For example, regardless of the implementation, Dijkstra argued that GOTO was a bad thing. But! This moron misused the title to refer to a bad implementation of a fundamentally good technology.

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

More like an arrogant ass

[Anonymous Coward]

This researcher contacted several BSD people asking how they did implement the HT case on SMP without giving more details. That's not how security issues are handled, and it's one of the reasons why the OpenBSD people have chosen to notify FreeBSD only after everyone else has been when a problem with openssh arises. So thanks for nothing, Mr. Percival.

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

mod parent UP: INFORMATIVE!

[Anonymous Coward]

very informative, thank you. Did you have any traumatic experiences when you were pottytrained?

Wow, this gentleman seems pretty accomplished ..

[phpCypher]

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

Re:Reminds me of a bug in Michigan Terminal Servic

[Anonymous Coward]

MTS ? ... Maybe you mean MVS. There were three IBM mainframe OS's in use in the 70's/80's. They were DOS (the oldest), MVS (the newest at the time), and VM (developed as an OS to help customers migrate from DOS to MVS). Never heard of MTS, though.

And yes, the FP support on MVS was a little strange, since FP support was an after-the-fact bolt-on sort of thing. Not surprising that artifacts like the one you cite were present ...

Paper released

[Anonymous Coward]

Well, here it is. http://www.daemonology.net/papers/htt.pdf

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:Nah...look for him in a van by the river...

[Anonymous Coward]

I would. Getting a PhD in engineering is a very safe route to status. Compare to diving into the real world, solving real problems that generate real hardware and software, then trying to sell the damn stuff to clueless but picky users, herd your clever but full of themselves engineers, keep good secretarial help, fend off the IRS yadda yadda and still turn a nice profit. Now *that* is what I'd call ambition. Not lazing away in the groves of Academe pondering how many angels on the head of a pin it would take to break an RSA key in some Alice in Wonderland fashion.

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.

Re: On the gripping hand

[Anonymous Coward]

I'm also a "Yank", and I learned from watching "Inspector Morse" that Oxford is the murder capital of the UK.

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.

Re: On the gripping hand

[Anonymous Coward]

And we all know what a worthless institution Cambridge is. :)

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?

Sour grapes!

[Anonymous Coward]

Yes, Harvard is that much better than any other school in the world. Do you have some reason it isn't, besides a feeling that you don't belong there so it just ... just couldn't be better?