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: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 22202 <at> debbugs.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: Mon, 18 Jan 2016 12:50:12 -0800

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> I wish we'd discuss such things before committing and not after.

Sorry, I missed the part of the discussion that talked about reading 
/dev/urandom in the first place.

>    . I see nothing wrong with having 2 (or more) independent reads from
>      /dev/urandom:

It's one more thing to worry about when auditing an Emacs trace. Also, it's two 
file descriptors (both open at the same time) when we can get by with just one.

>      . GnuTLS is a separate library, so it's free to do that for its
>        own purposes; we shouldn't care.

Yes and no. Yes, we shouldn't care how GnuTLS gets entropy; and no, because if 
GnuTLS is available we should be better off using its entropy source than 
rolling our own. The GnuTLS guys are far more expert in this stuff; why reinvent 
the wheel? And if the GnuTLS entropy source is busted, Emacs is already insecure 
in dozens of important ways, so using that source here shouldn't make matters 
significantly worse.

>	 Besides, what if tomorrow
>        there will be a 3rd library that would need to access
>        /dev/urandom?

Not our problem. As you say, libraries are free to do that for their own 
purposes, and we shouldn't care.

>    . GnuTLS is a library for TLS, not for cryptography.

GnuTLS is not just for TLS, it's for secure communications. Getting a nonce is a 
basic building block for such a library. They're not going to remove a basic 
building block.

>      What if tomorrow GnuTLS changes its implementation?

That's fine. We don't need to know the details of how GnuTLS gets its nonces. 
For example, if it starts using the RDRAND instruction available on Ivy Bridge 
and later Intel processors, more power to them. We shouldn't care.

>    . This change means that we now load GnuTLS at startup, even if no
>      TLS connections are or will be used.

That's already true on GNU and POSIXish platforms, so it's not a problem there. 
It is an issue on MS-Windows, though, so your change to avoid GnuTLS here on 
MS-Windows makes sense.

> Why is it suddenly a concern that users will know that we use time and
> PID as fallback?

Merely because we're in the neighborhood anyway and it's the first time I 
noticed that this detail was documented. The detail doesn't belong in the 
documentation; Emacs shouldn't promise that it'll use the PID, for example.

One other thing, while we're nearby: the doc shouldn't assume that readers know 
that time-of-day etc. is less random.

How about the attached patch? It should address these documentation concerns.

[t.diff (text/x-diff, attachment)]

Previous Next

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