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

Previous Next

Full log

View this message in rfc822 format

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

> Cc: 22202 <at> debbugs.gnu.org, rcopley <at> gmail.com, deng <at> randomsample.de
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 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.

You said it was a problem to have one more handle open, not I.  So
it's you who maintains this is a problem (a.k.a. "misfeature").  If
you are now saying it's okay to have the device open, then it's not a
problem to have it open twice for a short while.

IOW, please make up your mind whether this is an issue or not.

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

Now, _that's_ a stretch.  We only read /dev/urandom once, that's all.
You cannot be serious saying that a single call will deplete the
system entropy.

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

No, it doesn't.  We cannot be responsible for the internals of
3rd-party libraries.

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

Today, we do.  Tomorrow, it's anyone's guess.  Unless we audit their
code all the time.  Why should we?

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

That trust needs now to be ascertained even if we don't use secure
communications from Emacs.  So things got worse.

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

I've read the code and saw no differences.

Previous Next

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