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: Mon, 18 Jan 2016 12:50:12 -0800 Organization: UCLA Computer Science Department Message-ID: <569D5004.5080701@cs.ucla.edu> References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010408070103030800090806" X-Trace: ger.gmane.org 1453150283 2719 80.91.229.3 (18 Jan 2016 20:51:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 20:51:23 +0000 (UTC) Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 18 21:51: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 1aLGla-0002Xm-Il for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jan 2016 21:51:11 +0100 Original-Received: from localhost ([::1]:33643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLGla-0003pW-0q for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jan 2016 15:51:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLGlV-0003pC-SP for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 15:51:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLGlS-00014F-L1 for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 15:51:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLGlS-000143-I4 for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 15:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aLGlS-0000cK-97 for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 15:51: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: Mon, 18 Jan 2016 20:51: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.14531502232324 (code B ref 22202); Mon, 18 Jan 2016 20:51:02 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 20:50:23 +0000 Original-Received: from localhost ([127.0.0.1]:53214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLGkp-0000bQ-12 for submit@debbugs.gnu.org; Mon, 18 Jan 2016 15:50:23 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35538) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLGkm-0000bC-Ft for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 15:50:21 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 77007160E67; Mon, 18 Jan 2016 12:50:14 -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 ohUxZDFcHvOY; Mon, 18 Jan 2016 12:50:13 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8C9EA160E6B; Mon, 18 Jan 2016 12:50:13 -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 ErlPriks3rL3; Mon, 18 Jan 2016 12:50:13 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 618E5160E67; Mon, 18 Jan 2016 12:50:13 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <83fuxuevs2.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:111719 Archived-At: This is a multi-part message in MIME format. --------------010408070103030800090806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------010408070103030800090806 Content-Type: text/x-diff; name="t.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="t.diff" diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi index 3a9483a..28eb6b1 100644 --- a/doc/lispref/numbers.texi +++ b/doc/lispref/numbers.texi @@ -1252,9 +1252,9 @@ Random Numbers (@pxref{Integer Basics}). If @var{limit} is @code{t}, it means to choose a new seed as if Emacs -were restarting. The new seed will be set from the system entropy, if -that is available, or from the current time and Emacs process's PID -(@pxref{System Environment, emacs-pid}) if not. +were restarting, typically from the system entropy. On systems +lacking entropy pools, choose the seed from less-random volatile data +such as the current time. If @var{limit} is a string, it means to choose a new seed based on the string's contents. diff --git a/src/fns.c b/src/fns.c index 19fa440..86ad333 100644 --- a/src/fns.c +++ b/src/fns.c @@ -51,7 +51,7 @@ and `most-positive-fixnum', inclusive, are equally likely. With positive integer LIMIT, return random number in interval [0,LIMIT). With argument t, set the random number seed from the system's entropy -pool, or from the current time and pid if entropy is unavailable. +pool if available, otherwise from less-random volatile data such as the time. With a string argument, set the seed based on the string's contents. Other values of LIMIT are ignored. --------------010408070103030800090806--