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

Yer killin' me

[$RANDOMLUSER]

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.

AHAHAHAHAHA
snort. please. stop.
HA HA HA HA HA HA HA HA
No. Really. It hurts.
AHAHAHAHAHAHAHA goomph.

Re:Hardware RNG

[$RANDOMLUSER]

Now why would you assume Microsoft would use the hardware RNG when they have thier own, much better, proprietary RNG available?

Huh?

[mrseigen]

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.

Fixed in Vista?

[adonoman]

http://msdn.microsoft.com/msdnmag/issues/07/07/Security/default.aspx [microsoft.com] has the new API, including a RNG

that meets Federal Information Processing Standards (FIPS) for use with the Digital Signature Algorithm (DSA).

There's a lot I don't like about Vista, but for security researchers to "assume that XP and Vista use similar random number generators and may also be vulnerable" without a basic google search is a bit much!

Publication iffy

[cdrguru]

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.

Re:Hardware RNG

[thePsychologist]

It might only be a problem for 2000 users:

According to the researchers, who have already notified the Microsoft security response team about their discovery, although they only checked "Windows 2000" (which is currently the third most popular operating system in use) they assume that newer versions of "Windows", XP and Vista, use similar random number generators and may also be vulnerable.

Re:Hardware RNG

[thePsychologist]

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

the number of affected users enbiggens the problem

[doti]

only tested Windows 2000, and not XP or Vista, both combined are far more used than 2000

Still, 2000 has more (desktop) users than Linux. By your logic, if there were a similar problem in Linux, it would be less of a problem?

Re:Hardware RNG

[Belial6]

You actually didn't provide any evidence that the problem doesn't affect XP or Vista, you just suggested that the two newer version should be trusted immediately after finding out that 2000 has a bug in an unlikely to be updated part of the system. The non-troll way of highlighting this information would be:

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.

Re:Fixed in Vista?

[Anonymous Coward]

Huh? It's perfectly possible, indeed desirable to code against an interface. This gives you the ability to change the code behind it as you're treating it as a black box. It's not even new to windows; the common dialog calls for example bring up OS specific dialogs; so I could make the same call for Win95 on XP and I will get the XP dialog. Both your premise and your conclusion are pretty fatally flawed.

Re:Hardware RNG

[Bert64]

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.

Might not extend past W2K

[thebdj]

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 [nist.gov] 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.

Re:Hardware RNG

[thebdj]

A new RNG is not really a selling point, the only way it will help their bottom line is if enough people know about flaws in the old one that it's profitable to replace it.

Actually it can be, since it would be necessary to use a FIPS compliant PRNG to perform certain operations, they would need to have one. I suspect (see my other posts) that this is from a deprecated cryptographic service provider that MS no longer providers (DSS_BASE). If you check out the information on the CMVP website for the RNG Validation Lists [nist.gov], you will see they implement FIPS 186-2 PRNGs, which the paper itself admits (Appendix B) has some forward security and is not the PRNG they are attacking here.

Tin foil hat: "Reflections on Trusting Trust"

[mlwmohawk]

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.

Re:Tin foil hat: "Reflections on Trusting Trust"

[secPM_MS]

Everything I have heard in the security community within Microsoft says that there are no backdoors. Since my observation is not evidence to the paranoid, consider the following:

The Common Criteria evaluators have essentially full access to the Windows source code and all supporting documentation. They look for issues that would enable backdoors or security vulnerabilities. Once and a while, they find something interesting. Microsoft then fixes it as a security bug.

Windows platforms are used by numerous nations for secret information that they want to keep secret from the US. They wouldn't be using the platforms without some reasonable level of assurance concerning the code base.

If there were convenient backdoors in Windows, governments wouldn't need to conduct bag jobs to insert hardware loggers or use malware to capture suspect's actions.

My conclusion is that there are vulnerabilites in the Windows codebase, as shown by the MSRC process, but these are not intentional and they are fixed as they are discovered.

Re:Tin foil hat: "Reflections on Trusting Trust"

[mlwmohawk]

Everything I have heard in the security community within Microsoft says that there are no backdoors.

I have never heard anything other than, "It could be, if you knew...."

The Common Criteria evaluators have essentially full access to the Windows source code and all supporting documentation. They look for issues that would enable backdoors or security vulnerabilities. Once and a while, they find something interesting. Microsoft then fixes it as a security bug.

Funny how people who are not "Common Criteria evaluators" find a lot more stuff.

Windows platforms are used by numerous nations for secret information that they want to keep secret from the US. They wouldn't be using the platforms without some reasonable level of assurance concerning the code base.

And many of these nations are SERIOUSLY reconsidering their Windows use.

If there were convenient backdoors in Windows, governments wouldn't need to conduct bag jobs to insert hardware loggers or use malware to capture suspect's actions.

Assuming that third party utilities does screwup the intentional holes, that some people use other platforms, like Linux or bsd.

My conclusion is that there are vulnerabilites in the Windows codebase, as shown by the MSRC process, but these are not intentional and they are fixed as they are discovered.

Believe what you will, but I disagree. Maybe I am paranoid, but when your suspicions get confirmed, is it paranoia or good common sense?

Re:So...

[Tim C]

A newly registered guy, even if they're named secPM_MS, doesn't buy much.

Why does it matter how long he's had an account here? I've been here for years and have the UID to prove it (well, if you believe I registered this account rather than buying it), but what does that say about how much I know about any given topic?

Re:I can't believe this is an issue...

[Anonymous Coward]

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.

Why should MS crypto programmers be aware?

[EmbeddedJanitor]

I don't share your optimism. I have dealt closely with MS on three very different areas of computing (certain low-level kernel stuff and some client server stuff). In all cases I was shocked at how poorly the people understood their subject matter.

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.