Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Sat, 30 Apr 2022 17:49:55 -0700
From:   tytso <tytso@mit.edu>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     nadiah@cs.ucsd.edu, noahsd@gmail.com, dodis@cs.nyu.edu,
        tessaro@cs.washington.edu, torvalds@linux-foundation.org,
        djb@cr.yp.to, jeanphilippe.aumasson@gmail.com, jann@thejh.net,
        keescook@chromium.org, gregkh@linuxfoundation.org,
        peter@cryptojedi.org, linux-crypto@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: is "premature next" a real world rng concern, or just an
 academic exercise?
Message-ID: <Ym3ZM1P+uYYABtRm@mit.edu>
References: <YmlMGx6+uigkGiZ0@zx2c4.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YmlMGx6+uigkGiZ0@zx2c4.com>
Precedence: bulk

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