security/55659: ssh-keygen may generate predictable keys

[Andreas Gustafsson <gson%gson.org@localhost>]

>Number:         55659
>Category:       security
>Synopsis:       ssh-keygen may generate predictable keys
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    security-officer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 14 14:55:00 +0000 2020
>Originator:     Andreas Gustafsson
>Release:        NetBSD 9.0, -current, and others
>Organization:

>Environment:
System: NetBSD
Architecture: x86_64
Machine: amd64
>Description:

In NetBSD 9.0, ssh-keygen(1) uses /dev/urandom as its randomness
source, and will therefore silently generate potentially guessable
keys when run on a system that lacks entropy.  In -current, it uses
the kern.arandom sysctl, with the same result.

It makes no sense that NetBSD has strict criteria for when it
considers the system to have sufficient entropy, but then completely
ignores those criteria when performing the very operations where
having entropy is most important.

Other cryptographic functions such as the generation of SSH and TLS
session keys have similar issues, but I'm focusing on ssh-keygen
because I think it is the clearest example of a case where using
/dev/urandom is not acceptable.

I have been told NetBSD has behaved this way for decades, but that
does not make it any less of a bug.  In theory, fixing it is easy:
make ssh-keygen use /dev/random instead of /dev/urandom (or their
respective equivalents).  In practice, it's harder, because unless
other issues are fixed first, making this change can have a severe
usability impact, such as causing newly installed systems to
mysteriously hang on first boot as a result of ssh-keygen silently
blocking on /dev/random.

>How-To-Repeat:

Run ssh-keygen under ktrace and inspect the system calls issued.

>Fix:

I'm proposing the following rough plan:

First, make the randomness source of ssh-keygen configurable, so that
those who prefer it to block rather than generate predictable keys can
choose this behavior even if it is not yet the default.  This will
also aid testing of the following steps.

Second, make sure that most systems have sufficient entropy, for
example by creating a random seed file at installation or upgrade
time.  Also, make sure that if ssh-keygen nonetheless ends up unable
to generate keys due to a lack of entropy, a clear error message is
issued and points the user to a reasonable way of supplying the
entropy manually.

Finally, enable the configuration option of the first step by default.

[I am posting this to netbsd-bugs manually because it was not
automatically posted by gnats despite deliberately having
"Confidential: no", and neither security-officer nor gnats-admin has
responded to my mail asking how to fix that.  I don't know if replies
addressed to gnats-bugs will get posted on netbsd-bugs, either, but
http://gnats.netbsd.org/55659 will probably show them as it has been
showing the original PR since it was filed a week ago.]