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

[Eli Zaretskii]

> Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 18 Jan 2016 12:50:12 -0800
> 
> > 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.

That's not what I meant.  You saw the code I committed just a few days
ago; it would be prudent to discuss your plans to change that.  We all
silently fix blunders and other trivial problems; this wasn't one of
them.  It wasn't a bug fix, either.  So there was no need to rush with
the commit.  Such conduct doesn't make us feel like a community.

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

Why is that a worry?  We use many libraries, some of them open and
read files.  What's to worry about?

> Also, it's two file descriptors (both open at the same time) when we
> can get by with just one.

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

It's a very simple wheel.  If you've seen their sources (I have), you
know that they do exactly the same, both on GNU/Linux and on
MS-Windows.

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

I don't think we should become experts on external libraries, and I
don't think we should track their development.  Where GnuTLS needs
security for its internal use, we should let it do what they see fit;
if they do that wrongly, the word will spread, and we will upgrade or
switch to another library.

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.  This is the core of
this bug report.  I don't think we should delegate that to an external
library whose main business is secure communications.  It's a
different discipline, different trade-offs, etc.

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

So what is special about GnuTLS?

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

We did that since 1993.  Isn't it a tad too late to worry about it?

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

A fallback is always worse than Plan A.  Everyone understands that,
even if they know nothing about randomness and PRNGs.

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

Frankly, it feels silly, but since you are so enthusiastic, who am I
to stand on your way?