From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: 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 Organization: UCLA Computer Science Department Message-ID: <569ED727.5060509@cs.ucla.edu> References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <569E6D43.5080705@cs.ucla.edu> <83k2n5bfjv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453250427 20630 80.91.229.3 (20 Jan 2016 00:40:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 00:40:27 +0000 (UTC) Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de, johnw@gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 20 01:40:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aLgok-0003fF-Cv for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Jan 2016 01:40:10 +0100 Original-Received: from localhost ([::1]:39717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLgoj-00039j-Hg for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2016 19:40:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLgof-00039A-Ek for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 19:40:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLgoc-0003ye-7e for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 19:40:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLgoc-0003yX-3W for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 19:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aLgob-0006Xq-Tz for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 19:40:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Jan 2016 00:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22202 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 22202-submit@debbugs.gnu.org id=B22202.145325035325087 (code B ref 22202); Wed, 20 Jan 2016 00:40:01 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 20 Jan 2016 00:39:13 +0000 Original-Received: from localhost ([127.0.0.1]:54161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLgnp-0006WZ-Fb for submit@debbugs.gnu.org; Tue, 19 Jan 2016 19:39:13 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48429) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLgnn-0006WJ-KI for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 19:39:12 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BD0511608D3; Tue, 19 Jan 2016 16:39:05 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ze4aVy34rBHF; Tue, 19 Jan 2016 16:39:03 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A0272160D77; Tue, 19 Jan 2016 16:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m_O21_K9p-50; Tue, 19 Jan 2016 16:39:03 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 815591608D3; Tue, 19 Jan 2016 16:39:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <83k2n5bfjv.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111779 Archived-At: On 01/19/2016 10:16 AM, Eli Zaretskii wrote: >> Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de >> From: Paul Eggert >> 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.