Re: [Buildroot] [PATCH v2] package/urandom-scripts: hash old seed with new seed when saving

From: Peter Korsgaard <peter@korsgaard.com>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2] package/urandom-scripts: hash old seed with new seed when saving
Date: Mon, 28 Mar 2022 15:17:50 +0200	[thread overview]
Message-ID: <87fsn2b4ht.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20220324082433.GA3649946@scaer> (Yann E. MORIN's message of "Thu, 24 Mar 2022 09:24:33 +0100")

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Jason, All,
 > +Peter: candidate for backporting as a security fix

 > On 2022-03-23 14:07 -0600, Jason A. Donenfeld spake thusly:
 >> Writing into /dev/urandom doesn't actually credit any entropy bits. And
 >> while it adds that data to the entropy pool, it won't actually be
 >> immediately used when reading from /dev/urandom subsequently. This is
 >> how the kernel's /dev/urandom has always worked, unfortunately.
 >> 
 >> As a result of this behavior, which may be understandably surprising,
 >> writing a good seed file into /dev/urandom and then saving a new seed
 >> file immediately after is dangerous, because the new seed file may wind
 >> up being entirely deterministic, even if the old seed file was quite
 >> good.
 >> 
 >> This has been fixed in systemd with
 >> <https://github.com/systemd/systemd/commit/da2862ef06f22fc8d31dafced6d2d6dc14f2ee0b>,
 >> and fortunately it's possible to do the same thing in shell script here.
 >> Specifically, instead of just saving new /dev/urandom output straight
 >> up, we hash the new /dev/urandom together with the old seed, in order to
 >> produce the new seed. This way the amount of entropy in the new seed
 >> will stay the same or get better, but not appreciably regress.
 >> 
 >> At the same time, the pool size check in this script is useless. Writing
 >> to /dev/urandom never credits bits anyway, so no matter what, writing
 >> into /dev/urandom is useful and not harmful. There's also not much of a
 >> point in seeding with more than 256 bits, which is what the hashing
 >> operation above produces. So this commit removes the file size check.
 >> 
 >> As a final note, while this commit improves upon the status quo by
 >> removing a vulnerability, this shell script still does not actually
 >> initialize the RNG like it says it does. For initialization via a seed
 >> file, the RNDADDENTROPY ioctl must be used.
 >> 
 >> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

 > Applied to master, thanks.

Committed to 2021.02.x and 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot