From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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 17:45:33 +0200 Message-ID: <83fuxuevs2.fsf@gnu.org> References: <569BF8F7.3090904@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453131989 12544 80.91.229.3 (18 Jan 2016 15:46:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 15:46:29 +0000 (UTC) Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 18 16:46:18 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 1aLC0S-0001a7-HG for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jan 2016 16:46:12 +0100 Original-Received: from localhost ([::1]:60383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC0S-000100-2h for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jan 2016 10:46:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC0O-0000zt-EN for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 10:46:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLC0I-0000P2-Fj for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 10:46:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC0I-0000Or-Ct for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 10:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aLC0I-0001Hb-5M for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 10:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Jan 2016 15:46: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.14531319514911 (code B ref 22202); Mon, 18 Jan 2016 15:46:02 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 15:45:51 +0000 Original-Received: from localhost ([127.0.0.1]:52998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLC06-0001H9-Tp for submit@debbugs.gnu.org; Mon, 18 Jan 2016 10:45:51 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36228) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLC05-0001Gw-B8 for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 10:45:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLBzy-0000Ly-UP for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 10:45:44 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLBzk-0000IL-Uq; Mon, 18 Jan 2016 10:45:28 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1222 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLBzi-0000Cf-QZ; Mon, 18 Jan 2016 10:45:27 -0500 In-reply-to: <569BF8F7.3090904@cs.ucla.edu> (message from Paul Eggert on Sun, 17 Jan 2016 12:26:31 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:111706 Archived-At: > From: Paul Eggert > Cc: 22202@debbugs.gnu.org, Richard Copley , > demetriobenour@gmail.com, deng@randomsample.de > Date: Sun, 17 Jan 2016 12:26:31 -0800 > > Eli, thanks for improving the initial seed for (random t) in Emacs. I noticed that with this change, my Emacs was opening /dev/urandom twice, because GnuTLS does something similar during startup. Also, it was reading more data from /dev/urandom than it needed, due to stdio buffering. So I installed the attached patch, which defers to GnuTLS and falls back on doing things by hand (without stdio) only if GnuTLS is not available or fails. I assume this approach works under MS-Windows; if not please let me know and I'll try to fix it. I wish we'd discuss such things before committing and not after. What's the rush? It's not like Emacs was broken or something. It just isn't worth it. More to to the point, the more I think about this, the less I like this change. Here's why: . I see nothing wrong with having 2 (or more) independent reads from /dev/urandom: . GnuTLS is a separate library, so it's free to do that for its own purposes; we shouldn't care. Besides, what if tomorrow there will be a 3rd library that would need to access /dev/urandom? . Reading from /dev/urandom never blocks, so doing this one more time during startup should be a non-issue. . Calling gnutls_rnd makes Emacs dependent on GnuTLS in ways that we don't necessarily want: GnuTLS is a library for TLS, not for cryptography. What that function does on each platform is not documented anywhere in the GnuTLS manual that I could see; I needed to read the sources to find out. What if tomorrow GnuTLS changes its implementation? They are a separate project, they are not under any obligation to tell us. . This change means that we now load GnuTLS at startup, even if no TLS connections are or will be used. Why should we unnecessarily bloat our memory footprint, even in minor ways? . It breaks the Windows build -- since GnuTLS is dynamically loaded on Windows, any GnuTLS function must be called through macros set up in gnutls.c, which sysdep.c knows nothing about. (This is relatively simple to fix, but doing so requires adding yet more ugly #ifdef's to an already not-so-pretty little mess.) So I tend to just say NO here. Let's use the relatively simple code we had before (with your I/O changes, I don't object to those, of course), and leave GnuTLS to its own devices. WDYT? > Would you mind if I removed the newly-added details about current time and process ID from the documentation? The idea is that this is internal implementation detail that users should not rely on. I didn't really add anything: the fact that we used time and PID was spelled out in the function's doc string for the last 20-odd years. I just added that to the ELisp manual, to make it more consistent with the doc string, and also because it's hard to tell that we are using system entropy when available without saying anything about what we do when it isn't. (And IMO we should mention the system entropy because that's an important feature users should know about.) Why is it suddenly a concern that users will know that we use time and PID as fallback?