In April, I wrote about my issues with Microsoft's Ten Immutable Laws of Security. Well, they've surfaced again, and once again, Microsoft is using them to justify calling an issue "not a security vulnerability." Why? Because once again, "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore."
Windows 2000 and Windows XP were found to have a bug in the pseudorandom number generator, part of the Microsoft CryptoAPI (CAPI) and used throughout not only the operating system core features regarding security, but also by third-party software developers.
How is a random number generator used?
Random numbers are needed whenever encryption algorithms come into play. Sometimes they are sufficient just to make encryption keys, while other times they simply help to seed a value prior to encryption.
For instance, suppose I wanted to encrypt some data using a symmetric algorithm (that's one with only a single encryption key, not a public/private key). I'll choose AES-256 - that means that I have a 256-bit encryption key (the key is 32 bytes long). What typically happens is that the input data is taken in 32-byte chunks and a mathematical operation is performed on it and the key, resulting in a 32-byte output. The state of the key changes in a predictable way (predictable as long as you know the starting input and the key), and then the next block of input data is read. Typically, the next block of input data is exclusive-ORed (xor) against the first block's encryption result so that it is more difficult to attack the key if you know a certain amount of the plaintext.
What Microsoft does to improve the security of their symmetric algorithms is also to use an initialization vector. As I noted, the second block of data is XORed against the first block; this is a lossless operation, but it assists, as I mentioned, in making the key more difficult to attack. However, the first block doesn't have something to do this against. That's where the initialization vector comes in; the first block is XORed against the IV prior to encryption. This requires the storage of the IV in addition to the key, and is specific per-instance of a new encryption operation, but it helps prevent reverse-engineering the key given a plaintext, and it also prevents two identical plaintexts from being encrypted to the same value when not using the same IV.
All told, the fact that the cryptographic random number generator is predictable is troubling. Imagine being able to predict both the key and the IV of a given encrypted cipher stream.
Yes, just like my exploit, to exploit this vulnerability, you need to already have been compromised by running someone else's code. The disappointing thing is that, despite the evidence, Microsoft is still not budging that this is an effective attack vector (getting someone to run your code, I mean). Email, companion virii, evil ActiveX - it's all out there.