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 09:07:15 -0800 Organization: UCLA Computer Science Department Message-ID: <569E6D43.5080705@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> 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 1453223303 32362 80.91.229.3 (19 Jan 2016 17:08:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 17:08:23 +0000 (UTC) Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de To: Eli Zaretskii , John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 19 18:08: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 1aLZlL-0007Hy-1Y for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2016 18:08:11 +0100 Original-Received: from localhost ([::1]:38413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZlK-0001DE-4N for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2016 12:08:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZlG-0001D7-WE for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 12:08:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLZlC-0001l4-QA for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 12:08:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZlC-0001kh-N4 for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 12:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aLZlC-0004mE-5E for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 12:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Jan 2016 17:08:02 +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.145322324418293 (code B ref 22202); Tue, 19 Jan 2016 17:08:02 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 17:07:24 +0000 Original-Received: from localhost ([127.0.0.1]:53940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZka-0004ky-8m for submit@debbugs.gnu.org; Tue, 19 Jan 2016 12:07:24 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47045) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZkY-0004kl-F4 for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 12:07:23 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A4534160E75; Tue, 19 Jan 2016 09:07:16 -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 LVZG-tly3tho; Tue, 19 Jan 2016 09:07:15 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 96ED3160D77; Tue, 19 Jan 2016 09:07:15 -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 eLOtysR863Nc; Tue, 19 Jan 2016 09:07:15 -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 7B5EC160E73; Tue, 19 Jan 2016 09:07:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <83y4blbkrj.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:111751 Archived-At: 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. 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. >> 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, since we're responsible for Emacs. Our explanation will also have to cover Emacs's added accesses, so minimizing them will be a win. >> 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. > >> 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. > 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.