bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 18 Jan 2016 21:34:12 -0800
> 
>     AFAICS, we close the file descriptor as soon as we finished reading.
>     So unless GnuTLS initialization is run in another thread, there won't
>     be 2 descriptors at the same time.
> 
> GnuTLS keeps /dev/urandom open indefinitely.

So it's a bug or misfeature in GnuTLS.  Not our concern.

> If Emacs opens /dev/urandom independently it can have two file descriptors open to the same file. Yes, it's not a huge deal performance-wise; but it is strange, and when doing security audits it will be one more thing to explain.

GnuTLS guys need to explain this, not us.

>     But where we need to seed our own PRNG, we better had a good idea of
>     what we do and what kind of randomness we get.
> 
> Any worries we might have about GnuTLS's randomness apply with equal force to /dev/urandom's. After all, /dev/urandom is not guaranteed to be random.

No, /dev/urandom is random enough for our purposes.

> Really, though, if we can't trust GnuTLS to give us random data, we should not trust it for communications security at all. Nonces are that basic.

We could stop trusting GnuTLS for communications security, but we
still need the secure random seed for server-start.  I see no reasons
to tie these two together.  The Emacs server is not about TLS
communications, at least not by default.

If GnuTLS were a library of RNGs, it would have been a different
matter.  But it isn't.  We shouldn't depend so critically on 3rd party
libraries for functionality that is unrelated or secondary to their
goal.

>     So what is special about GnuTLS?
> 
> GnuTLS already has the random data we need; other libraries don't.

We have what we need; calling gnutls_rnd changes nothing in this
regard.  It's just a more complex way of issuing the same system
calls.  It buys us nothing in terms of security and performance, while
we sustain the price of having core functionality that must run at
startup crucially depending on a 3rd party library we don't control.

John, I feel this decision is wrong and the changes that prefer
gnutls_rnd should be reverted.  Maybe I'm the only one who cares, but
then Paul is the only one who felt the need to make that change.  I'd
like to hear your take on this, please.