No need to get all worried about this type of hack. First of all, it is just an idea, not something actually found. Secondly, the hack would be all too easy to detect: run rdrand 2^31 + x times and see if x is a repeated sequence.
Generate sequences of numbers continually, ad infinitum, and determine if distribution rates are (?).
How would one begin to fill in that question mark? A PRNG that spits out three million 'zeros' and a single 'four' is as reliable as a PRNG that spits out an even distribution of random numbers.
The issue here is the entropy of such a sequence is extremely low, and while low entropy PRNGs do exist, and they are not considered good for cryptographic purposes. If algorithmic weaknesses led to long stable and highly compressible sequences, or rather, sequences with a very low entropy (as measured by say, Kolmogorov complexity) would be considered suspect.
Determining Kolmogorov complexity is itself a difficult problem, it's the problem of finding the shortest program (in a theoretical computer science sense) that produces a given output. And the complexity of that sequence is trivial, which is a huge problem for PRNGs. If every other seed had an extraordinarily high complexity with lots of hidden state, then maybe it would be considered, but I suspect not.
That is, if you accept a certain probability of falsely identifying a RNG as biased, I don’t see why this should be a fundamentally difficult problem, at the very least for the generator with four million 0s and a single 1: The probability that a good RNG spits out less than a thousand 1s in four million queries is negligible compared to the probability that it returns between 1.5 and 2.5 million 1s.
Of course, it will be harder to detect more sophisticatedly broken generators, but still, without requiring certainty, it should be possible to make some sensible claims?
For practical help, see http://www.stat.fsu.edu/pub/diehard/ (linked from http://en.wikipedia.org/wiki/Diehard_tests)
Any number or group of numbers that are consistently over/under represented should point to a bias as far as I can tell.
However, the attack is essentially undetectable with n=128, and it can still be very useful because they force the AES key to be constant: between two reseedings of the conditioner, the output of RDRAND will be entirely deterministic and computable by the attacker. According to http://www.cryptography.com/public/pdf/Intel_TRNG_Report_201... , under heavy load there could be up to 44 64-bit outputs between consecutive reseedings, even assuming a healthy entropy source. The first 2 outputs are unpredictable, and the remaining (up to) 42 outputs can be predicted by the attacker.
Imagine a scenario where a malicious sandboxed application uses the random generator to monitor RDRAND output, while another application generates a cryptographic key. I think that according to Intel, this is safe because RDRAND is designed to be resistant to malicious processes (see the above paper). But if the n=128 attack is used, the malicious process can detect with high reliability when another process uses RDRAND, and can recover the value received by the other process (the exception is that if another process uses RDRAND just before a reseed, it can't be detected). For a 256-bit key and maximal load, that's a 90%+ chance of recovering the key. All with just a simple sandboxed binary.
And I think the broader point of the researchers is not about any particular attack, which can indeed be countered by specific countermeasures: it's that we now know that it's easy to maliciously alter any chip design to add various vulnerabilities, and it's probably going to be very difficult for any chip designer to predict what vulnerabilities this will introduce. I think RDRAND was chosen just because design details were made publicly available by Intel, not because it's the most interesting target. The paper gives another interesting example, which enables side-channel attacks in a side-channel-resistant chip.