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 #136 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>
Cc: rcopley <at> gmail.com, 22202 <at> debbugs.gnu.org, johnw <at> 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 16:39:03 -0800

On 01/19/2016 10:16 AM, Eli Zaretskii wrote:
>> 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.

There is no contradiction here. Although having multiple file 
descriptors for the same file is only a minor problem, that does not 
mean it is not a problem at all, nor does it mean that the minor problem 
is entirely in GnuTLS as opposed to being in the combination of GnuTLS 
and Emacs. I did not say GnuTLS's behavior is a misfeature or bug; such 
a characterization would go too far.

> You cannot be serious saying that a single call will deplete the
> system entropy.

Although the entropy will not be completely depleted, reading excess 
bytes from /dev/urandom can exhaust the entropy pool more quickly. On 
GNU/Linux, processes reading /dev/urandom can fairly quickly drain 
system entropy down to a couple hundred bits. Reads of /dev/random can 
then drain the remaining bits and subsequent reads will hang. Although 
the kernel eventually will reacquire system entropy, acquisition rates 
can be less than one bit per second, so reading excess data from 
/dev/urandom is not cost-free here.

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

We are not responsible for GnuTLS internals, but for audits we are 
responsible for explaining unusual behaviors. It's like many other 
aspects of libraries that Emacs uses: for example, although we are not 
responsible for ImageMagick internals, if those internals allocate a lot 
of memory and cause Emacs to hang or crash, we are responsible for the 
overall behavior.

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

We never really needed to audit the GnuTLS code in the first place. We 
went into it only because of concerns that GnuTLS might not do the right 
thing, due to lack of understanding about GnuTLS. These concerns have 
been addressed, and there should be no need to keep revisiting the issue.

> That trust needs now to be ascertained even if we don't use secure 
> communications from Emacs.

Sorry, I'm not following. If the point is that GnuTLS should be trusted 
for secure communications (which is relatively complicated) but not for 
generating nonces (which is relatively simple) then I don't see a sound 
basis for this worry. If GnuTLS can't be trusted for simple building 
blocks, why trust it for complex things? Especially when the complex 
things are based on the simple building blocks?

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

You can try running it both ways under "strace" in GNU/Linux. You should 
see different sequences of system calls involving /dev/urandom. That's 
what happened for me.

>> This is just a minor issue, one that has been blown all out of
>> proportion.
> This is unfair: if this minor issue was important enough for you to
> make those changes, then objecting to them cannot be considered
> "blowing it all out of proportion".

Yes, a simple objection to a minor change would not blow it all out of 
proportion. But this long thread is more than that.

Previous Next

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