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

Previous Next

Full log

Message #121 received at 22202 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, John Wiegley <johnw <at> gnu.org>
Cc: rcopley <at> gmail.com, 22202 <at> debbugs.gnu.org, deng <at> randomsample.de
Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to
 random number generator attack on Windows systems
Date: Tue, 19 Jan 2016 09:07:15 -0800

On 01/19/2016 08:24 AM, Eli Zaretskii wrote:
> So it's a bug or misfeature in GnuTLS.

GnuTLS has been operating that way for a while, and it works. Calling 
its behavior a "bug or misfeature" seems a stretch.

If we change Emacs back to always read /dev/urandom by hand as well has 
have GnuTLS read /dev/urandom at startup, this will cause Emacs to 
exhaust the GNU/Linux entropy pool more quickly. This may slow down 
other programs that read /dev/random (a device that blocks until entropy 
is available). So there is an overall system benefit to minimizing the 
use of /dev/urandom, which was the point of my original patch.

>> 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.

Any explanation they come up with will have to be part of our 
explanation, since we're responsible for Emacs. Our explanation will 
also have to cover Emacs's added accesses, so minimizing them will be a win.

>>      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.

In that case GnuTLS's nonce generator is random enough for our purposes, 
and we have a good idea of what kind of randomness we get.

>
>> 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.

If we stop trusting or using GnuTLS, the code will still get a secure 
random seed by hand, so that's not a problem. But currently we do trust 
and use GnuTLS by default, and there are no plans to change this.

> 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.

They are not the same system calls. If they were the same, you would be 
right and we shouldn't bother with GnuTLS here. They are different 
sequences of system calls, and the sequence that uses GnuTLS lessens 
entropy consumption and simplifies audits.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.