On Wed, Apr 27, 2022 at 03:58:51PM +0200, Jason A. Donenfeld wrote: > > 3) More broadly speaking, what kernel infoleak is actually acceptable to > the degree that anybody would feel okay in the first place about the > system continuing to run after it's been compromised? A one-time kernel infoleak where this might seem most likely is one where memory is read while the system is suspended/hibernated, or if you have a VM which is frozen and then replicated. A related version is one where a VM is getting migrated from one host to another, and the attacker is able to grab the system memory from the source "host" after the VM is migrated to the destination "host". Merely reseeding the CRNG from the input pool isn't going to help, since the attacker could have grabed not only the CRNG pool, but the input pool as well. In the case where the guest image is "freeze dried" and then reconstituted multiple times, and where the attacker hasn't actually grabed state, then all you need to do is to mix in some kind of nonce, such as the current time (which hopefully will vary across different VM "reconstitutions"), or some kind none (for example the VM ID, if that can be obtained somehow). But if the attacker can actually obtain internal state from one reconstituted VM, and use that to attack another reconstituted VM, and the attacker also knows what the nonce or time seed that was used so that different reconstituted VMs will have unique CRNG streams, this might be a place where the "premature next" attack might come into play. The simplest mitigation is if you have some kind of external RNG which you can actually trust, or at least mostly trust. e.g., either some kind of CPU-based hwrng, such as RDRAND, or a hypervisor-provided hwrng, such as Virtio-RNG. And if the hypervisor is going to playing games with reconstituting freeze-dried VM's, I'd argue it can d*mned well provide a virtio-rng facility. And the same argument could be made just as easily with live migration scenario, with the hypervisor providing some kind of notification that VM had just gotten live migrated, so it should really reseed from the virtio-rng facility right away. That leaves the variant where the kernel infoleak happened while the system was suspended. And in that case, we're talking about an attacker which had physical access to the machine (say, an "evil maid" attack while the laptop was left suspended in a hotel room in Moscow or Beijing). And in that case, there are probably far simpler ways that an "evil amid" with temporary physical access to the hardware could compromise the secuity of the unattended laptop. > Is "premature next" just an academic exercise, rather than a real world > RNG concern? I'd say it's mostly an academic exercise. Given our current model, where we only reseed the CRNG periodically, and we're hopefully getting some amount of uncertainty into the input pool, there will be a certain amount of "catastrophic reseeding" going on, which I don't think is a bad thing. But personally, I don't think the complexity of N levels of Fortuna pools are worth it. - Ted
