Slashdot Mirror
Hyper-Threading, Linus Torvalds vs. Colin Percival
OutsideIn writes "The recent Hyper-Threading vulnerability
announcement has generated a fair amount of discussion since it was released. KernelTrap
has an interesting article quoting Linux creator Linus Torvalds who recently compared the vulnerability to similar issues with early SMP
and direct-mapped caches suggesting, "it doesn't seem all that worrying in real life." Colin Percival,
who published a recent paper on the vulnerability,
strongly disagreed with Linus' assessment saying, "it is at
times like this that Linux really suffers from having a single dictator in charge; when Linus doesn't understand a problem,
he won't fix it, even if all the cryptographers in the world are standing against him.""
Actually, my bet is it will be fixed in the new CPU revision, by Intel. And eventually Kernel fix dug into the config somewhere next to other "bugfix/support" entries, with note like "Early multithreading Intel Pentium 4 CPUs have a vulnerablity that allows to override privledges of a process. This entry includes a patch for this bug at cost of increasing the kernel size by 32K and slightly slowing it down. If you have an early Pentium 4 processor and run a multi-user system, say Y. If you don't or aren't sure, say N."
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Linux developers can fix it but the fixes won't go in linus says what goes in and what doesn't.
Why wouldn't he?
He doesn't say "I don't want a fix for this anywhere in the kernel" anywhere. Just that he doesn't think it's a very critical issue.
If someone else does the patch for him, why wouldn't he accept it?
Beware: In C++, your friends can see your privates!
Of course. Except that the roles would be taken by other people: The Linux zealots would play the "it's a major security problem" role, while the MS zealots would play the "there's no real exploit here" role.
Except that for MS problems you'd probably not actually hear about it unless an exploit has been found (MS would of course keep quiet about it, and others would probably not find out other than by creating an exploit).
However, IANASE
The Tao of math: The numbers you can count are not the real numbers.
RMS is more like the tribal elder reminding you of your ideals - especially during those times when you consider putting them aside because they seem impossible to live up to.
I'm not to sure about that. Linus says this is a library issue and I agree. The kernel should not try to fix library bugs.
What this bug amounts to is this: When a program is performing calculations using secret data like an RSA key, it is important that the data access patterns do not depend on the secret data, since these patterns can be analyzed by an attacker.
An example of a classical vulnerability of this sort is using the c function strcmp to compare the real and the supplied password. By timing multiple runs you can get a decent estimate of how long time the strcmp function took, which means you can guess which character was first differing character in the password.
The security flaw in HT is that a process running on a HT CPU can get quite a lot of information about the data access patterns of the process on the other virtual CPU on the same chip. In other words, the severity of any library bugs which cause different access patterns on different secret data has been severly increased.
Try out fish, the friendly interactive shell.
FWIW, the original cray os didn't have virtual memory since seymor didn't understand it. A unique caas, but it is what I though of when I saw the /. blurb.
No just compare every character in the input everytime, rather than short-cut when you know it wont match.
If you've spent a lot of time working on something, it's obviously important to you. That doesn't mean that it's important to everyone else.
Well, no, however it is important to many people.
I, like many others here, run an e-commerce web site on Linux servers. In my case, my servers are virtual servers shared with other users who I do not have any knowledge of at all.
If the server used HT, it would be possible for one of those other users to run an exploit on the server to crack my e-commerce site's private key. Fortunately it doesn't, but my ISP could upgrade at any time...
Hence, this is an issue that effects me and my customers, and I seriously hope that a fix finds itself into either apache mod_ssl or the mainline Linux kernel PDQ.
That sounds like it has some non-trivial costs associated with it. That would mean losing performance in many instances where two high-cpu processes want to be exectured on a single physical processor at the same time.
The best solution is to just fix the crypto libraries as a short term solution, and for Intel to fix the chip in future iterations as a long term solution. Mucking about in the kernel and having other unknown effects seems like a bad approach when the problem can be fixed elsewhere.
AccountKiller
Not enough. You still have to make sure the hash functions runtime doesn't depend on the length of the password, or you will still be vulnerable to man-in-the-middle attacks.
Algorithms like SHA work on blocks of data, so what you need to do is make sure the code for padding the password to full block length doesn't change the runtime.
Try out fish, the friendly interactive shell.
That reminds me of the joke about programmers being in a car, steaming downhill with failed brakes, narrowly avoiding death, then once the car has come to a standstill suggesting that instead of seeing what went wrong they just get back in the car and `see if it happens again`.
Programmers hell, most mechanics I know have this attitude. 'Well, it stopped, didn't it. We'll fix it later'
I wouldn't blame software developers for this attitude, it seems to be common for humans (or at least Americans) as a whole.
Find coupons in Greeley
I dunno if I agree, for two reasons. First, you'd be surprised what a sophisticated, determined and deep pocketed adversary can do (e.g., the smart card vulnerabilities that were uncovered a few years ago by analyzing the power consumption).
Secondly, just because the clock is ticking fast doesn't mean you can't count them as they go by. The same process run at 1Mhz and 1Ghz is going to look substantially the same, because you're monitoring them faster too. If anything, you're less likely to get interrupted by I/O during the process.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Faster processors also means that you don't need to be as precise. You can search more possibilities faster, but every byte you can chip away helps narrow down the search range.
It's true that there are various "noisy" and uncontrollable aspects of modern CPUs, but if you take enough measurements and can establish a control, you can get valid information. It will not give you "the answer", it may help you to eliminate a set of data that is "not the answer". That is extremely valuable.
Some people actually monitor chip power supply variations to try to get this information. I won't pretend to understand how they get meaningful data from this, but it involves knowing the system under attack very well, and wanting the data really, really badly. Hence very high security systems shield their processors magnetically and inject "noisy" (bogus, unrelated) operations to cover this. It sounds like a pipe dream, but I've visited places where these systems are built (think Blue), and read some of the papers describing these exploits.
His point is valid, ANY information an attacker can get significantly reduces the integrity of the encryption. I just suspect Linus' point is that most (I said most, don't flame me) linux server deployments are geared towards not letting people on the server in the first place. This vulnerability seems to be valuable mostly to people who already have access to the system.
I didn't know it was possible to time anything as (ostensibly) quick as strcmp.
strcmp may be fast, virtual memory is not. You just make sure that your password ends up split between two pages in the comparing program - for example by padding the previous thing you send over network with spaces. Then generate some activity to make sure most of the things are paged out. Now if the part of the password on the first page is correct, the program will take longer to return failure and an extra page should be visible through vmstat. By repeating this with different alignment, someone can guess your password character-by-character.
I am afraid multi-user systems are there to keep students from stealing each other's homework, not for protecting military secrets. Over the Internet, such small variations in timing should be impossible to measure. You can insert a random delay every time your program processes an incorrect password for good measure.
First, remember that public key exchange is usually a very small component of a cryptographic session. Usually, you do all the public key work at startup, exchange private keys for the session, and then just use the private keys. So an inefficient solution that protects the public key computations is acceptable.
In the paper, Percival writes "Further, OpenSSL utilizes a "sliding window" method of modular exponentiation, decomposing x := (a^d)
mod p into a series
of squarings x := x^2 mod p and multiplications x := x ^ (a*2*k+1) mod p." When there's a zero bit in d, the squaring and multiplication are unnecessary, and the SSL implementation apparently skips them. That creates the covert channel. It should be sufficient to revise the code so that it always does the squaring and the multiplication, and then uses the zero bit in D to decide whether or not to use the result. Because some superscalar CPUs might manage to look ahead and avoid the squaring and computation, a nice solution would be to compute both x := (a^d)
mod p and x := (a^(d XOR K) mod p, where K is all binary ones out to the maximum length of d. This makes the computation symmetrical, independent of the value of d. This should roughly double the cost of the public key computation, which is probably tolerable.
It's now important to also examine private key mechanisms for similar vulnerabilities. In particular, DES implementations should be checked. Because those execute millions of times during a long data transfer, even if there's a low-bandwidth leak, an exploit may be possible. Some lookup-table based implementations of DES might have exploitable cache semantics, and that needs to be explored.
Allegedly the OpenSSL code has over 1000 data-dependent if-statements
I don't doubt it, and it would likely take a rewrite of the RSA code. But RSA is a very simple algorithm, so I believe it can be done without much trouble if one doesn't obsess over efficiency.
Practically speaking, just fixing modular exponentiation (which is the core of encoding and decoding) to call exactly the same bn_ functions whether the key bit is 0 or 1 would seem to fix this particular problem.
like the old maxim goes, there's no security if the attacker has physical access
Yup, if the security is based on a simple string compare, and you have physical access to the machine, all you need to do is modify the assembly. I use to do this to all my old computer games that required me to enter information out of the manual. Just invert the condition of the branch, then jump over the dialog call.
The way I compare encryption passwords in my programs, is to compare a hash of the end result with a stored one. ("end result" being the string of data that you xor against)
"That's so plausible, I can't believe it!" - Leela
How bout have threads be associated with a bit like NOT_OK_FOR_FOREIGN_PROCESS_HT. Most threads, having no such securtity concerns, would have the bit off and the kernel would schedule them as normal. Threads for crypto would set the bit on and then the kernel would only schedule those threads to run with threads of the same process on the same physical processor at the same time.