Slashdot Mirror
Loophole in Windows Random Number Generator
Invisible Pink Unicorn writes "A security loophole in the pseudo-random number generator used by Windows was recently detailed in a paper presented by researchers at the University of Haifa. The team found a way to decipher how the number generator works, and thus compute previous and future encryption keys used by the computer, and eavesdrop on private communication. Their conclusion is that Microsoft needs to improve the way it encodes information. They recommend that Microsoft publish the code of their random number generators as well as of other elements of the Windows security system to enable computer security experts outside Microsoft to evaluate their effectiveness. Although they only checked Windows 2000, they assume that XP and Vista use similar random number generators and may also be vulnerable. The full text of the paper is available in PDF format."
snort. please. stop.
HA HA HA HA HA HA HA HA
No. Really. It hurts.
AHAHAHAHAHAHAHA goomph.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Now why would you assume Microsoft would use the hardware RNG when they have thier own, much better, proprietary RNG available?
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Maybe it's just me, but I didn't think anyone would be stupid enough to use rand for SSL like the article is implying.
From what I can see, this is an old article anyway.
The only benefit that could possibly be derived by publishing algorithms and/or code for Windows security would be if (a) changes proposed would be implemented quickly and (b) everyone planet-wide upgraded.
If both of these did not happen, especially if (b) didn't happen, what you would be doing is exposing all non-upgrading users to the full brunt of whatever flaws their might be. Would this really be productive? Does this remind you of various failures in Linux code that led to rootkits being developed for it. Did the victims of such attacks think it was all for the best because they didn't upgrade in a timely manner?
Yes, relying on people not reverse-engineering code to protect users isn't a great plan. But the current situation - as regrettable as it is - is this is the only plan. There are no fallbacks, there are no alternatives. Most of the running copies of Windows aren't going to be "fixed" in any way whatsoever.
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
This is classic behaviour on Slashdot. I point out this might not be a big of a problem as it seems (as they only tested Windows 2000, and not XP or Vista, both combined are far more used than 2000), and I'm modded as troll, only because (I presume) that I'm providing evidence that a problem with Microsoft isn't as serious as it seems (i.e. I'm getting in the way of MS bashing).
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
factor 966971: 966971
That is a problem. I am eagerly awaiting the tests of XP and Vista to see if this was fixed for them.
You could probably even slip a little bias in there without being called a troll with:
They are going to test with XP and Vista aren't they? After all, it should be trivial to test this on the newer systems if the cryptography hasn't been changed. I mean what kind of security researcher just assumes the functionality of a security system?
Of course, it would be a little silly to assume that this does not affect at least XP, as 2000 was still under maintenance when XP was released, so if the bug was found during the development of XP, it should have been fixed in 2000. It would look far worse for Microsoft if they KNEW about a security hole in 2000 while it was still under maintanace, and did not bother to back port the fix from XP.
Funny you should mention that, windows has a really kludgy way of handling dates beyond 2000... It basically still uses a 2 digit date, and defines an arbitrary split point, eg:
Dates below 70 are considered in the year 2000, over 70 are considered in the 1900s.
Excel also has some stupid bugs to do with dates, which microsoft are now trying to enshrine in the ooxml format.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I am willing to bet two things:
1) This does not affect current versions of Windows.
2) This only affects exported versions of Windows. (The PRNG may still be there but may not be default.)
The RC4 implementation screams of a bit-size issue. It also goes to reason since they are in a non-US country. Furthermore, I doubt this affects current versions based on the information available. If you want, go throw the CMVP RNG validation list and find the Microsoft certificates. All of the RNGs that are approved do not use RC4.
I believe there is a lot of hot-air and presumption and in the paper. They published findings and ASSUMED that nothing has been changed with relation to the PRNG. The algorithm certificates shown above clearly shows this is not the case. Furthermore, they do not state which cryptographic provider is used to perform the generation. I believe this PRNG might be from DSS_BASE, which has since been deprecated. This would mean the problem does not exist. They also ask for Microsoft's code, yet I see none of their own. Without their code, how can their paper be reasonably verified.
I say show me some more, before you cry that this is the way all PRNGs since W2K have been implemented.
"Some days you just can't get rid of a bomb."
"Some days you just can't get rid of a bomb."
I'm sorry, all this RNG stuff just remines me of NSA key, and all the backdoor crap that Windows has suffered. I am reminded by the paper "Reflections on Trusting Trust."
I honestly have 100% no doubts that "Microsoft" is purposely installing multitudes of access methodologies in the form of bugs with "plausible deniability" for U.S. security officials. The telco's do it, they've been caught and are now asking for immunity. Now whether or not is is actually "Microsoft," or people working within the company secretly for the various security agencies purposely inserting these nearly impossible to find bugs is a different question.
Call me paranoid, but if I told you there was a secret room through which all internet traffic gets directed in all the major internet NOCs, you'd call that paranoid as well.
It's official. Most of you are morons.
One should note that the first step in this loophole is hijacking the process or obtaining administrative privileges over the client machine. If the attacker has hijacked the client process, it doesn't matter if they know the future encryption keys, as the client process. They might as well say "if you can use mind control to force another human being to sign over all their property and to tell you all their secrets, you could steal their identity...". Clearly, buffer overflows and other mechanisms through which processes are hijacked are more significant dangers than obtaining process specific state after a successful hijack of a process with administrative privileges. Traditionally, cryptographers and cryptoanalysts place the attacker in the role of a messenger or delivery boy. Here, they assume (as step 1) that the attacker can use another exploit to insert themselves into the client code. It is a well known problem that one cannot hide secrets from oneself. Just look at the XBOX, skype, etc. to see the miserable failures of companies who made every possible effort to convince users that they did not know their encryption keys in some way. This paper has no credibility based on the fact that the exploit exists in every possible encryption mechanism available. If a virus, trojan, or other user can insert itself into your client code at any point during communications, it can continue communication, request new encryption keys, use the random number generator, munge files, and generally do bad things because it is running directly in the client process. By this logic, everything is broken -- let me demonstrate:
NEW CROSS SITE SCRIPTING ATTACK IN :
step 1: gain control over the server through a buffer overflow or some other method
step 2: insert a cross-site scripting attack
step 3: profit!
NEW SSL VULNERABILITY:
step 1: gain control of the client process after the user input credentials
step 2: connect using SSL / use existing SSL connection
step 3: profit!
I wonder if this was actually published in a peer-reviewed journal. If it was, it makes me very sad to see the state of published research today.
Now I don't know what the crypto folk are like, but I have yet to see any real evidence to suggest that they'd be any better.
Engineering is the art of compromise.