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 23:09:57 +0200 Message-ID: <83h9iad26y.fsf@gnu.org> References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453151482 22226 80.91.229.3 (18 Jan 2016 21:11:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 21:11:22 +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 22:11: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 1aLH4x-0004LE-8W for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jan 2016 22:11:11 +0100 Original-Received: from localhost ([::1]:33687 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLH4w-0007yk-L8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jan 2016 16:11:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLH4s-0007yJ-Ts for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 16:11:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLH4o-0005PZ-KP for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 16:11:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLH4o-0005PV-GV for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 16:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aLH4o-00016K-AB for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 16:11: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 21:11: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.14531514154172 (code B ref 22202); Mon, 18 Jan 2016 21:11:02 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 21:10:15 +0000 Original-Received: from localhost ([127.0.0.1]:53218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLH42-00015B-N5 for submit@debbugs.gnu.org; Mon, 18 Jan 2016 16:10:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38950) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLH41-00014x-9S for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 16:10:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLH3u-000595-R8 for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 16:10:08 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLH3f-00053W-TA; Mon, 18 Jan 2016 16:09:51 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1651 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLH3f-00063k-2O; Mon, 18 Jan 2016 16:09:51 -0500 In-reply-to: <569D5004.5080701@cs.ucla.edu> (message from Paul Eggert on Mon, 18 Jan 2016 12:50: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:111720 Archived-At: > Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de > From: Paul Eggert > Date: Mon, 18 Jan 2016 12:50:12 -0800 > > > 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. That's not what I meant. You saw the code I committed just a few days ago; it would be prudent to discuss your plans to change that. We all silently fix blunders and other trivial problems; this wasn't one of them. It wasn't a bug fix, either. So there was no need to rush with the commit. Such conduct doesn't make us feel like a community. > > . 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. Why is that a worry? We use many libraries, some of them open and read files. What's to worry about? > Also, it's two file descriptors (both open at the same time) when we > can get by with just one. 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 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? It's a very simple wheel. If you've seen their sources (I have), you know that they do exactly the same, both on GNU/Linux and on MS-Windows. > 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. I don't think we should become experts on external libraries, and I don't think we should track their development. Where GnuTLS needs security for its internal use, we should let it do what they see fit; if they do that wrongly, the word will spread, and we will upgrade or switch to another library. 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. This is the core of this bug report. I don't think we should delegate that to an external library whose main business is secure communications. It's a different discipline, different trade-offs, etc. > > 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. So what is special about GnuTLS? > > 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. We did that since 1993. Isn't it a tad too late to worry about it? > One other thing, while we're nearby: the doc shouldn't assume that readers know > that time-of-day etc. is less random. A fallback is always worse than Plan A. Everyone understands that, even if they know nothing about randomness and PRNGs. > How about the attached patch? It should address these documentation concerns. Frankly, it feels silly, but since you are so enthusiastic, who am I to stand on your way?