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, 29 Dec 2015 18:21:30 +0200 Message-ID: <83lh8ddy45.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451406081 14388 80.91.229.3 (29 Dec 2015 16:21:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2015 16:21:21 +0000 (UTC) Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com To: Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 29 17:21:10 2015 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 1aDx1K-0005S3-4W for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Dec 2015 17:21:10 +0100 Original-Received: from localhost ([::1]:49124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDx1J-00073E-Hj for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Dec 2015 11:21:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDx1F-000739-K0 for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2015 11:21:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDx1C-0008Li-EL for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2015 11:21:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDx1C-0008Le-Ai for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2015 11:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aDx1C-0008PV-4w for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2015 11:21: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: Tue, 29 Dec 2015 16:21: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.145140604732284 (code B ref 22202); Tue, 29 Dec 2015 16:21:02 +0000 Original-Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 16:20:47 +0000 Original-Received: from localhost ([127.0.0.1]:48813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDx0x-0008Oe-3u for submit@debbugs.gnu.org; Tue, 29 Dec 2015 11:20:47 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35040) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDx0v-0008OS-BD for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 11:20:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDx0m-0008E6-VC for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 11:20:40 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDx0m-0008E0-Q3; Tue, 29 Dec 2015 11:20:36 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4517 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aDx0m-000591-2R; Tue, 29 Dec 2015 11:20:36 -0500 In-reply-to: (message from Richard Copley on Tue, 29 Dec 2015 15:36:12 +0000) 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:110961 Archived-At: > Date: Tue, 29 Dec 2015 15:36:12 +0000 > From: Richard Copley > > > Please provide the necessary details for reproducing this problem and > > verifying the solution. What I'm missing: > > > > > 1. Be logged into the same Windows computer as someone else. > > > > How do you do that? I understand you are describing a situation where > > 2 users are logged into the same Windows system simultaneously using > > the same credentials, is that true? If so, how to create such a > > situation? > > I don't think that is possible; however, two /different/ accounts can > be logged in to a computer at the same time, via Remote Desktop or > Fast User Switching. Logging in via Remote Desktop usurps the system, AFAIK. So these possibilities are not relevant to the issue at hand. > > > 2. Have a process running that is notified whenever a process starts up > > > 3. Have them run `emacs --daemon' or invoke `server-start'. > > > 4. Use the knowledge of the current time and the server's PID to guess > > > the authentication key. > > > > I don't think we use the current time and PID for that, but even if we > > do, how do you get a hold of the time at the moment of the server > > creation to nanosecond resolution? Please tell how to do that. > > We use function "random" (see function "server-generate-key"); its > seed is typically set at startup using the current time and PID (see > "init_random()" in sysdep.c), so it's the time Emacs started that you > would want to know, not the time the server started. You can get the > start time (to the nearest second at least) and PID of any user's > processes using, e.g., Process Explorer. You need the time to nanosecond resolution to compute the seed. How do you do that? > I'm not sure what resolution timestamp we end up using as the seed. > gettime() might return microsecond timestamps in certain configurations. On MS-Windows, gettime calls gettimeofday, which returns the system clock in 100 nanosecond units. The actual resolution of the clock is between 1 ms and 10 ms, but I think it's still an impossible task to get the exact time we sample the clock during startup with such a high accuracy. > I can't speak for Demetri but it seems to me he's imagining an attacker > who is prepared to use a certain amount of brute force. Knowing or > guessing the Emacs start time within a few seconds would reduce the > search space. As I said, I don't see how such a user could even get access to a machine without my paying attention. And that if the services required for remote access have not been turned off to begin with.