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: Tue, 19 Jan 2016 18:24:00 +0200 Message-ID: <83y4blbkrj.fsf@gnu.org> References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453221160 28174 80.91.229.3 (19 Jan 2016 16:32:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 16:32:40 +0000 (UTC) Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de To: Paul Eggert , John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 19 17:32:28 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 1aLZCm-00052O-13 for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2016 17:32:28 +0100 Original-Received: from localhost ([::1]:37985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZCl-0001nv-Hl for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2016 11:32:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZ5e-0005aB-9s for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 11:25:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLZ5a-0006Du-18 for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 11:25:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZ5Z-0006Dk-V8 for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 11:25:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aLZ5Z-0003ig-PF for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 11:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Jan 2016 16:25: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.145322066314243 (code B ref 22202); Tue, 19 Jan 2016 16:25:01 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 16:24:23 +0000 Original-Received: from localhost ([127.0.0.1]:53902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZ4x-0003hf-3z for submit@debbugs.gnu.org; Tue, 19 Jan 2016 11:24:23 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56430) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZ4v-0003hT-NT for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 11:24:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLZ4p-00062C-OZ for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 11:24:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZ4Y-0005wV-Ss; Tue, 19 Jan 2016 11:23:58 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2184 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLZ4R-0003ld-LV; Tue, 19 Jan 2016 11:23:52 -0500 In-reply-to: <569DCAD4.30606@cs.ucla.edu> (message from Paul Eggert on Mon, 18 Jan 2016 21:34:12 -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:111747 Archived-At: > Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de > From: Paul Eggert > Date: Mon, 18 Jan 2016 21:34:12 -0800 > > 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 keeps /dev/urandom open indefinitely. So it's a bug or misfeature in GnuTLS. Not our concern. > 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. > 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. > 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. I see no reasons to tie these two together. The Emacs server is not about TLS communications, at least not by default. If GnuTLS were a library of RNGs, it would have been a different matter. But it isn't. We shouldn't depend so critically on 3rd party libraries for functionality that is unrelated or secondary to their goal. > So what is special about GnuTLS? > > GnuTLS already has the random data we need; other libraries don't. 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. It buys us nothing in terms of security and performance, while we sustain the price of having core functionality that must run at startup crucially depending on a 3rd party library we don't control. John, I feel this decision is wrong and the changes that prefer gnutls_rnd should be reverted. Maybe I'm the only one who cares, but then Paul is the only one who felt the need to make that change. I'd like to hear your take on this, please.