4 ms·
Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can e
by Tuna-Fish 2y ago
Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can examine register contents and alter the value it's returning so that mixing it into the previous source of randomness produces the desired evil value.
- rincebrain 2y agoSure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
- Tuna-Fish 2y agoThe thing is, all the other ways you can compromise the kernel from microcode are at least theoretically detectable. A security researcher could study how the cpu operates and find the exploit. If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. I agree that worrying about RDRAND shouldn't probably be on the top of anyone's priorities, but there is some cause to at least use it defensively, for example using it to pre-fill buffers with random values in a different context, so that subversion would in the very least require memory references, instead of running RDRAND in the context of your RNG.
- Muromec 2y ago> If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. Should you not see it from timing alone being wrong?
- usrusr 2y agoHad the same thought. But then on the other hand, when nobody is looking at the timing, nobody will see anything. And those who do see a timing artifact, will they really dig deeper or will they just shrug off another oddity? I would not like to bet on another Clifford Stoll in this day and age.
- Tuna-Fish 2y agoRDRAND is very slow and you can fix up the timing with a slowdown loop in the microcode.
- wtallis 2y agoI think you may be overestimating the scale of attack that can be accomplished within the constraints of a microcode update. Given that the CPU has to still seem to be operating normally while using malicious microcode, how much space out of the few kilobytes of a microcode update file is really available for implementing a subtle attack, complete with monitoring the state of the larger system to detect a trigger condition or locate specific information (such as the timestamp you mention)? Sure, malicious microcode theoretically has access to basically everything, but the severely limited payload makes it a lot harder to pull off complicated attacks.
- mmh0000 2y agoAnd, you shouldn't trust your CPU! * https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it https://www.eff.org/deeplinks/2017/05/intels-management-engi... * https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine * https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo... * https://en.wikipedia.org/wiki/ARM_architecture_family#Security_extensions https://en.wikipedia.org/wiki/ARM_architecture_family#Securi...
- jstasiak 2y agoAn article mentioning this kind of attack: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html