From: Jason A. Donenfeld
> Sent: 30 April 2022 14:48
>
> Hi Denys,
>
> On Sat, Apr 30, 2022 at 3:12 PM Denys Vlasenko <vda.li...@googlemail.com>
> wrote:
> > > + /* The fsync() here is necessary for safety here, so that power
> > > being pulled
> > > + * at the wrong moment doesn't result in the seed being used
> > > twice by accident. */
> > > if ((unlink(filename) < 0 || fsync(dfd) < 0) && seed_len) {
> > > bb_perror_msg("can't%s seed", " remove");
> > > return -1;
> >
> > I don't understand the scenario mentioned here.
> > Let's say we removed fsync() above.
> > We read /var/lib/seedrng/seed.credit contents.
> > We unlink() it, but this change does not go to disk yet.
> > We seed the RNG.
> > We recreate /var/lib/seedrng/seed.credit with new contents,
> > but this change does not go to disk yet too.
> > We exit.
> > Only now, after we are done, RNG can be used for e.g. key generation.
> >
> > And only if the power gets pulled AFTER this key generation,
> > and the write cached data is still not on the disk
> > (for example, if you use ext4 or xfs, this won't happen since
> > they synchronously wait for both O_TRUNC truncations
> > and renames), the previous /var/lib/seedrng/seed.credit might
> > still exist and might get reused on the next boot,
> > and a new key can be generated from the same seed.
> >
> > Do you often pull power cords from machines you use for
> > somewhat important crypto operations, such as generating keys?
> > What are the chances that you also do it on a machine without RTC
> > clock (which would otherwise supply randomness
> > from the current time)?
> >
> > IOW: To me, this does not seem to be a realistic threat.
> > It's a theoretical one: you can concoct a scenario where it might happen,
> > but triggering it for real, even on purpose, would be difficult.
>
> Again, stop charging steadfastly toward creating vulnerabilities
> because you don't understand things. The scenario is:
>
> - RNG is seeded and credited using file A.
> - File A is unlinked but not fsync()d.
> - TLS connection does something and a nonce is generated.
> - System loses power and reboots.
> - RNG is seeded and credited using same file A.
> - TLS connection does something and the same nonce is generated,
> resulting in catastrophic cryptographic failure.
>
> This is a big deal. Crediting seeds is not to be taken lightly.
> Crediting file-based seeds is _only_ safe when they're never used
> twice.
Using the same file twice is better than having nothing at all.
At least different systems use different values.
Unless you have a remote 'dos' attack that can crash the system
at exactly the right point in the boot sequence this is an
entirely 'academic' error.
What is much more likely is that the file where the entropy
is saved is just a memory overlay on top of a read-only image.
That is much more likely for an embedded system than any of
the 'failure' cases you've considered.
I also wonder how sane it is to do 'new_key = f(old_key)'.
That doesn't seem significantly better than using the same key.
For a really embedded system the only persistent storage
could easily be a small serial EEPROM with a very limited
number of write cycles.
This requires special code to read/write and care to avoid
hitting the write cycle count on a small number of memory cells.
No amount of faffing about with filesystem accesses will
help here at all.
There is also the case (that on my systems at least) udev
initialisation reads from /dev/[u]random well before the S20
script loads any saved entropy.
I've not tried to find out what the value is used for.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
