On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote:
>
> If the security issue only affects a small percentage of the installations
> and fixing it means breaking many other installations, then there has to
> be a discussion if we really want fix the issue or if a "don't do that"
> documentation is the better choice.
One of the questions which needs to be answered is exactly how many
installations are actually broken. I don't think it's going to be bad
as you suspect....
> Rasberry PIs were only an example. There are also other systems, including
> old x86 systems, that don't have a HWRNG. Also, there are probably a load
> of x86 VMs that emulate an older CPU due to libvirt misconfiguration and
> don't expose the rdrand cpuid bit.
x86 systems have a high resolution timer; Rasberry PI's don't.
Furthermore, if libvirt is miconfigured, it should just be fixed (and
better yet, it should be configured to enable virtio-rng, which is
*not* hard).
> Systems that don't suffer from blocking on entropy because they have other
> sources of entropy (hwrng, ...) won't have their security reduced because
> the good entropy will still be added to the pool, regardless of the seed
> file being credited or not.
The question is how long they have to block. *Very* unfortunately,
there's a lot of busted software that try to generate
security-critical keys when the system is first booted, which is when
entropy available is the least available. Such packages include ssh
and various packages which call openssl (such as CUPS) which are
visible to the internet.
And if the system doesn't have good sources of entropy, and don't have
sufficient interrupts to initialize the entropy pool, the question is
what should we do? Should we just blindly proceed and let them
generate insecure keys? At least, if the system blocks, they'll know
something is wrong, and they can fix the problem (for example, such as
*fixing* their libvirt configuration).
Ultimately, I don't think it's a big problem, primarily because I'm
not hearing a lot of yelling from Debian users. It may be annoying
for your Rasberry Pi system, but the question is whether that is a
common case or an isolated case.
> So, how could we go forward from here. Maybe we could limit the wait for
> entropy to some reasonable value (1 minute? 5 minutes?). This could be
> done by creating a program that does a blocking getrandom but with a
> timeout. If the timeout expires and the seed file has been read
> successfully before, it would then credit the read entropy. This program
> would be added as systemd unit so that services that need entropy can
> depend on it and don't get killed with a timeout. Is this a reasonable
> approach? Or do you (or anyone else) have any better suggestions?
My suggest is to try and figure out *what* is blocking, and *why*. If
it's because it's something security-critical, such as generating ssh
keys, letting things continue even though we don't have secure entropy
is a bad, bad, BAD idea. If it's for something stupid, like
generating seeds for Python dictionaries (just as an example; that one
has been fixed) then the application should be fixed not to request
secure randomness in the first place.
That's the correct fix, as opposed to a short cut that might leave us
in worst place, from a security perspective.
- Ted
