From unknown Thu Aug 14 21:53:01 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#22202 <22202@debbugs.gnu.org> To: bug#22202 <22202@debbugs.gnu.org> Subject: Status: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Reply-To: bug#22202 <22202@debbugs.gnu.org> Date: Fri, 15 Aug 2025 04:53:01 +0000 retitle 22202 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random num= ber generator attack on Windows systems reassign 22202 emacs submitter 22202 Demetri Obenour severity 22202 normal tag 22202 security thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 05:08:03 2015 Received: (at submit) by debbugs.gnu.org; 18 Dec 2015 10:08:03 +0000 Received: from localhost ([127.0.0.1]:55144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9rxC-0004FR-0v for submit@debbugs.gnu.org; Fri, 18 Dec 2015 05:08:03 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52557) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9rxA-0004F8-Ap for submit@debbugs.gnu.org; Fri, 18 Dec 2015 05:08:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9rwz-0007AB-L3 for submit@debbugs.gnu.org; Fri, 18 Dec 2015 05:07:55 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9rwz-0007A7-HS for submit@debbugs.gnu.org; Fri, 18 Dec 2015 05:07:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9rww-000804-QA for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 05:07:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9rwr-000799-9i for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 05:07:46 -0500 Received: from mail-yk0-x231.google.com ([2607:f8b0:4002:c07::231]:34008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9rwr-00078o-4t for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2015 05:07:41 -0500 Received: by mail-yk0-x231.google.com with SMTP id p130so52138343yka.1 for ; Fri, 18 Dec 2015 02:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type; bh=Rta7aSu62KTe4rxxZnVwwgmgwRbUj2+GSLCdLV6WVTU=; b=A334VUb/OfEs/YChyGVCYipUi+i4QXwFGmbgYnz8WvBGSflCAaRImOFh86akZXX3nL vxGcm1sk/DCODMQ8FJyXhfC/muvOuYbdPEVml21T0rcl8Si86vDAivFE+PB43xuhvv61 FekLUjZBm8G9EF50+dZJWvbeUBVFcY+L/WIPrT9tEHK/cg9lR4mskZgs0oD6QxVhOwKK hGM6KjWYuHzHir1wIJ9I62Pma81loGXjAaPyFdIf8rxLlAQpTPXpBqP91NQSYIMukTc7 /5e+jjdPCkW3afMGL41zBt9DnM3zm5y/VlO+1LWoljcxrl3Ee0v1VMxl1obuy+sjTECq Mf5A== X-Received: by 10.129.110.84 with SMTP id j81mr2027042ywc.151.1450433260450; Fri, 18 Dec 2015 02:07:40 -0800 (PST) Received: from localhost.hsd1.tn.comcast.net ([2601:840:8101:227f:2ae3:47ff:fe02:d99e]) by smtp.gmail.com with ESMTPSA id u63sm14984344ywf.4.2015.12.18.02.07.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Dec 2015 02:07:39 -0800 (PST) From: Demetri Obenour To: bug-gnu-emacs@gnu.org Subject: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Date: Fri, 18 Dec 2015 05:05:09 -0500 Message-ID: <87h9jg5ay2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) 1. Be logged into the same Windows computer as someone else. 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. 5. Connect to the other user's Emacs server. 6. Execute arbitrary code with the other user's privileges. Emacs does not provide a cryptographically secure random number generator that can be used on all platforms (including Windows). On Unix-like systems, one can use `/dev/urandom', but Windows requires a Windows API call to obtain entropy, which is not accessable from Emacs. Emacs should provide a CSPRNG on ALL platforms, and this should be used for the secret in the Emacs server. This is a blocker to the use of the Emacs server on Windows. In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.6) of 2015-09-14 on buildvm-10.phx2.fedoraproject.org Windowing system distributor `Fedora Project', version 11.0.11704000 System Description: Fedora release 22 (Twenty Two) Configured using: `configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3 --with-gpm=no build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro' Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Tar Minor modes in effect: display-time-mode: t display-battery-mode: t global-linum-mode: t linum-mode: t global-semanticdb-minor-mode: t global-semantic-idle-scheduler-mode: t show-paren-mode: t semantic-mode: t global-auto-complete-mode: t tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t global-visual-line-mode: t visual-line-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Type "q" to delete help window. user-error: Beginning of history; no preceding item Quit [2 times] user-error: Beginning of history; no preceding item Making completion list... File emacs-24.4.tar.xz is large (37.9M), really open? (y or n) y XZ uncompressing emacs-24.4.tar.xz...done Parsing tar file...done Making completion list... Load-path shadows: /home/dobenour/.emacs.d/elpa/ada-mode-5.1.8/ada-ref-man hides /home/dobenour/.emacs.d/elpa/ada-ref-man-2012.0/ada-ref-man /home/dobenour/.emacs.d/elpa/auctex-11.88.6/prv-emacs hides /usr/share/emacs/site-lisp/auctex/prv-emacs /home/dobenour/.emacs.d/elpa/auctex-11.88.6/context-en hides /usr/share/emacs/site-lisp/auctex/context-en /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar /home/dobenour/.emacs.d/elpa/auctex-11.88.6/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp /home/dobenour/.emacs.d/elpa/auctex-11.88.6/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf /home/dobenour/.emacs.d/elpa/auctex-11.88.6/latex hides /usr/share/emacs/site-lisp/auctex/latex /home/dobenour/.emacs.d/elpa/auctex-11.88.6/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style /home/dobenour/.emacs.d/elpa/auctex-11.88.6/plain-tex hides /usr/share/emacs/site-lisp/auctex/plain-tex /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold /home/dobenour/.emacs.d/elpa/auctex-11.88.6/context hides /usr/share/emacs/site-lisp/auctex/context /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik /home/dobenour/.emacs.d/elpa/auctex-11.88.6/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex /home/dobenour/.emacs.d/elpa/auctex-11.88.6/preview hides /usr/share/emacs/site-lisp/auctex/preview /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex hides /usr/share/emacs/site-lisp/auctex/tex /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info /home/dobenour/.emacs.d/elpa/auctex-11.88.6/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt /home/dobenour/.emacs.d/elpa/auctex-11.88.6/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite /home/dobenour/.emacs.d/elpa/auctex-11.88.6/tex-site hides /usr/share/emacs/site-lisp/tex-site /home/dobenour/.emacs.d/elpa/auctex-11.88.6/auctex hides /usr/share/emacs/site-lisp/site-start.d/auctex /usr/share/emacs/site-lisp/site-start.d/slime-autoloads hides /usr/share/emacs/site-lisp/slime/slime-autoloads /usr/share/emacs/site-lisp/site-start.d/slime hides /usr/share/emacs/site-lisp/slime/slime /usr/share/emacs/site-lisp/site-start.d/hyperspec hides /usr/share/emacs/site-lisp/slime/hyperspec /usr/share/emacs/site-lisp/site-start.d/maxima-modes hides /usr/share/emacs/site-lisp/maxima/site_start.d/maxima-modes /home/dobenour/.emacs.d/elpa/ada-mode-5.1.8/ada-mode hides /usr/share/emacs/24.5/lisp/progmodes/ada-mode /home/dobenour/.emacs.d/elpa/ada-mode-5.1.8/ada-xref hides /usr/share/emacs/24.5/lisp/progmodes/ada-xref /home/dobenour/.emacs.d/elpa/ada-mode-5.1.8/ada-prj hides /usr/share/emacs/24.5/lisp/progmodes/ada-prj /home/dobenour/.emacs.d/elpa/ada-mode-5.1.8/ada-stmt hides /usr/share/emacs/24.5/lisp/progmodes/ada-stmt /home/dobenour/.emacs.d/elpa/org-20150608/ob-exp hides /usr/share/emacs/24.5/lisp/org/ob-exp /home/dobenour/.emacs.d/elpa/org-20150608/ob-emacs-lisp hides /usr/share/emacs/24.5/lisp/org/ob-emacs-lisp /home/dobenour/.emacs.d/elpa/org-20150608/ob-js hides /usr/share/emacs/24.5/lisp/org/ob-js /home/dobenour/.emacs.d/elpa/org-20150608/org-loaddefs hides /usr/share/emacs/24.5/lisp/org/org-loaddefs /home/dobenour/.emacs.d/elpa/org-20150608/ob-io hides /usr/share/emacs/24.5/lisp/org/ob-io /home/dobenour/.emacs.d/elpa/org-20150608/org-gnus hides /usr/share/emacs/24.5/lisp/org/org-gnus /home/dobenour/.emacs.d/elpa/org-20150608/ob-screen hides /usr/share/emacs/24.5/lisp/org/ob-screen /home/dobenour/.emacs.d/elpa/org-20150608/ob-octave hides /usr/share/emacs/24.5/lisp/org/ob-octave /home/dobenour/.emacs.d/elpa/org-20150608/org-docview hides /usr/share/emacs/24.5/lisp/org/org-docview /home/dobenour/.emacs.d/elpa/org-20150608/org-faces hides /usr/share/emacs/24.5/lisp/org/org-faces /home/dobenour/.emacs.d/elpa/org-20150608/ox-latex hides /usr/share/emacs/24.5/lisp/org/ox-latex /home/dobenour/.emacs.d/elpa/org-20150608/ox-org hides /usr/share/emacs/24.5/lisp/org/ox-org /home/dobenour/.emacs.d/elpa/org-20150608/org hides /usr/share/emacs/24.5/lisp/org/org /home/dobenour/.emacs.d/elpa/org-20150608/ox-texinfo hides /usr/share/emacs/24.5/lisp/org/ox-texinfo /home/dobenour/.emacs.d/elpa/org-20150608/ob hides /usr/share/emacs/24.5/lisp/org/ob /home/dobenour/.emacs.d/elpa/org-20150608/ob-haskell hides /usr/share/emacs/24.5/lisp/org/ob-haskell /home/dobenour/.emacs.d/elpa/org-20150608/ob-comint hides /usr/share/emacs/24.5/lisp/org/ob-comint /home/dobenour/.emacs.d/elpa/org-20150608/org-crypt hides /usr/share/emacs/24.5/lisp/org/org-crypt /home/dobenour/.emacs.d/elpa/org-20150608/org-bbdb hides /usr/share/emacs/24.5/lisp/org/org-bbdb /home/dobenour/.emacs.d/elpa/org-20150608/org-colview hides /usr/share/emacs/24.5/lisp/org/org-colview /home/dobenour/.emacs.d/elpa/org-20150608/ob-sqlite hides /usr/share/emacs/24.5/lisp/org/ob-sqlite /home/dobenour/.emacs.d/elpa/org-20150608/ob-tangle hides /usr/share/emacs/24.5/lisp/org/ob-tangle /home/dobenour/.emacs.d/elpa/org-20150608/org-protocol hides /usr/share/emacs/24.5/lisp/org/org-protocol /home/dobenour/.emacs.d/elpa/org-20150608/org-entities hides /usr/share/emacs/24.5/lisp/org/org-entities /home/dobenour/.emacs.d/elpa/org-20150608/ob-sql hides /usr/share/emacs/24.5/lisp/org/ob-sql /home/dobenour/.emacs.d/elpa/org-20150608/ob-java hides /usr/share/emacs/24.5/lisp/org/ob-java /home/dobenour/.emacs.d/elpa/org-20150608/ob-perl hides /usr/share/emacs/24.5/lisp/org/ob-perl /home/dobenour/.emacs.d/elpa/org-20150608/ob-lisp hides /usr/share/emacs/24.5/lisp/org/ob-lisp /home/dobenour/.emacs.d/elpa/org-20150608/org-capture hides /usr/share/emacs/24.5/lisp/org/org-capture /home/dobenour/.emacs.d/elpa/org-20150608/org-list hides /usr/share/emacs/24.5/lisp/org/org-list /home/dobenour/.emacs.d/elpa/org-20150608/ob-core hides /usr/share/emacs/24.5/lisp/org/ob-core /home/dobenour/.emacs.d/elpa/org-20150608/ob-picolisp hides /usr/share/emacs/24.5/lisp/org/ob-picolisp /home/dobenour/.emacs.d/elpa/org-20150608/ob-ledger hides /usr/share/emacs/24.5/lisp/org/ob-ledger /home/dobenour/.emacs.d/elpa/org-20150608/ob-R hides /usr/share/emacs/24.5/lisp/org/ob-R /home/dobenour/.emacs.d/elpa/org-20150608/org-mhe hides /usr/share/emacs/24.5/lisp/org/org-mhe /home/dobenour/.emacs.d/elpa/org-20150608/ob-sh hides /usr/share/emacs/24.5/lisp/org/ob-sh /home/dobenour/.emacs.d/elpa/org-20150608/org-mobile hides /usr/share/emacs/24.5/lisp/org/org-mobile /home/dobenour/.emacs.d/elpa/org-20150608/org-mouse hides /usr/share/emacs/24.5/lisp/org/org-mouse /home/dobenour/.emacs.d/elpa/org-20150608/org-timer hides /usr/share/emacs/24.5/lisp/org/org-timer /home/dobenour/.emacs.d/elpa/org-20150608/ob-sass hides /usr/share/emacs/24.5/lisp/org/ob-sass /home/dobenour/.emacs.d/elpa/org-20150608/org-irc hides /usr/share/emacs/24.5/lisp/org/org-irc /home/dobenour/.emacs.d/elpa/org-20150608/org-info hides /usr/share/emacs/24.5/lisp/org/org-info /home/dobenour/.emacs.d/elpa/org-20150608/org-w3m hides /usr/share/emacs/24.5/lisp/org/org-w3m /home/dobenour/.emacs.d/elpa/org-20150608/ob-scheme hides /usr/share/emacs/24.5/lisp/org/ob-scheme /home/dobenour/.emacs.d/elpa/org-20150608/ox-md hides /usr/share/emacs/24.5/lisp/org/ox-md /home/dobenour/.emacs.d/elpa/org-20150608/org-eshell hides /usr/share/emacs/24.5/lisp/org/org-eshell /home/dobenour/.emacs.d/elpa/org-20150608/org-datetree hides /usr/share/emacs/24.5/lisp/org/org-datetree /home/dobenour/.emacs.d/elpa/org-20150608/org-attach hides /usr/share/emacs/24.5/lisp/org/org-attach /home/dobenour/.emacs.d/elpa/org-20150608/ob-org hides /usr/share/emacs/24.5/lisp/org/ob-org /home/dobenour/.emacs.d/elpa/org-20150608/org-bibtex hides /usr/share/emacs/24.5/lisp/org/org-bibtex /home/dobenour/.emacs.d/elpa/org-20150608/ox-publish hides /usr/share/emacs/24.5/lisp/org/ox-publish /home/dobenour/.emacs.d/elpa/org-20150608/ob-matlab hides /usr/share/emacs/24.5/lisp/org/ob-matlab /home/dobenour/.emacs.d/elpa/org-20150608/ob-ruby hides /usr/share/emacs/24.5/lisp/org/ob-ruby /home/dobenour/.emacs.d/elpa/org-20150608/org-rmail hides /usr/share/emacs/24.5/lisp/org/org-rmail /home/dobenour/.emacs.d/elpa/org-20150608/org-ctags hides /usr/share/emacs/24.5/lisp/org/org-ctags /home/dobenour/.emacs.d/elpa/org-20150608/org-element hides /usr/share/emacs/24.5/lisp/org/org-element /home/dobenour/.emacs.d/elpa/org-20150608/ob-python hides /usr/share/emacs/24.5/lisp/org/ob-python /home/dobenour/.emacs.d/elpa/org-20150608/org-footnote hides /usr/share/emacs/24.5/lisp/org/org-footnote /home/dobenour/.emacs.d/elpa/org-20150608/ob-mscgen hides /usr/share/emacs/24.5/lisp/org/ob-mscgen /home/dobenour/.emacs.d/elpa/org-20150608/org-inlinetask hides /usr/share/emacs/24.5/lisp/org/org-inlinetask /home/dobenour/.emacs.d/elpa/org-20150608/ob-plantuml hides /usr/share/emacs/24.5/lisp/org/ob-plantuml /home/dobenour/.emacs.d/elpa/org-20150608/ob-latex hides /usr/share/emacs/24.5/lisp/org/ob-latex /home/dobenour/.emacs.d/elpa/org-20150608/ox-man hides /usr/share/emacs/24.5/lisp/org/ox-man /home/dobenour/.emacs.d/elpa/org-20150608/org-habit hides /usr/share/emacs/24.5/lisp/org/org-habit /home/dobenour/.emacs.d/elpa/org-20150608/org-clock hides /usr/share/emacs/24.5/lisp/org/org-clock /home/dobenour/.emacs.d/elpa/org-20150608/ob-asymptote hides /usr/share/emacs/24.5/lisp/org/ob-asymptote /home/dobenour/.emacs.d/elpa/org-20150608/org-macro hides /usr/share/emacs/24.5/lisp/org/org-macro /home/dobenour/.emacs.d/elpa/org-20150608/ob-scala hides /usr/share/emacs/24.5/lisp/org/ob-scala /home/dobenour/.emacs.d/elpa/org-20150608/org-install hides /usr/share/emacs/24.5/lisp/org/org-install /home/dobenour/.emacs.d/elpa/org-20150608/ox-html hides /usr/share/emacs/24.5/lisp/org/ox-html /home/dobenour/.emacs.d/elpa/org-20150608/org-compat hides /usr/share/emacs/24.5/lisp/org/org-compat /home/dobenour/.emacs.d/elpa/org-20150608/ox-beamer hides /usr/share/emacs/24.5/lisp/org/ox-beamer /home/dobenour/.emacs.d/elpa/org-20150608/org-feed hides /usr/share/emacs/24.5/lisp/org/org-feed /home/dobenour/.emacs.d/elpa/org-20150608/org-id hides /usr/share/emacs/24.5/lisp/org/org-id /home/dobenour/.emacs.d/elpa/org-20150608/ob-lilypond hides /usr/share/emacs/24.5/lisp/org/ob-lilypond /home/dobenour/.emacs.d/elpa/org-20150608/org-src hides /usr/share/emacs/24.5/lisp/org/org-src /home/dobenour/.emacs.d/elpa/org-20150608/org-macs hides /usr/share/emacs/24.5/lisp/org/org-macs /home/dobenour/.emacs.d/elpa/org-20150608/ob-clojure hides /usr/share/emacs/24.5/lisp/org/ob-clojure /home/dobenour/.emacs.d/elpa/org-20150608/ob-maxima hides /usr/share/emacs/24.5/lisp/org/ob-maxima /home/dobenour/.emacs.d/elpa/org-20150608/ob-css hides /usr/share/emacs/24.5/lisp/org/ob-css /home/dobenour/.emacs.d/elpa/org-20150608/org-plot hides /usr/share/emacs/24.5/lisp/org/org-plot /home/dobenour/.emacs.d/elpa/org-20150608/org-indent hides /usr/share/emacs/24.5/lisp/org/org-indent /home/dobenour/.emacs.d/elpa/org-20150608/org-archive hides /usr/share/emacs/24.5/lisp/org/org-archive /home/dobenour/.emacs.d/elpa/org-20150608/org-pcomplete hides /usr/share/emacs/24.5/lisp/org/org-pcomplete /home/dobenour/.emacs.d/elpa/org-20150608/ob-makefile hides /usr/share/emacs/24.5/lisp/org/ob-makefile /home/dobenour/.emacs.d/elpa/org-20150608/ox-icalendar hides /usr/share/emacs/24.5/lisp/org/ox-icalendar /home/dobenour/.emacs.d/elpa/org-20150608/org-agenda hides /usr/share/emacs/24.5/lisp/org/org-agenda /home/dobenour/.emacs.d/elpa/org-20150608/ob-table hides /usr/share/emacs/24.5/lisp/org/ob-table /home/dobenour/.emacs.d/elpa/org-20150608/ob-eval hides /usr/share/emacs/24.5/lisp/org/ob-eval /home/dobenour/.emacs.d/elpa/org-20150608/ox hides /usr/share/emacs/24.5/lisp/org/ox /home/dobenour/.emacs.d/elpa/org-20150608/ob-awk hides /usr/share/emacs/24.5/lisp/org/ob-awk /home/dobenour/.emacs.d/elpa/org-20150608/ox-odt hides /usr/share/emacs/24.5/lisp/org/ox-odt /home/dobenour/.emacs.d/elpa/org-20150608/ob-lob hides /usr/share/emacs/24.5/lisp/org/ob-lob /home/dobenour/.emacs.d/elpa/org-20150608/ox-ascii hides /usr/share/emacs/24.5/lisp/org/ox-ascii /home/dobenour/.emacs.d/elpa/org-20150608/org-table hides /usr/share/emacs/24.5/lisp/org/org-table /home/dobenour/.emacs.d/elpa/org-20150608/ob-shen hides /usr/share/emacs/24.5/lisp/org/ob-shen /home/dobenour/.emacs.d/elpa/org-20150608/ob-keys hides /usr/share/emacs/24.5/lisp/org/ob-keys /home/dobenour/.emacs.d/elpa/org-20150608/ob-calc hides /usr/share/emacs/24.5/lisp/org/ob-calc /home/dobenour/.emacs.d/elpa/org-20150608/ob-ocaml hides /usr/share/emacs/24.5/lisp/org/ob-ocaml /home/dobenour/.emacs.d/elpa/org-20150608/org-version hides /usr/share/emacs/24.5/lisp/org/org-version /home/dobenour/.emacs.d/elpa/org-20150608/ob-C hides /usr/share/emacs/24.5/lisp/org/ob-C /home/dobenour/.emacs.d/elpa/org-20150608/ob-ditaa hides /usr/share/emacs/24.5/lisp/org/ob-ditaa /home/dobenour/.emacs.d/elpa/org-20150608/ob-ref hides /usr/share/emacs/24.5/lisp/org/ob-ref /home/dobenour/.emacs.d/elpa/org-20150608/ob-fortran hides /usr/share/emacs/24.5/lisp/org/ob-fortran /home/dobenour/.emacs.d/elpa/org-20150608/ob-dot hides /usr/share/emacs/24.5/lisp/org/ob-dot /home/dobenour/.emacs.d/elpa/org-20150608/ob-gnuplot hides /usr/share/emacs/24.5/lisp/org/ob-gnuplot Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils tar-mode jka-compr eieio-opt speedbar sb-image dframe help-mode info package julia-mode ert find-func ewoc debug rx tls server idris-autoloads toml-mode-init rust-mode-autoloads time battery linum semantic/db-mode semantic/db eieio-base semantic/idle semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt saveplace paren semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw eieio eieio-core mode-local cedet cus-start cus-load vc vc-dispatcher advice u-vm-color vm-autoloads vm-vars vm-version slime warnings byte-opt bytecomp byte-compile cconv derived cl-extra help-fns easy-mmode easymenu pp comint ansi-color ring slime-autoloads preview-latex proof-site proof-autoloads pg-vars hyperspec cl-macs thingatpt browse-url cl gv bbdb-loaddefs auto-complete-config auto-complete edmacro kmacro cl-loaddefs cl-lib popup tex-site auto-loads agda2 time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) Memory information: ((conses 16 250685 11999) (symbols 48 31904 0) (miscs 40 5369 181) (strings 32 64890 8146) (string-bytes 1 1659171) (vectors 16 23573) (vector-slots 8 581629 6882) (floats 8 129 250) (intervals 56 10649 30) (buffers 960 16) (heap 1024 52593 2624)) From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 18 05:46:13 2015 Received: (at 22202) by debbugs.gnu.org; 18 Dec 2015 10:46:13 +0000 Received: from localhost ([127.0.0.1]:55170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9sY9-00059T-5B for submit@debbugs.gnu.org; Fri, 18 Dec 2015 05:46:13 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33073) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a9sY8-00059I-EH for 22202@debbugs.gnu.org; Fri, 18 Dec 2015 05:46:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9sY0-0008ID-1k for 22202@debbugs.gnu.org; Fri, 18 Dec 2015 05:46:07 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9sXz-0008I8-Us; Fri, 18 Dec 2015 05:46:03 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1781 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1a9sXz-0004do-Bw; Fri, 18 Dec 2015 05:46:03 -0500 Date: Fri, 18 Dec 2015 12:46:26 +0200 Message-Id: <8337v0xce5.fsf@gnu.org> From: Eli Zaretskii To: Demetri Obenour In-reply-to: <87h9jg5ay2.fsf@gmail.com> (message from Demetri Obenour on Fri, 18 Dec 2015 05:05:09 -0500) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <87h9jg5ay2.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Demetri Obenour > Date: Fri, 18 Dec 2015 05:05:09 -0500 > > > 1. Be logged into the same Windows computer as someone else. > 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. > 5. Connect to the other user's Emacs server. > 6. Execute arbitrary code with the other user's privileges. 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? > 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. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 10:36:20 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 15:36:20 +0000 Received: from localhost ([127.0.0.1]:48797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDwJv-0007Ep-S6 for submit@debbugs.gnu.org; Tue, 29 Dec 2015 10:36:20 -0500 Received: from mail-yk0-f171.google.com ([209.85.160.171]:33068) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDwJu-0007Eb-3H for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 10:36:18 -0500 Received: by mail-yk0-f171.google.com with SMTP id k129so109606009yke.0 for <22202@debbugs.gnu.org>; Tue, 29 Dec 2015 07:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8JRmQ+4M4aGddBVKsc5cAwEAOxasOK7/YTzteV3S29E=; b=ruQV4A/IDn9hng8HjZU7Dkq05Ekh7zCuslSUb5GyIuQQzhXQLvzqxOgt7AzRFpyDl3 NxfhF4kF11LdYaf48GtSjRot9zzz1MWalSYSBPg13yUGwxFG914gzw6SLF283Ru96wWY qAG9CjeHtyn03fU3pV/zbDUAaqgOFyEsa+yQMbTNGrCU9F39nhSiyE3KMeDeB8Ihcamx 4yZemyGFm8SdkXPlMu366M2KkMbOLJfvASzSjwgN8556Q/M/S/AqSFYRISb9AdfeC5bU QKeITp4giuBGP1vvMBhRZr1tMbOZGspLRubQWk3jKuZax54IdlN+88Jv/xMEMj1wGNTz u7rA== MIME-Version: 1.0 X-Received: by 10.129.19.214 with SMTP id 205mr45378110ywt.136.1451403372631; Tue, 29 Dec 2015 07:36:12 -0800 (PST) Received: by 10.37.207.214 with HTTP; Tue, 29 Dec 2015 07:36:12 -0800 (PST) Date: Tue, 29 Dec 2015 15:36:12 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: Eli Zaretskii , Demetri Obenour , 22202@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > 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. (If the computer is a Remote Desktop server then two users can be simultaneously interacting with their desktops, in separate sessions. That's not at all uncommon in a business environment, but I don't think it's relevant to this question.) > > 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. I'm not sure what resolution timestamp we end up using as the seed. gettime() might return microsecond timestamps in certain configurations. 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 11:20:47 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 16:20:47 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Tue, 29 Dec 2015 18:21:30 +0200 Message-Id: <83lh8ddy45.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Tue, 29 Dec 2015 15:36:12 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 12:44:55 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 17:44:55 +0000 Received: from localhost ([127.0.0.1]:48870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDyKN-0002Bz-7y for submit@debbugs.gnu.org; Tue, 29 Dec 2015 12:44:55 -0500 Received: from mail-yk0-f182.google.com ([209.85.160.182]:33233) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDyKL-0002Bm-CF for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 12:44:53 -0500 Received: by mail-yk0-f182.google.com with SMTP id k129so112840505yke.0 for <22202@debbugs.gnu.org>; Tue, 29 Dec 2015 09:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w4FRoQeZDHelDq/A0b+ipiVr9xt+TNPMeyoqA7bxccE=; b=cRINGNPY687NZHnlvG7LTGbWmVB1aMz55v9GYuj6SV/PtCMsQygDSjHyUEX62iN+wf 5OZqEa5UTZqTw68sSabFA9FjngwXkFaFtVbq4X4vhvJQgBoQcPtepWFN6xpKE/RKT9rE zEkqDonBExkheh5KJvHfuLx2xmOT9YmsZQh+MKjHT/bA0Fbp0LNzCsaI7UBAW4QFNoha IjR/PyewGXwmKIiqsiYO1cZT9vQfuqK5zZreYunVq6GS55lsmQBZ7oevi808eIGRqTKY BAoPVeZpYKmq4yfgcviZ29GcKeXOeGI2OjYXRSD237sSM43IaBD+92Iaeb2A+Ix1vHf7 NopQ== MIME-Version: 1.0 X-Received: by 10.129.33.65 with SMTP id h62mr44724708ywh.139.1451411087861; Tue, 29 Dec 2015 09:44:47 -0800 (PST) Received: by 10.37.207.214 with HTTP; Tue, 29 Dec 2015 09:44:47 -0800 (PST) In-Reply-To: <83lh8ddy45.fsf@gnu.org> References: <83lh8ddy45.fsf@gnu.org> Date: Tue, 29 Dec 2015 17:44:47 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetri Obenour X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 29 December 2015 at 16:21, Eli Zaretskii wrote: >> 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. That is definitely not correct. In some configurations several users can connect via remote desktop. I do this every day. It /might/ be necessary to have a "Professional" and/or Server edition of Windows. A licensed Terminal Server supports dozens of sessions at once. Fast User Switching is a different thing. (Type CTRL-ALT-DEL and click "Switch User".) That, too, might require "Professional". >> > > 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 haven't tried, but the MSDN docs for GetProcessTimes say it returns the start time in 100 ns units. I'd guess that's what Process Explorer uses. >> 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. Perhaps you don't need to. Brute force. (Maybe that's ridiculous. I haven't tried to do the sums. Trying 100 to 1000 different values doesn't sound too hard.) >> 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. With respect, that's not correct (explained above). > And that if the services > required for remote access have not been turned off to begin with. Yes obviously, but many organizations do have Remote Desktop servers their staff can (or must) connect to. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 15:01:03 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 20:01:03 +0000 Received: from localhost ([127.0.0.1]:48922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE0S7-0007SP-1C for submit@debbugs.gnu.org; Tue, 29 Dec 2015 15:01:03 -0500 Received: from randomsample.de ([5.45.97.173]:39200) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE0S4-0007Rs-P5 for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 15:01:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=fHDMs+UaqMtFzVmGWo3hZei3uB3cgld4R6G1PdWN3bI=; b=UqNtZ2aSjXDbWBTXT1iUMme1WvoriY4tAOC88l5sv++kEzLBz0oU4j+yhlmVqbwH3L84cNf4lzeiKBlWNdqTLLWkDWTibbaR5qXuhgc2vRO0iEE7/b56Bh6dcE6ey5aN; Received: from ip4d1494ed.dynamic.kabel-deutschland.de ([77.20.148.237] helo=isaac.fritz.box) by randomsample.de with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aE0S3-0006JT-85; Tue, 29 Dec 2015 21:00:59 +0100 From: David Engster To: Richard Copley Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems In-Reply-To: (Richard Copley's message of "Tue, 29 Dec 2015 17:44:47 +0000") References: <83lh8ddy45.fsf@gnu.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux) Date: Tue, 29 Dec 2015 21:00:55 +0100 Message-ID: <8760zh81oo.fsf@isaac.fritz.box> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: Eli Zaretskii , 22202@debbugs.gnu.org, Demetri Obenour X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Richard Copley writes: > On 29 December 2015 at 16:21, Eli Zaretskii wrote: >>> 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. > > That is definitely not correct. In some configurations several users > can connect via remote desktop. I do this every day. It /might/ be > necessary to have a "Professional" and/or Server edition of Windows. > A licensed Terminal Server supports dozens of sessions at once. That's correct (it requires a Windows Server with enabled terminal services), but each user session has of course its own process space, so I don't see how the described attack could work there. -David From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 16:23:03 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 21:23:03 +0000 Received: from localhost ([127.0.0.1]:49001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE1jS-0004UA-Vu for submit@debbugs.gnu.org; Tue, 29 Dec 2015 16:23:03 -0500 Received: from mail-yk0-f171.google.com ([209.85.160.171]:34930) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE1jQ-0004TV-LY for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 16:23:00 -0500 Received: by mail-yk0-f171.google.com with SMTP id x67so138701702ykd.2 for <22202@debbugs.gnu.org>; Tue, 29 Dec 2015 13:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JWY3nYu1ukYkJbRO6dfc8lAveTN+2UvaG2LhfX8/zCc=; b=w2R9g4LlraYwKlPoTmwijG5x1frUcT23tSXf3otbJnuBWOFUDQlLHeOqbk/UdYudOy C1KJVWmBnax0maXGeu8rUogL+2dMj9O66bPoEIyGSgSNG5UJQhuu7acwA60+EJKdhQ4J mXAbyXFKErfoQRFULNZsIMW+R8ZCglogEK5SScOcoOQZViXlQcmiEQenH9R/dMzTF33B vQdjyvjEbuf1di1Wi92F1FcY2Gi14YMgqo1pZOcpHKEVx3oN/SdCfFMg07wONG0nZv4j lKXMHadwuIx2hKb/xBAgiMAp2zph6EFliPUIOJHFwhVaninvnNTeOsvLnVpHLG0xMprk emnA== MIME-Version: 1.0 X-Received: by 10.129.53.66 with SMTP id c63mr45217503ywa.138.1451424175232; Tue, 29 Dec 2015 13:22:55 -0800 (PST) Received: by 10.37.207.214 with HTTP; Tue, 29 Dec 2015 13:22:55 -0800 (PST) In-Reply-To: <8760zh81oo.fsf@isaac.fritz.box> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> Date: Tue, 29 Dec 2015 21:22:55 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: David Engster Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: Eli Zaretskii , 22202@debbugs.gnu.org, Demetri Obenour X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> [...] > > That's correct (it requires a Windows Server with enabled terminal > services), but each user session has of course its own process space, so > I don't see how the described attack could work there. Not sure what you mean by process space. As an unprivileged user you can find other users' Emacs processes without any effort (using tasklist.exe, for example). If you know on what port an Emacs server is listening (which is admittedly a difficulty), you can send bytes to it. I've just done so as an experiment. (I was driving both sessions so I knew the server port.) I haven't reproduced the whole attack scenario and I don't pretend know whether it could work. I don't claim any expertise in software security. I just wanted to help out by answering Eli's questions. To get back to the OP's main point, given that we already go to the trouble of creating this secret, it wouldn't hurt to do it better (on all systems, for preference). On Windows it really doesn't seem hard. Sorry, no patch, for legal reasons, but there's a simple example on the MSDN page for CryptGenRandom. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 17:03:01 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 22:03:01 +0000 Received: from localhost ([127.0.0.1]:49012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE2M9-0005Ta-Hf for submit@debbugs.gnu.org; Tue, 29 Dec 2015 17:03:01 -0500 Received: from randomsample.de ([5.45.97.173]:39471) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE2M8-0005TO-0u for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 17:03:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=LyBlO0krTQ9oNzSaea4TcN9owzA3zR7v6xwcGQ5beGk=; b=Go8nNAmY4FVASwWYtvcgSGxABikPYJKpoQwm7E8o8a2sibw9yY3sYDHVEdQ2nVaZo6SdV9FDvHCw4dOkjPGW3UBdDmm73OzQWB/2B8RF05uoAHp8oIY0kqXzlhCobLJX; Received: from ip4d1494ed.dynamic.kabel-deutschland.de ([77.20.148.237] helo=isaac.fritz.box) by randomsample.de with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aE2M6-0003XA-KA; Tue, 29 Dec 2015 23:02:58 +0100 From: David Engster To: Richard Copley Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems In-Reply-To: (Richard Copley's message of "Tue, 29 Dec 2015 21:22:55 +0000") References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux) Date: Tue, 29 Dec 2015 23:02:55 +0100 Message-ID: <87poxo7w1c.fsf@isaac.fritz.box> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: Eli Zaretskii , 22202@debbugs.gnu.org, Demetri Obenour X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Richard Copley writes: >>> [...] >> >> That's correct (it requires a Windows Server with enabled terminal >> services), but each user session has of course its own process space, so >> I don't see how the described attack could work there. > > Not sure what you mean by process space. As an unprivileged user > you can find other users' Emacs processes without any effort (using > tasklist.exe, for example). If you know on what port an Emacs server > is listening (which is admittedly a difficulty), you can send bytes to it. > I've just done so as an experiment. (I was driving both sessions so I > knew the server port.) You logged in with two different user accounts? I always thought sessions from different users were better isolated from one another and more similar to Linux containers. If that is not the case, then I agree the attack scenario looks feasible. -David From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 29 18:14:02 2015 Received: (at 22202) by debbugs.gnu.org; 29 Dec 2015 23:14:02 +0000 Received: from localhost ([127.0.0.1]:49029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE3Ss-0007B3-FA for submit@debbugs.gnu.org; Tue, 29 Dec 2015 18:14:02 -0500 Received: from mail-yk0-f170.google.com ([209.85.160.170]:34146) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aE3Sq-0007AT-OM for 22202@debbugs.gnu.org; Tue, 29 Dec 2015 18:14:01 -0500 Received: by mail-yk0-f170.google.com with SMTP id a85so64933067ykb.1 for <22202@debbugs.gnu.org>; Tue, 29 Dec 2015 15:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NH7ma0bDppth74+jCshNxVY9tU90YsnD00Xqk2hf2Vw=; b=O/7XRu7VkeETYruvFtnuU6Fmiv68HVqkwOveMcpkhbEs8pGUz7NhbQCW3b8ph8ULeM q25tEXFihEIcyDNfFlfG3krIU37ENCW80dOmSfTUoEpRz645BO29KuyAtOJFxi0HijhW TlUaqr9mw+ThZd4SnW6DqzhC6wY5HEQvBDc3nRcGwtd5wYnV4iEIWUoZu9mYQwTW/WAO kljMrt10O/kAUvc6zCJfKdAHF1LDrkwNhkYg+k0y6+LrA/XVMtus3rLG0u/3ze9oi4J9 WYTOG/es2lLZwJTpdgF5aE9Phcdv5K8LAvSOH+ZTHvrkt8TAKMmC4RWXQUekXNhEQndx LhNw== MIME-Version: 1.0 X-Received: by 10.13.218.198 with SMTP id c189mr50471988ywe.165.1451430835329; Tue, 29 Dec 2015 15:13:55 -0800 (PST) Received: by 10.37.207.214 with HTTP; Tue, 29 Dec 2015 15:13:55 -0800 (PST) In-Reply-To: <87poxo7w1c.fsf@isaac.fritz.box> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <87poxo7w1c.fsf@isaac.fritz.box> Date: Tue, 29 Dec 2015 23:13:55 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: David Engster Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: Eli Zaretskii , 22202@debbugs.gnu.org, Demetri Obenour X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > You logged in with two different user accounts? Yes. I didn't know you could log in two sessions as the same user. Apparently you can (serverfault.com/questions/116016). From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 30 10:57:32 2015 Received: (at 22202) by debbugs.gnu.org; 30 Dec 2015 15:57:32 +0000 Received: from localhost ([127.0.0.1]:50535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEJ7z-00066o-Vx for submit@debbugs.gnu.org; Wed, 30 Dec 2015 10:57:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38127) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEJ7y-00066d-SW for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 10:57:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEJ7s-0003vX-Ci for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 10:57:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEJ7o-0003vF-Fk; Wed, 30 Dec 2015 10:57:20 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1122 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEJ7n-0007CV-ML; Wed, 30 Dec 2015 10:57:20 -0500 Date: Wed, 30 Dec 2015 17:58:14 +0200 Message-Id: <83mvssc4ix.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Tue, 29 Dec 2015 21:22:55 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Tue, 29 Dec 2015 21:22:55 +0000 > From: Richard Copley > Cc: Eli Zaretskii , 22202@debbugs.gnu.org, > Demetri Obenour > > I haven't reproduced the whole attack scenario and I don't pretend > know whether it could work. I don't claim any expertise in software > security. I just wanted to help out by answering Eli's questions. > > To get back to the OP's main point, given that we already go to the > trouble of creating this secret, it wouldn't hurt to do it better (on all > systems, for preference). On Windows it really doesn't seem hard. > Sorry, no patch, for legal reasons, but there's a simple example on > the MSDN page for CryptGenRandom. Can you audit the patch below? I know next to nothing about cryptography, and I'm not sure I understood all the flags involved in these APIs. Also, generating random numbers with these APIs is significantly slower -- about 2.5 msec per number, as opposed to something like 175 microsec using 'rand'. Should we perhaps provide an option (by default off) to force using the old, weaker, but faster method? Thanks. --- src/w32.c~0 2015-11-29 06:48:07.000000000 +0200 +++ src/w32.c 2015-12-30 17:48:19.297251800 +0200 @@ -224,6 +224,8 @@ typedef struct _REPARSE_DATA_BUFFER { #include /* should be after winsock2.h */ +#include + #include #include "w32.h" @@ -2093,9 +2095,34 @@ init_user_info (void) CloseHandle (token); } +static HCRYPTPROV w32_crypto_hprov; +static int +w32_init_crypt_random (void) +{ + if (!CryptAcquireContext (&w32_crypto_hprov, NULL, NULL, PROV_RSA_FULL, + CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) + { + DebPrint (("CryptAcquireContext failed with error %x\n", + GetLastError ())); + return -1; + } + return 0; +} + int random (void) { + if (w32_crypto_hprov) + w32_init_crypt_random (); + if (w32_crypto_hprov) + { + const DWORD nbytes = 4; /* see RAND_BITS in sysdep.c */ + BYTE rand_buffer[nbytes]; + + if (CryptGenRandom (w32_crypto_hprov, nbytes, rand_buffer)) + return *(int *)&rand_buffer[0]; + } + /* Else fall back on rand () */ /* rand () on NT gives us 15 random bits...hack together 30 bits. */ return ((rand () << 15) | rand ()); } @@ -2103,6 +2130,18 @@ random (void) void srandom (int seed) { + if (!w32_crypto_hprov) + w32_init_crypt_random (); + if (w32_crypto_hprov) + { + const DWORD nbytes = 4; /* see RAND_BITS in sysdep.c */ + BYTE buf[nbytes]; + + memcpy (buf, &seed, sizeof buf); + CryptGenRandom (w32_crypto_hprov, nbytes, buf); + } + /* Always seed rand () as well, in case some future call to + CryptGenRandom fails and we need to fall back to rand () */ srand (seed); } @@ -9386,6 +9425,8 @@ globals_of_w32 (void) extern void dynlib_reset_last_error (void); dynlib_reset_last_error (); #endif + + w32_crypto_hprov = (HCRYPTPROV)0; } /* For make-serial-process */ From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 30 15:47:48 2015 Received: (at 22202) by debbugs.gnu.org; 30 Dec 2015 20:47:48 +0000 Received: from localhost ([127.0.0.1]:50678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aENeu-0008CP-AI for submit@debbugs.gnu.org; Wed, 30 Dec 2015 15:47:48 -0500 Received: from mail-yk0-f171.google.com ([209.85.160.171]:36407) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aENes-0008CC-P3 for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 15:47:47 -0500 Received: by mail-yk0-f171.google.com with SMTP id v14so71868940ykd.3 for <22202@debbugs.gnu.org>; Wed, 30 Dec 2015 12:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UiFsXfYIL/+fdGNUGqNJcfGGwczwSi2dAp+bVaDjMck=; b=Y6O1CDn+XNa/PLFuqPT3EpLqQlAmcZWLSoTh7vhDfqwzv/IhC0pz3dHGv/4QETdKOn drDPqrNkHYLV0tSBImEy9iW2cXHaqLaz5YWLtkPYyrNcSVe4qqTHnsU+3H6JNBaePk5t v8gO5vhC6FA3WpLAqlnkuuv/VBwvpzICBTwLieShsuSC8iBhk62YJxjFsn9VBXNBT185 V+KEN4nKt0D2ZJdfCQu+8sP2Pultc4Mr0eR33MRB5DLYCJ9EDDmU79SOmxmlQIPQtisL t2DL8IsyJA/QbTK2n3iA2TseFjnTv6BGCAmThJJQ8C6yFKZH0FwKjpi0vA3wcEEZPLPm 9YoQ== MIME-Version: 1.0 X-Received: by 10.13.218.198 with SMTP id c189mr54556040ywe.165.1451508461119; Wed, 30 Dec 2015 12:47:41 -0800 (PST) Received: by 10.37.207.214 with HTTP; Wed, 30 Dec 2015 12:47:40 -0800 (PST) In-Reply-To: <83mvssc4ix.fsf@gnu.org> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> Date: Wed, 30 Dec 2015 20:47:40 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetri Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Can you audit the patch below? I know next to nothing about > cryptography, and I'm not sure I understood all the flags involved in > these APIs. Sure! But please bear in mind I'm not experienced in crypto either. With regard to API usage: The call to CryptAcquireContext looks good to me. (The comment about interoperability in the documentation for the parameter "pszProvider" does not apply as we are not inter- operating with anything. Setting "pszContainer" to NULL, as you have done, is explicitly recommended. The docs for the individual flags entail the very value of "dwFlags" that you use.) I can see nothing else to comment on. Re performance: using CryptGenRandom to provide a seed for srand is enough to address Demetri's concern. For performance reasons, as you said, implementing random() with CryptGenRandom is potentially bad. I think random() itself should not be changed. That said, rand() makes me uncomfortable (mostly because of bugs in long-gone implementations, and superstition). Given the chance I would replace it with an xorshift* generator. The generator at [1] seeded with 64 bits from CryptGenRandom should give good performance for random() and (I guess!) an effectively unassailable server secret. But I have no good reason to claim that rand() is not good enough. Thank you Eli. [1]: https://en.wikipedia.org/w/index.php?title=Xorshift&oldid=697235156#xorshift.2A From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 30 15:55:52 2015 Received: (at 22202) by debbugs.gnu.org; 30 Dec 2015 20:55:52 +0000 Received: from localhost ([127.0.0.1]:50683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aENmi-0008On-4P for submit@debbugs.gnu.org; Wed, 30 Dec 2015 15:55:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35915) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aENmh-0008Ob-3o for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 15:55:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aENmb-0004Q1-6A for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 15:55:45 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aENmX-0004NG-Im; Wed, 30 Dec 2015 15:55:41 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1856 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aENmW-0006Tx-Ez; Wed, 30 Dec 2015 15:55:41 -0500 Date: Wed, 30 Dec 2015 22:56:29 +0200 Message-Id: <83r3i3bqpu.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Wed, 30 Dec 2015 20:47:40 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Wed, 30 Dec 2015 20:47:40 +0000 > From: Richard Copley > Cc: David Engster , 22202@debbugs.gnu.org, > Demetri Obenour > > Re performance: using CryptGenRandom to provide a seed for srand > is enough to address Demetri's concern. For performance reasons, > as you said, implementing random() with CryptGenRandom is > potentially bad. I think random() itself should not be changed. That'd be the worst of both worlds, IMO: a not-so-good PRNG with no way whatsoever to get a repeatable sequence. Am I right? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 30 15:56:10 2015 Received: (at 22202) by debbugs.gnu.org; 30 Dec 2015 20:56:10 +0000 Received: from localhost ([127.0.0.1]:50687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aENn0-0008Po-Ch for submit@debbugs.gnu.org; Wed, 30 Dec 2015 15:56:10 -0500 Received: from mail-yk0-f180.google.com ([209.85.160.180]:33245) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aENmy-0008PV-QQ for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 15:56:09 -0500 Received: by mail-yk0-f180.google.com with SMTP id k129so142828141yke.0 for <22202@debbugs.gnu.org>; Wed, 30 Dec 2015 12:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k5R9y0pxZupCEI5YfNr6qgn7h2tUVFSaqT2qijzvHJU=; b=m8mjRanTbLsL/1XvoG3w7m3NhhdCP7YD1efrg6tf1B0gbyJ/o7PlSI3QTrVoJCDA0D SV+F5E5qsw9ISiB2JuMW9aR8X03QIVS2vVDbStd4vqsUzSKQ12c6BAiXf6VvQlcKFdfV li+HY4/yJjT6Ym8W7JeasvHDPF4HOH1qWHWYxjBSpZkcit0LhwYjbI8oOMQY3yjuomE/ aL6NrpYx2iWMcFmJSOVa/mt/ikmKq/iNi0+JN6wvF3vDA0GfWWQKTEP31MSb9lODgqFj NYDQlks5NUEd2mt+zAUAt2+YPmK4iM8CuQmmADlBXr2F76sThrUhMsrO7myg+NHAh2yZ alhA== MIME-Version: 1.0 X-Received: by 10.13.246.130 with SMTP id g124mr49693012ywf.29.1451508963303; Wed, 30 Dec 2015 12:56:03 -0800 (PST) Received: by 10.37.207.214 with HTTP; Wed, 30 Dec 2015 12:56:03 -0800 (PST) In-Reply-To: References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> Date: Wed, 30 Dec 2015 20:56:03 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetri Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Ah, I forgot to mention one other thing that had occurred to me. It might not be a good idea to pass the current time to CryptGenRandom for the optional initial seed. The current time (in various forms) is already used as seed entropy by the system, and it's conceivable (though implausible) that we could be destroying entropy by doing this. It's probably better (and "acceptable" according to the documentation) not to pass any seed at all. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 30 16:15:21 2015 Received: (at 22202) by debbugs.gnu.org; 30 Dec 2015 21:15:21 +0000 Received: from localhost ([127.0.0.1]:50693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEO5Y-0000Uc-UY for submit@debbugs.gnu.org; Wed, 30 Dec 2015 16:15:21 -0500 Received: from mail-yk0-f181.google.com ([209.85.160.181]:35811) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEO5X-0000UP-DW for 22202@debbugs.gnu.org; Wed, 30 Dec 2015 16:15:19 -0500 Received: by mail-yk0-f181.google.com with SMTP id x67so164458474ykd.2 for <22202@debbugs.gnu.org>; Wed, 30 Dec 2015 13:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=60toc0dis2TMACzUwP0Mu6kkeWb6K/+qm6ozALAmo1I=; b=iDcSoaHMN/3T0h9gbycrL3h7xPlrZO4cNy43XyYg1Xcx3vQ8Ni0roB5zG43kIJrXKC /He5PhJh7wpWLo+ZcaJ7DXY8yVBtZc7uiRIOw47Yvhi1+auXFphjC54UE5WfvegbyvpM C4eRr246FIlItXvIiVqmsBZcizTFiyXHntZfLUK1+ZhdU59+JPrXzdhxwYupALoLfFrt OFv9i/dvCP3Sp8l8GzrVATN3lp6R0aIEnJp173M2l1uHVHlZ+LqKZKGCX1CLXwjwjq+P acvgTBvZDByjVf5ulNPncbkFSzlxDVChQn2sn1Bzzul6Yl3ASy78qbmSkKSUY/Wb0DDG Udig== MIME-Version: 1.0 X-Received: by 10.129.152.7 with SMTP id p7mr49315647ywg.85.1451510114013; Wed, 30 Dec 2015 13:15:14 -0800 (PST) Received: by 10.37.207.214 with HTTP; Wed, 30 Dec 2015 13:15:13 -0800 (PST) In-Reply-To: <83r3i3bqpu.fsf@gnu.org> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <83r3i3bqpu.fsf@gnu.org> Date: Wed, 30 Dec 2015 21:15:13 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Richard Copley To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetri Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > That'd be the worst of both worlds, IMO: a not-so-good PRNG with no > way whatsoever to get a repeatable sequence. Am I right? Oh dear. Yes. Worse than that, repeatability is part of the contract for the lisp "random" function, so seed_random() and get_random() are constrained to be deterministic. Right? Seems as though init_random() is the only place that could use CryptGenRandom, which is a pity if you're trying to confine the changes to w32.c. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 31 09:13:33 2015 Received: (at 22202) by debbugs.gnu.org; 31 Dec 2015 14:13:33 +0000 Received: from localhost ([127.0.0.1]:51008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEdyv-0008Ig-Dw for submit@debbugs.gnu.org; Thu, 31 Dec 2015 09:13:33 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34637) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEdyt-0008IT-Hl for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 09:13:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEdyn-0005Su-5S for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 09:13:26 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEdyi-0005SU-DY; Thu, 31 Dec 2015 09:13:20 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2223 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEdyh-000516-Ip; Thu, 31 Dec 2015 09:13:19 -0500 Date: Thu, 31 Dec 2015 16:14:00 +0200 Message-Id: <83io3ebt93.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Wed, 30 Dec 2015 21:15:13 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <83r3i3bqpu.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Wed, 30 Dec 2015 21:15:13 +0000 > From: Richard Copley > Cc: David Engster , 22202@debbugs.gnu.org, > Demetri Obenour > > > That'd be the worst of both worlds, IMO: a not-so-good PRNG with no > > way whatsoever to get a repeatable sequence. Am I right? > > Oh dear. Yes. Worse than that, repeatability is part of the contract for > the lisp "random" function, so seed_random() and get_random() are > constrained to be deterministic. Right? > > Seems as though init_random() is the only place that could use > CryptGenRandom, which is a pity if you're trying to confine the > changes to w32.c. How about the following, then? (Not sure it's a good idea to read from /dev/random, as that could block; perhaps we should use /dev/urandom instead.) --- src/sysdep.c~2 2015-11-11 07:57:41.000000000 +0200 +++ src/sysdep.c 2015-12-31 16:09:46.987229300 +0200 @@ -2095,8 +2095,35 @@ seed_random (void *seed, ptrdiff_t seed_ void init_random (void) { - struct timespec t = current_timespec (); - uintmax_t v = getpid () ^ t.tv_sec ^ t.tv_nsec; + uintmax_t v; + struct timespec t; + bool success = false; + +#if HAVE_DEV_RANDOM + FILE *fp = fopen ("/dev/random", "rb"); + + if (fp) + { + int i; + + for (i = 0, v = 0; i < sizeof (uintmax_t); i++) + { + v <<= 8; + v |= fgetc (fp); + } + fclose (fp); + success = true; + } +#elif defined WINDOWSNT + if (w32_init_random (&v, sizeof v) == 0) + success = true; +#endif /* HAVE_DEV_RANDOM || WINDOWSNT */ + if (!success) + { + /* Fall back to current time value + PID. */ + t = current_timespec (); + v = getpid () ^ t.tv_sec ^ t.tv_nsec; + } seed_random (&v, sizeof v); } --- src/w32.c~0 2015-11-29 06:48:07.000000000 +0200 +++ src/w32.c 2015-12-31 16:05:06.775707600 +0200 @@ -224,6 +224,8 @@ typedef struct _REPARSE_DATA_BUFFER { #include /* should be after winsock2.h */ +#include + #include #include "w32.h" @@ -2093,6 +2095,34 @@ init_user_info (void) CloseHandle (token); } +static HCRYPTPROV w32_crypto_hprov; +static int +w32_init_crypt_random (void) +{ + if (!CryptAcquireContext (&w32_crypto_hprov, NULL, NULL, PROV_RSA_FULL, + CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) + { + DebPrint (("CryptAcquireContext failed with error %x\n", + GetLastError ())); + w32_crypto_hprov = 0; + return -1; + } + return 0; +} + +int +w32_init_random (void *buf, ptrdiff_t buflen) +{ + if (w32_crypto_hprov) + w32_init_crypt_random (); + if (w32_crypto_hprov) + { + if (CryptGenRandom (w32_crypto_hprov, buflen, (BYTE *)buf)) + return 0; + } + return -1; +} + int random (void) { @@ -9386,6 +9416,8 @@ globals_of_w32 (void) extern void dynlib_reset_last_error (void); dynlib_reset_last_error (); #endif + + w32_crypto_hprov = (HCRYPTPROV)0; } /* For make-serial-process */ --- src/w32.h~2 2015-11-29 06:48:07.000000000 +0200 +++ src/w32.h 2015-12-31 16:09:21.960654500 +0200 @@ -222,6 +222,9 @@ extern int w32_memory_info (unsigned lon /* Compare 2 UTF-8 strings in locale-dependent fashion. */ extern int w32_compare_strings (const char *, const char *, char *, int); +/* Return a cryptographically secure seed for PRNG. */ +extern int w32_init_random (void *, ptrdiff_t); + #ifdef HAVE_GNUTLS #include --- src/fns.c~ 2015-11-22 07:57:20.000000000 +0200 +++ src/fns.c 2015-12-31 16:57:43.607286800 +0200 @@ -50,7 +50,8 @@ All integers representable in Lisp, i.e. 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 current time and pid. +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. With a string argument, set the seed based on the string's contents. Other values of LIMIT are ignored. --- configure.ac~2 2015-12-20 06:45:33.000000000 +0200 +++ configure.ac 2015-12-31 16:06:48.959511800 +0200 @@ -4145,6 +4145,22 @@ AC_TYPE_MBSTATE_T +AC_MSG_CHECKING([whether "/dev/random" is available]) +dev_random=no +dnl MSYS, being a Cygwin fork, thinks "/dev/random" does exist, so +dnl don't check this for the MinGW builds. +if test "${opsys}" != "mingw32"; then + if test -r "/dev/random"; then + AC_DEFINE(HAVE_DEV_RANDOM, 1, [Define if the system supports the "/dev/random" device.]) + dev_random=yes + fi +fi +if test $dev_random = yes; then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi + dnl Fixme: AC_SYS_POSIX_TERMIOS should probably be used, but it's not clear dnl how the tty code is related to POSIX and/or other versions of termios. dnl The following looks like a useful start. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 31 12:04:46 2015 Received: (at 22202) by debbugs.gnu.org; 31 Dec 2015 17:04:46 +0000 Received: from localhost ([127.0.0.1]:51898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEgec-0004Lz-1z for submit@debbugs.gnu.org; Thu, 31 Dec 2015 12:04:46 -0500 Received: from mail-yk0-f175.google.com ([209.85.160.175]:33345) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEgeb-0004Ln-8g for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 12:04:45 -0500 Received: by mail-yk0-f175.google.com with SMTP id k129so161429127yke.0 for <22202@debbugs.gnu.org>; Thu, 31 Dec 2015 09:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=9gyj1ORf+YGk/mwlNUhswdksCslFB+Dae1oCDBh7w44=; b=Xbt1TmdcEHSWio2rxeRvjSvRT8ljZWhwST+Dxn81nWDE2Ne70e2mWYQYp/9U1qO1KT S+L7VwCQG9hCrDxXOpKHaGy0oyUm0DMgWGUuRi0U4IM2frSRId6WV6cNiqYpaVGAtFbY 75a39ekp24AxF5ljeHf9hOSQj0LNnvrBRjt2wYNK787YIfGspWIZ5nDo5rxIgQWieSA2 7+I3auKh1CZ38ntHcBiLU5IYEfwRrfReZVGlUzNxszHYclHx9B114BzfznMlj28uwyiV sIIVrB0388wep5ZoxCy6IC1NlOKsGK5os2IJ6RG9rXesV01Dj6PsIuA7C8CquUGxR8WI lYiw== X-Received: by 10.129.84.2 with SMTP id i2mr15787753ywb.21.1451581479893; Thu, 31 Dec 2015 09:04:39 -0800 (PST) Received: from localhost.hsd1.tn.comcast.net ([2601:840:8101:227f:2ae3:47ff:fe02:d99e]) by smtp.googlemail.com with ESMTPSA id t189sm62265347ywd.43.2015.12.31.09.04.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Dec 2015 09:04:39 -0800 (PST) Message-ID: <1451581478.15612.5.camel@gmail.com> Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems From: Demetrios Obenour To: Richard Copley , Eli Zaretskii Date: Thu, 31 Dec 2015 12:04:38 -0500 In-Reply-To: References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Wed, 2015-12-30 at 20:47 +0000, Richard Copley wrote: > > Can you audit the patch below? I know next to nothing about > > cryptography, and I'm not sure I understood all the flags involved > > in > > these APIs. > > Sure! But please bear in mind I'm not experienced in crypto > either. > > With regard to API usage: The call to CryptAcquireContext looks good > to me. (The comment about interoperability in the documentation for > the parameter "pszProvider" does not apply as we are not inter- > operating with anything. Setting "pszContainer" to NULL, as you have > done, is explicitly recommended. The docs for the individual flags > entail the very value of "dwFlags" that you use.) I can see nothing > else to comment on. > > Re performance: using CryptGenRandom to provide a seed for srand > is enough to address Demetri's concern. For performance reasons, > as you said, implementing random() with CryptGenRandom is > potentially bad. I think random() itself should not be changed. > > That said, rand() makes me uncomfortable (mostly because of bugs in > long-gone implementations, and superstition). Given the chance I > would > replace it with an xorshift* generator. The generator at [1] seeded > with 64 bits from CryptGenRandom should give good performance for > random() and (I guess!) an effectively unassailable server secret. > > But I have no good reason to claim that rand() is not good enough. > > Thank you Eli. > > [1]: https://en.wikipedia.org/w/index.php?title=Xorshift&oldid=697235 > 156#xorshift.2A > The server secret should be entirely obtained from CryptGenRandom (or the function RtlGenRandom on which it is based). The server secret is a cryptographic key and should be generated as such. Using the same entropy to seed an insecure PRNG and the server secret is a bad idea -- the server secret could be guessed based on PRNG output. It would also be nice to expose a CSPRNG to Lisp on all platforms. I know that SLIME could use it on Windows, and it would be nice if one could have a just-do-it API for this purpose. Speed does not matter much here. Demetri From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 31 12:24:24 2015 Received: (at 22202) by debbugs.gnu.org; 31 Dec 2015 17:24:24 +0000 Received: from localhost ([127.0.0.1]:51908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEgxc-0004pe-0c for submit@debbugs.gnu.org; Thu, 31 Dec 2015 12:24:24 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47378) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEgxa-0004pS-Iu for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 12:24:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEgxQ-0004kf-UU for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 12:24:17 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEgxQ-0004kb-RS; Thu, 31 Dec 2015 12:24:12 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2356 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEgxP-0008Oy-Vv; Thu, 31 Dec 2015 12:24:12 -0500 Date: Thu, 31 Dec 2015 19:24:52 +0200 Message-Id: <83bn96bkez.fsf@gnu.org> From: Eli Zaretskii To: Demetrios Obenour In-reply-to: <1451581478.15612.5.camel@gmail.com> (message from Demetrios Obenour on Thu, 31 Dec 2015 12:04:38 -0500) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Demetrios Obenour > Cc: David Engster , 22202@debbugs.gnu.org > Date: Thu, 31 Dec 2015 12:04:38 -0500 > > The server secret should be entirely obtained from CryptGenRandom (or > the function RtlGenRandom on which it is based). The server secret is > a cryptographic key and should be generated as such. Using the same > entropy to seed an insecure PRNG and the server secret is a bad idea -- > the server secret could be guessed based on PRNG output. I don't understand what you are saying. server.el doesn't use the secret, it simply invokes the 'random' function several time to generate the authentication key. The secret is used to seed the PRNG during Emacs startup, and it is used only once. Given this description, how can the secret be guessed, and what are the implications of that guess (if indeed it's possible) on the ability of an attacker to control Emacs via the client socket? > It would also be nice to expose a CSPRNG to Lisp on all platforms. I > know that SLIME could use it on Windows, and it would be nice if one > could have a just-do-it API for this purpose. Speed does not matter > much here. Patches are welcome, but they should include the same feature for Posix hosts, probably using /dev/random. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 19:13:53 2016 Received: (at 22202) by debbugs.gnu.org; 2 Jan 2016 00:13:53 +0000 Received: from localhost ([127.0.0.1]:33969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aF9pR-0000mt-0B for submit@debbugs.gnu.org; Fri, 01 Jan 2016 19:13:53 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:35118) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aF9pP-0000mh-Nz for 22202@debbugs.gnu.org; Fri, 01 Jan 2016 19:13:51 -0500 Received: by mail-yk0-f174.google.com with SMTP id x67so203869835ykd.2 for <22202@debbugs.gnu.org>; Fri, 01 Jan 2016 16:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=944j8NI4XxFO732nXERdpAO6K/oDge5D5YT4y6mjerY=; b=VDJHIQixnQIC1U9TyFBE916IFvM/ug8V2cKnauyOiHRzubsZ/aWGA/EE+mmDM5WgSn JkS/yv/t5ahJrdpmBx2Kj67ckyZJrCZFjJpSddor18OvRtdEi9VkpGbzgpahjGUKLSI1 4JHLiebnVndQem9QRiSXYq4R8mZwSxnxOHHeJDJz5KUbeEIp2eMGKgW4UUsG7AXLGs3y pTlrOW/RJ3Zu5V8Q9crMHSKf/62VqcDgkFgYZeDz6m1HTh1qULR5uXdQTgXHvN+Us+ed dqoV3SxuKMlQ2bYI7MkkdZ+pWvtD7VWG6QdMXWyWuVCBEY9mTyxU+zVDn/AatkNhWnb5 RZPQ== X-Received: by 10.129.19.214 with SMTP id 205mr54045945ywt.136.1451591411830; Thu, 31 Dec 2015 11:50:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.214 with HTTP; Thu, 31 Dec 2015 11:49:42 -0800 (PST) In-Reply-To: <834meybf2v.fsf@gnu.org> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> <834meybf2v.fsf@gnu.org> From: Richard Copley Date: Thu, 31 Dec 2015 19:49:42 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetrios Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) >> That last patch would still improve matters. The user would have >> to be publishing the output of their PRNG to begin with in order >> for the attacker to analyse it and guess the seed. (I don't know >> how one could do that but that's no proof that it's impossible.) > >I don't even understand how that could be possible. Me either, but that doesn't make it impossible. (There are articles on the web demonstrating such feats, if you're interested.) >> What Demetri has just described is what I would do. > >Now I'm confused: do what? As I understand it: Provide a function callable from lisp that returns a cryptographically secure sequence of random bytes, of a specified length. Use that function to generate the server secret. >We still need to support 'random' with an >argument, so we cannot get rid of seeding a PRNG with a known value. >And I didn't want to remove srandom. Given the above, we could leave "random", etc., as they are, or we could use a better PRNG and/or seed with system entropy. It would no longer be tied up with this issue report. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 19:52:23 2016 Received: (at 22202) by debbugs.gnu.org; 2 Jan 2016 00:52:23 +0000 Received: from localhost ([127.0.0.1]:34014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFAQg-0003Mo-Rs for submit@debbugs.gnu.org; Fri, 01 Jan 2016 19:52:23 -0500 Received: from mail-yk0-f176.google.com ([209.85.160.176]:35485) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFAQf-0003MX-1V for 22202@debbugs.gnu.org; Fri, 01 Jan 2016 19:52:21 -0500 Received: by mail-yk0-f176.google.com with SMTP id x67so204219564ykd.2 for <22202@debbugs.gnu.org>; Fri, 01 Jan 2016 16:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uIy0wFJD6/NXCxf1M58UocZdHs3vXDr6mND7KlIGArk=; b=bPZRT8b3gbCSqXN8DfxnTq8xvooUSx9f8bUq8uTxAGs+nvw0JRbCFxy+6TRW4ibnJ3 Lib8+zOR5177mY7aeNO3ttReX9dYG19/ScmpM9A4Pvaw3ToYxObDU+GRWNJqGo3WuuAG sx3NcBa7h8tYIkA+cXHdM0rhv9AZJIYjR7Oi3KL315Tgo932stfBhFpQyRTr8lMD8tOF tuGM9nDMuvbQBRUqrI+Vtn/QiD9yocvHSThT/JSQG9zyddmzdLyUBBmI44G8dr2Sct+t 0xPo8J55dMlSMu2xjEvPCvx4gj7rxYOKreeh1TTDI8VqhmuDa/yQUT4BZN+LpKyeGGtr jGGg== X-Received: by 10.129.157.74 with SMTP id u71mr54913346ywg.83.1451594688237; Thu, 31 Dec 2015 12:44:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.214 with HTTP; Thu, 31 Dec 2015 12:44:18 -0800 (PST) In-Reply-To: <8337uibcm5.fsf@gnu.org> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> <834meybf2v.fsf@gnu.org> <8337uibcm5.fsf@gnu.org> From: Richard Copley Date: Thu, 31 Dec 2015 20:44:18 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetri Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) >> >> What Demetri has just described is what I would do. >> > >> >Now I'm confused: do what? >> >> As I understand it: Provide a function callable from lisp that returns >> a cryptographically secure sequence of random bytes, of a specified >> length. Use that function to generate the server secret. > > That's what my patch does. A separate function from "random". >> >We still need to support 'random' with an >> >argument, so we cannot get rid of seeding a PRNG with a known value. >> >And I didn't want to remove srandom. >> >> Given the above, we could leave "random", etc., as they are, or we >> could use a better PRNG and/or seed with system entropy. It would >> no longer be tied up with this issue report. > > Patches welcome, as I said already. You asked me a question. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 20:51:52 2016 Received: (at 22202) by debbugs.gnu.org; 2 Jan 2016 01:51:52 +0000 Received: from localhost ([127.0.0.1]:34118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBMF-00088u-PW for submit@debbugs.gnu.org; Fri, 01 Jan 2016 20:51:51 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33965) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBAz-00068D-EO for 22202@debbugs.gnu.org; Fri, 01 Jan 2016 20:40:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEikz-0000OS-Go for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 14:19:32 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEikz-0000OO-DQ; Thu, 31 Dec 2015 14:19:29 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2505 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEikx-0000F6-Nh; Thu, 31 Dec 2015 14:19:28 -0500 Date: Thu, 31 Dec 2015 21:20:08 +0200 Message-Id: <834meybf2v.fsf@gnu.org> From: Eli Zaretskii To: Demetrios Obenour In-reply-to: <1451581478.15612.5.camel@gmail.com> (message from Demetrios Obenour on Thu, 31 Dec 2015 12:04:38 -0500) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Demetrios Obenour > Cc: David Engster , 22202@debbugs.gnu.org > Date: Thu, 31 Dec 2015 12:04:38 -0500 > > It would also be nice to expose a CSPRNG to Lisp on all platforms. I > know that SLIME could use it on Windows, and it would be nice if one > could have a just-do-it API for this purpose. Speed does not matter > much here. Btw, for the record: my speed measurements were wrong: it turned out I compared an optimized build with an unoptimized one. When compared correctly, there's no perceptible performance difference between using CRT's 'rand' and using the Windows Crypto API to generate random numbers. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 20:51:58 2016 Received: (at 22202) by debbugs.gnu.org; 2 Jan 2016 01:51:58 +0000 Received: from localhost ([127.0.0.1]:34130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBMM-00089h-EC for submit@debbugs.gnu.org; Fri, 01 Jan 2016 20:51:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33965) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBB0-00068D-Lt for 22202@debbugs.gnu.org; Fri, 01 Jan 2016 20:40:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEjaT-0005vQ-Km for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 15:12:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEjaT-0005vM-HP; Thu, 31 Dec 2015 15:12:41 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2521 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEjaS-0004PE-Op; Thu, 31 Dec 2015 15:12:41 -0500 Date: Thu, 31 Dec 2015 22:13:22 +0200 Message-Id: <8337uibcm5.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Thu, 31 Dec 2015 19:49:42 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> <834meybf2v.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Richard Copley > Date: Thu, 31 Dec 2015 19:49:42 +0000 > Cc: Demetrios Obenour , David Engster , > 22202@debbugs.gnu.org > > >> What Demetri has just described is what I would do. > > > >Now I'm confused: do what? > > As I understand it: Provide a function callable from lisp that returns > a cryptographically secure sequence of random bytes, of a specified > length. Use that function to generate the server secret. That's what my patch does. > >We still need to support 'random' with an > >argument, so we cannot get rid of seeding a PRNG with a known value. > >And I didn't want to remove srandom. > > Given the above, we could leave "random", etc., as they are, or we > could use a better PRNG and/or seed with system entropy. It would > no longer be tied up with this issue report. Patches welcome, as I said already. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 20:51:59 2016 Received: (at 22202) by debbugs.gnu.org; 2 Jan 2016 01:51:59 +0000 Received: from localhost ([127.0.0.1]:34132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBMM-00089o-Mq for submit@debbugs.gnu.org; Fri, 01 Jan 2016 20:51:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33965) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBB1-00068D-DB for 22202@debbugs.gnu.org; Fri, 01 Jan 2016 20:40:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEhre-0002YP-4u for 22202@debbugs.gnu.org; Thu, 31 Dec 2015 13:22:22 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEhre-0002YF-2A; Thu, 31 Dec 2015 13:22:18 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2396 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEhrc-0002BA-VR; Thu, 31 Dec 2015 13:22:17 -0500 Date: Thu, 31 Dec 2015 20:22:58 +0200 Message-Id: <838u4abhq5.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Thu, 31 Dec 2015 17:47:18 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> <83bn96bkez.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Richard Copley > Date: Thu, 31 Dec 2015 17:47:18 +0000 > Cc: Demetrios Obenour , David Engster , > 22202@debbugs.gnu.org > > That last patch would still improve matters. The user would have > to be publishing the output of their PRNG to begin with in order > for the attacker to analyse it and guess the seed. (I don't know > how one could do that but that's no proof that it's impossible.) I don't even understand how that could be possible. > What Demetri has just described is what I would do. Now I'm confused: do what? We still need to support 'random' with an argument, so we cannot get rid of seeding a PRNG with a known value. And I didn't want to remove srandom. > + if (w32_crypto_hprov) > + w32_init_crypt_random (); > > should be > > + if (! w32_crypto_hprov) > + w32_init_crypt_random (); Ah, that's a left-over from debugging. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 21:03:50 2016 Received: (at 22202) by debbugs.gnu.org; 2 Jan 2016 02:03:50 +0000 Received: from localhost ([127.0.0.1]:34177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBXq-0001jR-Cw for submit@debbugs.gnu.org; Fri, 01 Jan 2016 21:03:50 -0500 Received: from mail-yk0-f178.google.com ([209.85.160.178]:33104) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aFBXo-0001jC-Sz for 22202@debbugs.gnu.org; Fri, 01 Jan 2016 21:03:49 -0500 Received: by mail-yk0-f178.google.com with SMTP id k129so183323099yke.0 for <22202@debbugs.gnu.org>; Fri, 01 Jan 2016 18:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wNhev/k/HacLaiy1rrLseZ/Z78gBteiabJ+3QqSP810=; b=jewrBTDYCTF40yLNyqnZnT7G45bHlf4SSksKx0dJ1yfzqCILs6EybnJyQnFf29Nhg+ LVQCjYUufyqv7giO0lkivsK73mGn/n+eQcyx4EbHgtxlT4BZwPQ8NObCJ5vWCQGV6cEJ x+7Os9PSIoXfdKAwj9imgS6YUrcUW3GIesMdW+nHzUtP0rD2hTy5k4Kc52vAU1JL2Dur FB3kfvAOwLnNFcfONZX5AtGN7MufCCHPVPs5IAGvIVryKKjwqRQK4vXEKVX3X4x03D2c 6gZglTxRqNdhjj0eKwkr2mLB3qf81YLsdtefsuhNI1XXSlu2qtlwE5dzdgZ/hPxcIJlV l4lQ== X-Received: by 10.129.33.65 with SMTP id h62mr52227762ywh.139.1451584068223; Thu, 31 Dec 2015 09:47:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.214 with HTTP; Thu, 31 Dec 2015 09:47:18 -0800 (PST) In-Reply-To: <83bn96bkez.fsf@gnu.org> References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> <83bn96bkez.fsf@gnu.org> From: Richard Copley Date: Thu, 31 Dec 2015 17:47:18 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Demetrios Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) That last patch would still improve matters. The user would have to be publishing the output of their PRNG to begin with in order for the attacker to analyse it and guess the seed. (I don't know how one could do that but that's no proof that it's impossible.) What Demetri has just described is what I would do. (Sorry again that I can't assist with a patch.) + if (w32_crypto_hprov) + w32_init_crypt_random (); should be + if (! w32_crypto_hprov) + w32_init_crypt_random (); From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 15 04:55:27 2016 Received: (at 22202-done) by debbugs.gnu.org; 15 Jan 2016 09:55:27 +0000 Received: from localhost ([127.0.0.1]:49643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aK16M-00087p-R3 for submit@debbugs.gnu.org; Fri, 15 Jan 2016 04:55:27 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40475) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aK16L-00087a-FP for 22202-done@debbugs.gnu.org; Fri, 15 Jan 2016 04:55:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aK16C-0004V3-2x for 22202-done@debbugs.gnu.org; Fri, 15 Jan 2016 04:55:20 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK16B-0004Uz-Vd; Fri, 15 Jan 2016 04:55:16 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4797 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aK16B-0001sF-5N; Fri, 15 Jan 2016 04:55:15 -0500 Date: Fri, 15 Jan 2016 11:55:11 +0200 Message-Id: <83r3hjf9q8.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Thu, 31 Dec 2015 19:49:42 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <83lh8ddy45.fsf@gnu.org> <8760zh81oo.fsf@isaac.fritz.box> <83mvssc4ix.fsf@gnu.org> <1451581478.15612.5.camel@gmail.com> <834meybf2v.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202-done Cc: demetriobenour@gmail.com, deng@randomsample.de, 22202-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Richard Copley > Date: Thu, 31 Dec 2015 19:49:42 +0000 > Cc: Demetrios Obenour , David Engster , > 22202@debbugs.gnu.org > > >> That last patch would still improve matters. The user would have > >> to be publishing the output of their PRNG to begin with in order > >> for the attacker to analyse it and guess the seed. (I don't know > >> how one could do that but that's no proof that it's impossible.) > > > >I don't even understand how that could be possible. > > Me either, but that doesn't make it impossible. (There are articles > on the web demonstrating such feats, if you're interested.) > > >> What Demetri has just described is what I would do. > > > >Now I'm confused: do what? > > As I understand it: Provide a function callable from lisp that returns > a cryptographically secure sequence of random bytes, of a specified > length. Use that function to generate the server secret. That'd be an enhancement, not a bug. Patches to provide such an API are welcome, now that the infrastructure exists both on Posix hosts and on MS-Windows (see below), the rest should be easy: one just needs to follow the established APIs in other Lisp-like environments, I think. > >We still need to support 'random' with an > >argument, so we cannot get rid of seeding a PRNG with a known value. > >And I didn't want to remove srandom. > > Given the above, we could leave "random", etc., as they are, or we > could use a better PRNG and/or seed with system entropy. It would > no longer be tied up with this issue report. I preferred to make it possible to pass a cryptographically secure byte stream to 'srandom' instead. See commit 3ffe81e on the emacs-25 branch. This leaves the basic 'random' functionality intact, so no Lisp packages should be affected. I'm therefore marking this bug as done. Thanks for the feedback. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 17 15:26:42 2016 Received: (at 22202) by debbugs.gnu.org; 17 Jan 2016 20:26:42 +0000 Received: from localhost ([127.0.0.1]:52068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKtuM-0006TM-G6 for submit@debbugs.gnu.org; Sun, 17 Jan 2016 15:26:42 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50303) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKtuJ-0006T8-UV for 22202@debbugs.gnu.org; Sun, 17 Jan 2016 15:26:40 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 29EFC160017; Sun, 17 Jan 2016 12:26:34 -0800 (PST) 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 QuoanrGMKAiC; Sun, 17 Jan 2016 12:26:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B3398160544; Sun, 17 Jan 2016 12:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 jrFh3lMhKwGK; Sun, 17 Jan 2016 12:26:32 -0800 (PST) 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 7D3DE160017; Sun, 17 Jan 2016 12:26:32 -0800 (PST) To: Eli Zaretskii From: Paul Eggert Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Organization: UCLA Computer Science Department Message-ID: <569BF8F7.3090904@cs.ucla.edu> Date: Sun, 17 Jan 2016 12:26:31 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040009080301020704010803" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: Richard Copley , 22202@debbugs.gnu.org, demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This is a multi-part message in MIME format. --------------040009080301020704010803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. 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. --------------040009080301020704010803 Content-Type: text/x-diff; name="0001-Prefer-GnuTLS-when-acquiring-random-seed.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Prefer-GnuTLS-when-acquiring-random-seed.patch" >From 05e8148a24ebe51fbe758dd16265e8fb81f85953 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 17 Jan 2016 12:12:08 -0800 Subject: [PATCH] Prefer GnuTLS when acquiring random seed This attempts to improve on the fix for Bug#22202. * configure.ac (HAVE_DEV_URANDOM): Remove. Check /dev/urandom existence at run time, not at build time, since the device could exist in the former but not the latter. * src/sysdep.c [HAVE_GNUTLS]: Include gnutls/gnutls.h. (gnutls_rnd) [GNUTLS_VERSION_NUMBER < 0x020c00]: New fallback macro. (random_seed): New typedef. (set_random_seed): New static function. (seed_random): Use them. (init_random): Use random_seed instead of uintmax_t, so as to not consume more entropy than needed. Prefer gnutls_rnd if it works; this avoids a redundant open of /dev/urandom on GNU/Linux with modern GnuTLS. --- configure.ac | 16 ------------ src/sysdep.c | 85 ++++++++++++++++++++++++++++++------------------------------ 2 files changed, 43 insertions(+), 58 deletions(-) diff --git a/configure.ac b/configure.ac index 6c9b621..8c01aba 100644 --- a/configure.ac +++ b/configure.ac @@ -4153,22 +4153,6 @@ fi AC_TYPE_MBSTATE_T -AC_MSG_CHECKING([whether "/dev/urandom" is available]) -dev_urandom=no -dnl MSYS, being a Cygwin fork, thinks "/dev/urandom" does exist, so -dnl don't check this for the MinGW builds. -if test "${opsys}" != "mingw32"; then - if test -r "/dev/urandom"; then - AC_DEFINE(HAVE_DEV_URANDOM, 1, [Define if the system supports the "/dev/urandom" device.]) - dev_urandom=yes - fi -fi -if test $dev_urandom = yes; then - AC_MSG_RESULT(yes) -else - AC_MSG_RESULT(no) -fi - dnl Fixme: AC_SYS_POSIX_TERMIOS should probably be used, but it's not clear dnl how the tty code is related to POSIX and/or other versions of termios. dnl The following looks like a useful start. diff --git a/src/sysdep.c b/src/sysdep.c index 1fa4229..635443c 100644 --- a/src/sysdep.c +++ b/src/sysdep.c @@ -99,6 +99,15 @@ along with GNU Emacs. If not, see . */ #include "process.h" #include "cm.h" +#ifdef HAVE_GNUTLS +# include +#endif +#if 0x020c00 <= GNUTLS_VERSION_NUMBER +# include +#else +# define gnutls_rnd(level, data, len) (-1) +#endif + #ifdef WINDOWSNT #include /* In process.h which conflicts with the local copy. */ @@ -2068,63 +2077,55 @@ init_signals (bool dumping) # endif /* !HAVE_RANDOM */ #endif /* !RAND_BITS */ +#ifdef HAVE_RANDOM +typedef unsigned int random_seed; +static void set_random_seed (random_seed arg) { srandom (arg); } +#elif defined HAVE_LRAND48 +/* Although srand48 uses a long seed, this is unsigned long to avoid + undefined behavior on signed integer overflow in init_random. */ +typedef unsigned long int random_seed; +static void set_random_seed (random_seed arg) { srand48 (arg); } +#else +typedef unsigned int random_seed; +static void set_random_seed (random_seed arg) { srand (arg); } +#endif + void seed_random (void *seed, ptrdiff_t seed_size) { -#if defined HAVE_RANDOM || ! defined HAVE_LRAND48 - unsigned int arg = 0; -#else - long int arg = 0; -#endif + random_seed arg = 0; unsigned char *argp = (unsigned char *) &arg; unsigned char *seedp = seed; - ptrdiff_t i; - for (i = 0; i < seed_size; i++) + for (ptrdiff_t i = 0; i < seed_size; i++) argp[i % sizeof arg] ^= seedp[i]; -#ifdef HAVE_RANDOM - srandom (arg); -#else -# ifdef HAVE_LRAND48 - srand48 (arg); -# else - srand (arg); -# endif -#endif + set_random_seed (arg); } void init_random (void) { - uintmax_t v; - struct timespec t; - bool success = false; - -#if HAVE_DEV_URANDOM - FILE *fp = fopen ("/dev/urandom", "rb"); - - if (fp) + random_seed v; + if (gnutls_rnd (GNUTLS_RND_NONCE, &v, sizeof v) != 0) { - int i; - - for (i = 0, v = 0; i < sizeof (uintmax_t); i++) + bool success = false; +#ifndef WINDOWSNT + int fd = emacs_open ("/dev/urandom", O_RDONLY | O_BINARY, 0); + if (0 <= fd) { - v <<= 8; - v |= fgetc (fp); + success = emacs_read (fd, &v, sizeof v) == sizeof v; + emacs_close (fd); + } +#else + success = w32_init_random (&v, sizeof v) == 0; +#endif + if (! success) + { + /* Fall back to current time value + PID. */ + struct timespec t = current_timespec (); + v = getpid () ^ t.tv_sec ^ t.tv_nsec; } - fclose (fp); - success = true; - } -#elif defined WINDOWSNT - if (w32_init_random (&v, sizeof v) == 0) - success = true; -#endif /* HAVE_DEV_URANDOM || WINDOWSNT */ - if (!success) - { - /* Fall back to current time value + PID. */ - t = current_timespec (); - v = getpid () ^ t.tv_sec ^ t.tv_nsec; } - seed_random (&v, sizeof v); + set_random_seed (v); } /* -- 2.5.0 --------------040009080301020704010803-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 17 20:42:54 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 01:42:54 +0000 Received: from localhost ([127.0.0.1]:52200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKyqM-0001dE-Cs for submit@debbugs.gnu.org; Sun, 17 Jan 2016 20:42:54 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56994) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aKyqK-0001d1-51 for 22202@debbugs.gnu.org; Sun, 17 Jan 2016 20:42:52 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0E0AC160017; Sun, 17 Jan 2016 17:42:46 -0800 (PST) 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 Fx3hIWhLz5UA; Sun, 17 Jan 2016 17:42:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 581DB1607CC; Sun, 17 Jan 2016 17:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 NdsZQhAEygp3; Sun, 17 Jan 2016 17:42:45 -0800 (PST) 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 2A147160017; Sun, 17 Jan 2016 17:42:45 -0800 (PST) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: 22202@debbugs.gnu.org References: <569BF8F7.3090904@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <569C4314.3090101@cs.ucla.edu> Date: Sun, 17 Jan 2016 17:42:44 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569BF8F7.3090904@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: Richard Copley , Eli Zaretskii , Andreas Schwab , demetriobenour@gmail.com, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Andreas Schwab discovered a problem with my patch in that GnuTLS wasn't initialized, and reverted the GnuTLS part of it. As I understand it, newer versions of GnuTLS initialize themselves when they are loaded and so do not run into the issue; I tested with GnuTLS 3.3.15, which I suppose is new enough. I attempted to fix this problem in the followup commit 130d512045aa376333b664d58c501b3884187592. Andreas's commit also changed some unrelated style issues, which I reverted; that is merely a longrunning stylistic disagreement, and right now is not a good time to be changing style in code unrelated to fixes. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 07:04:59 2016 Received: (at submit) by debbugs.gnu.org; 18 Jan 2016 12:04:59 +0000 Received: from localhost ([127.0.0.1]:52347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aL8YM-0002nW-Pr for submit@debbugs.gnu.org; Mon, 18 Jan 2016 07:04:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36399) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aL8YL-0002nJ-2o for submit@debbugs.gnu.org; Mon, 18 Jan 2016 07:04:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL8YF-0003Yr-6C for submit@debbugs.gnu.org; Mon, 18 Jan 2016 07:04:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL8YF-0003Yn-3R for submit@debbugs.gnu.org; Mon, 18 Jan 2016 07:04:51 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL8YE-00014u-4N for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 07:04:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL8Y9-0003YJ-4b for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 07:04:50 -0500 Received: from plane.gmane.org ([80.91.229.3]:48907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL8Y8-0003Y1-Uo for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 07:04:45 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aL8Y5-0005ZT-9u for bug-gnu-emacs@gnu.org; Mon, 18 Jan 2016 13:04:41 +0100 Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jan 2016 13:04:41 +0100 Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jan 2016 13:04:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Date: Mon, 18 Jan 2016 12:04:34 +0000 Lines: 23 Message-ID: References: <569BF8F7.3090904@cs.ucla.edu> <569C4314.3090101@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt) Cancel-Lock: sha1:2FtB901ExVKbRcIp37eUe2L6DcQ= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) On Sun 17 Jan 2016, Paul Eggert wrote: > Andreas Schwab discovered a problem with my patch in that GnuTLS wasn't > initialized, and reverted the GnuTLS part of it. As I understand it, newer > versions of GnuTLS initialize themselves when they are loaded and so do not > run into the issue; I tested with GnuTLS 3.3.15, which I suppose is new > enough. I attempted to fix this problem in the followup commit > 130d512045aa376333b664d58c501b3884187592. Your patch will break builds configured using --without-gnutls, as the gnutls headers may not be installed, and should not be included. In addition, these changes require static or dynamic linking of gnutls, which breaks the Windows builds (which use runtime imports for the gnutls DLLs). > Andreas's commit also changed some unrelated style issues, which I reverted; > that is merely a longrunning stylistic disagreement, and right now is not a > good time to be changing style in code unrelated to fixes. This is rudeness from both of you: please solve this disagreement by talking to each other instead of adding pointless churn to the source tree. AndyM From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 09:40:42 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 14:40:42 +0000 Received: from localhost ([127.0.0.1]:52425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLAz4-00082O-AE for submit@debbugs.gnu.org; Mon, 18 Jan 2016 09:40:42 -0500 Received: from mail-yk0-f178.google.com ([209.85.160.178]:36175) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLAz2-00082C-AJ for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 09:40:40 -0500 Received: by mail-yk0-f178.google.com with SMTP id v14so521207761ykd.3 for <22202@debbugs.gnu.org>; Mon, 18 Jan 2016 06:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bkApdkWvWiFEDIav7/0df5pV21zLwvIbgFh+FcyS4W4=; b=DAnV9LN6jA1L9TENE0YlN90brwOKmal4poJxg6m8pYaR+7EbcL2Y6aFjIZKe3zu+9y rfU4f9JTbXShU01tVmqUUkS23wr3fELLhY18iX/lJPcvgr3gFZoZrErw7lM5wjpT1c+m 8qIZClyPN00it8lqt8caBHikPofxw1w70naNQp0d6GqiYc8R2mb/AOGzapxwQ6Pd426q zZCr4VUcNavq5teDlLzIZptZRZFnzzXgwGbTrU52DA7p2iv0ATz2ZheYjIVBCUJGEYvK +831dwkJ4gYzADPHxIau8T5VjUKsVkWq0OdwEBdW7JgRIIezX3iATi1eKBfSNqz1HaTD l0xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bkApdkWvWiFEDIav7/0df5pV21zLwvIbgFh+FcyS4W4=; b=FiXU2pYQt+lPEPiiqfMICKLYH0wZoAUULEjs5VhxRmn0xXohahPEizyTiwK5e/f4ib fABXqJpGbQLxgm2IWNxsa+cgTPXWMOaLLiUPO55UKMTXAaf1d4fC92juyrpHYoSxNMSk i5SIiUnZESq01vv0c+eYKfWaBVmGMbt7ZmCHmEtWzwIyplMYkHZmcUF/ZuL4loOOEVct 49SDut8QfuqUguVD+YJC4m6U0hRXMAAk5posj3M1X7xXBJdAWCXvL59pauP6ujr2ttRd zS2JIxVUWNyIZSPI7YIXZ/Q3/5BJiOIwBCAlNcNkVKC+ooooufipAVlAsrX9dP8NsPgO TQlQ== X-Gm-Message-State: ALoCoQnAMxprAbuCthFz40ACDB6QestxFyv/eUdhV729gNNlz4bQMkc2W064Q7++OM8dtQ59ABbyO3iZYKqNNvSpL1y03fa6Xg== X-Received: by 10.13.246.130 with SMTP id g124mr15243963ywf.29.1453128034810; Mon, 18 Jan 2016 06:40:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.214 with HTTP; Mon, 18 Jan 2016 06:40:05 -0800 (PST) In-Reply-To: <569C4314.3090101@cs.ucla.edu> References: <569BF8F7.3090904@cs.ucla.edu> <569C4314.3090101@cs.ucla.edu> From: Richard Copley Date: Mon, 18 Jan 2016 14:40:05 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Paul Eggert Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: Eli Zaretskii , 22202@debbugs.gnu.org, Andreas Schwab , Demetri Obenour , David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 18 January 2016 at 01:42, Paul Eggert wrote: > Andreas Schwab discovered a problem with my patch in that GnuTLS wasn't > initialized, and reverted the GnuTLS part of it. As I understand it, newer > versions of GnuTLS initialize themselves when they are loaded and so do not > run into the issue; I tested with GnuTLS 3.3.15, which I suppose is new > enough. I attempted to fix this problem in the followup commit > 130d512045aa376333b664d58c501b3884187592. > > Andreas's commit also changed some unrelated style issues, which I reverted; > that is merely a longrunning stylistic disagreement, and right now is not a > good time to be changing style in code unrelated to fixes. I can't build from the current sources; the error is: CCLD temacs.exe sysdep.o: In function `init_random': C:/emacs/repo/emacs/src/sysdep.c:2108: undefined reference to `gnutls_rnd' C:/emacs/repo/emacs/src/sysdep.c:2108:(.text+0xf38): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `gnutls_rnd' collect2.exe: error: ld returned 1 exit status Configuration details (from last good build): In GNU Emacs 25.0.50.1 (x86_64-w64-mingw32) of 2016-01-14 built on 60678UHB Repository revision: dadb841a06aa1ffd6d17c04ef83140dbd1ad7307 Windowing system distributor 'Microsoft Corp.', version 6.1.7601 Configured using: 'configure --prefix /c/emacs/emacs-20160114-182403 --without-imagemagick --disable-dependency-tracking --enable-locallisppath=%emacs_dir%/../site-lisp 'CFLAGS=-Og -g -ggdb'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 10:45:51 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 15:45:51 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Mon, 18 Jan 2016 17:45:33 +0200 Message-Id: <83fuxuevs2.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <569BF8F7.3090904@cs.ucla.edu> (message from Paul Eggert on Sun, 17 Jan 2016 12:26:31 -0800) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 10:57:35 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 15:57:35 +0000 Received: from localhost ([127.0.0.1]:53006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLCBT-0001Ye-8X for submit@debbugs.gnu.org; Mon, 18 Jan 2016 10:57:35 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40078) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLCBR-0001YS-UF for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 10:57:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLCBJ-0003nh-Mc for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 10:57:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLCBJ-0003nc-JW; Mon, 18 Jan 2016 10:57:25 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1245 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLCBI-0001ar-Sg; Mon, 18 Jan 2016 10:57:25 -0500 Date: Mon, 18 Jan 2016 17:57:31 +0200 Message-Id: <837fj6ev84.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-reply-to: (message from Andy Moreton on Mon, 18 Jan 2016 12:04:34 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <569C4314.3090101@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Andy Moreton > Date: Mon, 18 Jan 2016 12:04:34 +0000 > > In addition, these changes require static or dynamic linking of gnutls, > which breaks the Windows builds (which use runtime imports for the gnutls DLLs). This part should be provisionally fixed now. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 11:05:24 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 16:05:24 +0000 Received: from localhost ([127.0.0.1]:53010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLCJ2-0001lS-0X for submit@debbugs.gnu.org; Mon, 18 Jan 2016 11:05:24 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42710) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLCJ0-0001lG-HK for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 11:05:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLCIs-0005Ox-Gp for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 11:05:16 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLCIn-0005MM-4I; Mon, 18 Jan 2016 11:05:09 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1252 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLCIl-0004dI-RG; Mon, 18 Jan 2016 11:05:08 -0500 Date: Mon, 18 Jan 2016 18:05:14 +0200 Message-Id: <834meaeuv9.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Mon, 18 Jan 2016 14:40:05 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <569C4314.3090101@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, eggert@cs.ucla.edu, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Richard Copley > Date: Mon, 18 Jan 2016 14:40:05 +0000 > Cc: 22202@debbugs.gnu.org, Eli Zaretskii , > Demetri Obenour , David Engster , > Andreas Schwab > > I can't build from the current sources; the error is: > > CCLD temacs.exe > sysdep.o: In function `init_random': > C:/emacs/repo/emacs/src/sysdep.c:2108: undefined reference to `gnutls_rnd' > C:/emacs/repo/emacs/src/sysdep.c:2108:(.text+0xf38): relocation > truncated to fit: R_X86_64_PC32 against undefined symbol `gnutls_rnd' > collect2.exe: error: ld returned 1 exit status Please try again. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 11:21:02 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 16:21:03 +0000 Received: from localhost ([127.0.0.1]:53038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLCYA-0002Ap-93 for submit@debbugs.gnu.org; Mon, 18 Jan 2016 11:21:02 -0500 Received: from mail-yk0-f178.google.com ([209.85.160.178]:35775) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLCY9-0002A1-0I for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 11:21:01 -0500 Received: by mail-yk0-f178.google.com with SMTP id x67so620166095ykd.2 for <22202@debbugs.gnu.org>; Mon, 18 Jan 2016 08:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JvAiOiofchCp9DWnR7TXxZL4B5oLwCN1bbR1IaC0bzQ=; b=yo/OKmt/e3T/5FKQ4+gxEI7onWcMeuCphr54+2Vlmn2raV576KNMiuRNKMvOGLMnoJ 9XN5zJWzKBC++TRezkqT8p6NdvK8zfFTwEaQOKdQ06xI3yTwAyJ+w6WG5ERbf0roQNx7 fshLe63EC8zxaulhiw0wWPdRdN03m1lhgRV+stwccHaiZ3rXPnl3eAzFQsEj46dnwm3J MFpWf2fKmhpHMBNZpnt/8TvD0SFS3wrWvo2i15WagcZ3RdTr0m35N95Bq/r/6xH65stn L2WwXZu4iPNcJbeRBhvmRHXkH2GFTZx4Rzd+hZzF4kFeInwZledyfaJXgcXlxnbkCXM8 4QgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JvAiOiofchCp9DWnR7TXxZL4B5oLwCN1bbR1IaC0bzQ=; b=kehXyyOBhkdvzHlJIt4s866hd4CABf9LjqeJtkXzABiV0uDE5bGBKgEDgpkCwCf/KZ IuySdLhu7HojZ9yU8sW7vG4d3ocBd6foHqWeTZYI10a8XXcstpNKu4lsRJxzSK7UCsdK WHixesiMhRW1qaHQWfBFOKUEQZNdkNpsBOW4waAiHVNGuS6jd8INIFp8qx/ygZR0nNQI XIzvDwSgWJ4Twn3PIEjeVcxaotwE7E2hdl2/kPnr4nGPHhqKiKDr42g0vaOM4ZSaUP7x P/fufZNrdfJhCwTjmkoHZwHimkoaFsqnDctjCn3hT/Zz1NUMnm83ZrzuBBUTVbgQ8eL9 /qTw== X-Gm-Message-State: ALoCoQnwkdFwtTUkywTNUlfLIHe8NJmUqYJaUsd1H5qoyxQEVbJeOk/w9UUsG+MwEbe6rX9DhQna1rSLCDB9I/HwTu2jPJ9Rzw== X-Received: by 10.37.57.15 with SMTP id g15mr5259903yba.41.1453134055654; Mon, 18 Jan 2016 08:20:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.214 with HTTP; Mon, 18 Jan 2016 08:20:26 -0800 (PST) In-Reply-To: <834meaeuv9.fsf@gnu.org> References: <569BF8F7.3090904@cs.ucla.edu> <569C4314.3090101@cs.ucla.edu> <834meaeuv9.fsf@gnu.org> From: Richard Copley Date: Mon, 18 Jan 2016 16:20:26 +0000 Message-ID: Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org, Paul Eggert , Andreas Schwab X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 18 January 2016 at 16:05, Eli Zaretskii wrote: >> From: Richard Copley >> Date: Mon, 18 Jan 2016 14:40:05 +0000 >> Cc: 22202@debbugs.gnu.org, Eli Zaretskii , >> Demetri Obenour , David Engster , >> Andreas Schwab >> >> I can't build from the current sources; the error is: >> >> CCLD temacs.exe >> sysdep.o: In function `init_random': >> C:/emacs/repo/emacs/src/sysdep.c:2108: undefined reference to `gnutls_rnd' >> C:/emacs/repo/emacs/src/sysdep.c:2108:(.text+0xf38): relocation >> truncated to fit: R_X86_64_PC32 against undefined symbol `gnutls_rnd' >> collect2.exe: error: ld returned 1 exit status > > Please try again. Fixed, thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 15:50:23 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 20:50:23 +0000 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 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 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) 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) 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 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) 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) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <569D5004.5080701@cs.ucla.edu> Date: Mon, 18 Jan 2016 12:50:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <83fuxuevs2.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------010408070103030800090806" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 16:10:15 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 21:10:15 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Mon, 18 Jan 2016 23:09:57 +0200 Message-Id: <83h9iad26y.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <569D5004.5080701@cs.ucla.edu> (message from Paul Eggert on Mon, 18 Jan 2016 12:50:12 -0800) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 18:13:31 2016 Received: (at 22202) by debbugs.gnu.org; 18 Jan 2016 23:13:31 +0000 Received: from localhost ([127.0.0.1]:53257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLIzK-00048L-Qp for submit@debbugs.gnu.org; Mon, 18 Jan 2016 18:13:30 -0500 Received: from mail-pa0-f49.google.com ([209.85.220.49]:34526) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLIzI-00047z-Ts for 22202@debbugs.gnu.org; Mon, 18 Jan 2016 18:13:29 -0500 Received: by mail-pa0-f49.google.com with SMTP id uo6so426493607pac.1 for <22202@debbugs.gnu.org>; Mon, 18 Jan 2016 15:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:reply-to:mime-version:content-type; bh=FdiFVSLzzwQ3YC42maveZxilrdaKjroGLUIUNbR9INI=; b=z4FLFynTIzEURgqVBb9W0wknOTpW8k/1uY6ZUlUmlrLomZMUD0xagr/Hidq38QNejC x5dI9fGQHIf5ixe/kK3aia8225+h6OzBNZZVml+Oa2OgbO3UU/rkArpJXpFjH82p24ZS KaJsb1Qtc3psC0hrhJmnvF1Ta82jvuDSHsxpuGegLlLAuNeUpNVDTA5W6OfmdOm6699b zjBe2o57ExXmLwaY0oyfhDC9CQPI460oAjRVT+oV3ggrc/lZxiu2x8EU5oIFsu3bO1RN v+XeqHPb4m/xzr8MDoSmbDDRxSEkKRVYxTAwQLRvRNBnnNvZJiofO4SwxBCWd7R0tBjT 1SkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:reply-to:mime-version:content-type; bh=FdiFVSLzzwQ3YC42maveZxilrdaKjroGLUIUNbR9INI=; b=hcKrWXOJlROoDdDkxg77ogiCkrOQUPIHLbGOx7VJ5X7hVRcrtXbES8ZlMe/6GDP/NS kZIgQACErm3uom/vWbF2StUj0X85nmrcJ3jGOBZE+Ia11DiEpnTpvDBW6lwWsYoHbtls K4P3N0+oEqLoHeN9/u2LX+VyOI06VeiJUD5gZtR4dNoMKI/kinGhpiqsEGEJ6Kcv+gjO 0VghR9DjrGeFObYQydKT/8lcm8+q3K4NWsrJIrPZqEgQ2nVU5whLlYYzl4UKpMTxJ24k uBtAKZwIgDVeWnqPCG9kIxTt8M3dpguemug4ixfeQ+vymc3RqqinSdiaBAjy6WpV0P/o keWw== X-Gm-Message-State: ALoCoQnrzRGoMBWIsgyUATh6IzPUOjnVy8LOWX2h1HZdzAU+UdJH5PYAJL9o6poUfUXcRVKCL2razEO3etSGScns9sSwdtpbrw== X-Received: by 10.66.150.37 with SMTP id uf5mr40577473pab.30.1453158803247; Mon, 18 Jan 2016 15:13:23 -0800 (PST) Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id i76sm36352870pfj.68.2016.01.18.15.13.22 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 18 Jan 2016 15:13:22 -0800 (PST) From: John Wiegley X-Google-Original-From: "John Wiegley" Received: by Vulcan.local (Postfix, from userid 501) id 637B0124C7D86; Mon, 18 Jan 2016 15:13:21 -0800 (PST) To: Andy Moreton Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems In-Reply-To: (Andy Moreton's message of "Mon, 18 Jan 2016 12:04:34 +0000") Date: Mon, 18 Jan 2016 15:03:40 -0800 Message-ID: References: <569BF8F7.3090904@cs.ucla.edu> <569C4314.3090101@cs.ucla.edu> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (darwin) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: John Wiegley Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Andy Moreton writes: > This is rudeness from both of you: please solve this disagreement by talk= ing > to each other instead of adding pointless churn to the source tree. Whenever possible, resolving arguments by words rather than commits is truly preferable. =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJWnW9MAAoJEMFE2PTxn+YwoOwL/1fFmUrEcwxgwYp202v/qON1 iLXTdNvgh1D5xDAWRwriRFL3wV8WfDqWF54m/OOBvf0cNl8DCTLWIqfwetcE4sly 5+mqzuMqu6C5JrbsyiJJpV5gNaw/lT3LRei0DaoVk4ZgCQqt7aYcDJ7++nbZJZLN yhE0EupDA+z4b1+NIeMEhwQPwcby2v6tgR+KzSRQ/ciUtnL7gB4FOXOCLksJBuvt 2S/MP1K9Ip+Yxg2slC/QSb8wnLUrfpYFk2MCdXzuknM1us9+27LS8ZUCghlzZSM0 1sAai8KzVOV2KliosolxRQg3QgcTTK4/XeoD0hC+HmnO4jCwyGq0hfYyhYYgmm48 GWML1p9FMPqJnvFnnEtbIhOCsTTssSEtuEwanjcc7ag1BqyZTHRuCAYpkx18Ur9y XgTUHFdttl6JAsS1nt9WzUbVWFi6VY2h3JMrf6XdICP7cDqJLb1sb5yhlYf4Oavj yfpYc0D8zTHvWaJKiCgnZR4g9e7jILPSfCxX+qFY3g== =lhEs -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 00:34:21 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 05:34:21 +0000 Received: from localhost ([127.0.0.1]:53308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLOvt-0006Sq-KZ for submit@debbugs.gnu.org; Tue, 19 Jan 2016 00:34:21 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54004) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLOvr-0006Sd-P7 for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 00:34:20 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E36F5160E67; Mon, 18 Jan 2016 21:34:13 -0800 (PST) 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 Jw7KppiUVhAb; Mon, 18 Jan 2016 21:34:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2FFDE160E6B; Mon, 18 Jan 2016 21:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 qxZemAbncf1F; Mon, 18 Jan 2016 21:34:13 -0800 (PST) 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 F3746160E67; Mon, 18 Jan 2016 21:34:12 -0800 (PST) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <569DCAD4.30606@cs.ucla.edu> Date: Mon, 18 Jan 2016 21:34:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <83h9iad26y.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli Zaretskii wrote: > We all silently fix blunders and other trivial problems; this wasn't one of > them. I thought it a trivial matter; evidently I was mistaken. My apologies. > 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. 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. > 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. 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. > So what is special about GnuTLS? GnuTLS already has the random data we need; other libraries don't. I installed the documentation patch, since it does seem a minor improvement. Yes, the doc could have been improved ages ago, but late is better than never. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 11:24:23 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 16:24:23 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Tue, 19 Jan 2016 18:24:00 +0200 Message-Id: <83y4blbkrj.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert , John Wiegley In-reply-to: <569DCAD4.30606@cs.ucla.edu> (message from Paul Eggert on Mon, 18 Jan 2016 21:34:12 -0800) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 12:03:31 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 17:03:31 +0000 Received: from localhost ([127.0.0.1]:53936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZgo-0004ey-Jx for submit@debbugs.gnu.org; Tue, 19 Jan 2016 12:03:30 -0500 Received: from mail-pf0-f170.google.com ([209.85.192.170]:36614) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZgm-0004ej-Ku for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 12:03:29 -0500 Received: by mail-pf0-f170.google.com with SMTP id n128so178251671pfn.3 for <22202@debbugs.gnu.org>; Tue, 19 Jan 2016 09:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:reply-to:mime-version:content-type; bh=0pZKbAMibBjPnLg2/SiuLFQfqX60pmOcq+5TUCpnhA8=; b=HCjIfZyAzQiaUSu3JMhjnZDgxFjItogxIiRguamTxRs3pwkbHSjnixJMxTva31Wc4j OB2ol9ucMjFouAM+VwNSkJNr37KD+0ypBRxt8vDtiRXIQy7FcVw7rM007TxtGhjBLXm8 rBjl2WU7IPBkXsmygjYHi0TzDcp51VNURSHD7fk1E2jHClPL2Y9054y3i3NW9F+0Vf72 /cuE8II/MpDD2ZsR6U/bH45zhNo4fc2/QAu20MCng/yEWAomf6OQWFuhreSMNJJVae3r 9oosUTuVXtQVBUljmNqZSiYJDQ+gaD2/DBhDS8KME6HtfgxOTvOUVPqn/6IbIqC5he47 JKvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:reply-to:mime-version:content-type; bh=0pZKbAMibBjPnLg2/SiuLFQfqX60pmOcq+5TUCpnhA8=; b=cfKzmqcqlOIRBrmYkZJTR4L+b1/uhDCLxLOJAx1SJgEg1JOq2RgaG6LWUvGGMF5BbD pJq1XhcmZii1NTW9RdVbce6C+BdMtgYW3Wx9rT/RSjeKYyzQT71YBKfSnA8Rg9G6jF1p oKv4G5L+fmGpu79SXreCgq1JwUTDHdkEFVx1wWDvfHh5SDesYu61eP1V4WEM+NWehk68 7KwzGpxFs6XpPLE9EXN0mGACK/aFoQK6k7mJf265+IBCGPFJXJVXcKLvufFmxvfr1QWR 5XRRocLG1xITvLRjVsgRLXp/nG8vrqmBJSMsFnHWYNJAygTjpXCpAgogiKN3eAOht+4/ zgnQ== X-Gm-Message-State: ALoCoQnX1CdVJFZHjOsRTVegNTcOJ1P6LDRKWEbZ8wUpbBm2/FFSYEudTzQKx9M/fBkrkKqHen6zGktm3EXnEFoH3blB9B6qgg== X-Received: by 10.98.76.92 with SMTP id z89mr45855131pfa.91.1453223002995; Tue, 19 Jan 2016 09:03:22 -0800 (PST) Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id 11sm42690862pfq.87.2016.01.19.09.03.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Jan 2016 09:03:21 -0800 (PST) From: John Wiegley X-Google-Original-From: John Wiegley Received: by Vulcan.local (Postfix, from userid 501) id 3A23C124F7A03; Tue, 19 Jan 2016 09:03:20 -0800 (PST) To: Eli Zaretskii Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems In-Reply-To: <83y4blbkrj.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jan 2016 18:24:00 +0200") Date: Tue, 19 Jan 2016 09:03:17 -0800 Message-ID: References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (darwin) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, Paul Eggert , deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: John Wiegley Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Eli Zaretskii writes: > 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. From=20what I've read, I agree with you Eli. If we can open /dev/urandom, w= hy do we need a dependency on GnuTLS to effectively do the same thing? What critical feature is GnuTLS buying for us that would make this worthwhi= le, Paul? =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJWnmxVAAoJEMFE2PTxn+YwuxQL/RVu4PyzUzGc+QJEc6X+7/rM q8SSDx+2IoDXiQEeS/NSF+iPd7WekYw7D1T8aaU7O0WUyApUkmVpyH2ZZzxpNvAO r/5orW8M3YIXR7gCcKnQQYBnGLcFIJ0oFTSd3HonHdC3QXMguidqnpvm1x2IXzdd OKLbCm8yfYpInsH3wjTMH6kCaUurZzL9OMFaPVw92D/UqmHol9wJZ7vNdxljDQOe 8qbFcWc6j54K/UxW8wswx3HTSKry0hnJWTmztFwQElRcwgZ+UaGXEkMD1SrK4jWK aLWeN5BiiM2Qq+FdfNrOeS9o2q+B2H6ylidIiG2PGfym58LOjQnKAJ9UPmtmQrcQ ymAr0oLrslC7sLprKTXNx+OaW5Ag1OKLhxD/94DqM+u0E3RDR7dJGplpvMUaaH++ KZr2zEc9WuiiaDFwtbkk+pe4tVAwz5jSzmBQnOXZ7R3230LmnAsyMgib2VL5ueAg n9EpJaN15kjCHcXT5lwhthCHe0DuviJxejLKdnlh7A== =koc5 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 12:07:24 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 17:07:24 +0000 Received: from localhost ([127.0.0.1]:53940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZka-0004ky-8m for submit@debbugs.gnu.org; Tue, 19 Jan 2016 12:07:24 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47045) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLZkY-0004kl-F4 for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 12:07:23 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A4534160E75; Tue, 19 Jan 2016 09:07:16 -0800 (PST) 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 LVZG-tly3tho; Tue, 19 Jan 2016 09:07:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 96ED3160D77; Tue, 19 Jan 2016 09:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 eLOtysR863Nc; Tue, 19 Jan 2016 09:07:15 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7B5EC160E73; Tue, 19 Jan 2016 09:07:15 -0800 (PST) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii , John Wiegley References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <569E6D43.5080705@cs.ucla.edu> Date: Tue, 19 Jan 2016 09:07:15 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <83y4blbkrj.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 01/19/2016 08:24 AM, Eli Zaretskii wrote: > So it's a bug or misfeature in GnuTLS. GnuTLS has been operating that way for a while, and it works. Calling its behavior a "bug or misfeature" seems a stretch. If we change Emacs back to always read /dev/urandom by hand as well has have GnuTLS read /dev/urandom at startup, this will cause Emacs to exhaust the GNU/Linux entropy pool more quickly. This may slow down other programs that read /dev/random (a device that blocks until entropy is available). So there is an overall system benefit to minimizing the use of /dev/urandom, which was the point of my original patch. >> 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. Any explanation they come up with will have to be part of our explanation, since we're responsible for Emacs. Our explanation will also have to cover Emacs's added accesses, so minimizing them will be a win. >> 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. In that case GnuTLS's nonce generator is random enough for our purposes, and we have a good idea of what kind of randomness we get. > >> 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. If we stop trusting or using GnuTLS, the code will still get a secure random seed by hand, so that's not a problem. But currently we do trust and use GnuTLS by default, and there are no plans to change this. > 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. They are not the same system calls. If they were the same, you would be right and we shouldn't bother with GnuTLS here. They are different sequences of system calls, and the sequence that uses GnuTLS lessens entropy consumption and simplifies audits. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 12:38:33 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 17:38:33 +0000 Received: from localhost ([127.0.0.1]:53961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLaEi-0005XC-SU for submit@debbugs.gnu.org; Tue, 19 Jan 2016 12:38:33 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49685) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLaEh-0005Ww-0B for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 12:38:31 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5460F160D05; Tue, 19 Jan 2016 09:38:24 -0800 (PST) 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 tJE2GHAKsWQj; Tue, 19 Jan 2016 09:38:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 51A26160D77; Tue, 19 Jan 2016 09:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 DY4aOOJ4MU3g; Tue, 19 Jan 2016 09:38:23 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3795E160D05; Tue, 19 Jan 2016 09:38:23 -0800 (PST) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: John Wiegley , Eli Zaretskii References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <569E748F.6090800@cs.ucla.edu> Date: Tue, 19 Jan 2016 09:38:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 01/19/2016 09:03 AM, John Wiegley wrote: > What critical feature is GnuTLS buying for us that would make this worthwhile, > Paul? There is nothing "critical" here. This is just a minor issue, one that has been blown all out of proportion. Using GnuTLS when available lessens use of system resources and simplifies auditing, but Emacs could get by without this minor bugfix-improvement. > why do we need a dependency on GnuTLS There isn't a dependency on GnuTLS in the usual sense: that is, if GnuTLS is absent, the code still works as before. The only dependency is that we trust the GnuTLS library to work when it is present, and to report an error if one occurs. This is a reasonable assumption, both here and elsewhere in Emacs. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 13:16:52 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 18:16:52 +0000 Received: from localhost ([127.0.0.1]:53988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLapn-0007C4-Rg for submit@debbugs.gnu.org; Tue, 19 Jan 2016 13:16:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35162) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLapm-0007Bt-JO for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 13:16:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLapg-00039O-7h for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 13:16:45 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLapQ-000355-UW; Tue, 19 Jan 2016 13:16:28 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2259 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLapQ-00075z-3X; Tue, 19 Jan 2016 13:16:28 -0500 Date: Tue, 19 Jan 2016 20:16:36 +0200 Message-Id: <83k2n5bfjv.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <569E6D43.5080705@cs.ucla.edu> (message from Paul Eggert on Tue, 19 Jan 2016 09:07:15 -0800) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <569E6D43.5080705@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, johnw@gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de > From: Paul Eggert > Date: Tue, 19 Jan 2016 09:07:15 -0800 > > On 01/19/2016 08:24 AM, Eli Zaretskii wrote: > > So it's a bug or misfeature in GnuTLS. > > GnuTLS has been operating that way for a while, and it works. Calling > its behavior a "bug or misfeature" seems a stretch. You said it was a problem to have one more handle open, not I. So it's you who maintains this is a problem (a.k.a. "misfeature"). If you are now saying it's okay to have the device open, then it's not a problem to have it open twice for a short while. IOW, please make up your mind whether this is an issue or not. > If we change Emacs back to always read /dev/urandom by hand as well has > have GnuTLS read /dev/urandom at startup, this will cause Emacs to > exhaust the GNU/Linux entropy pool more quickly. This may slow down > other programs that read /dev/random (a device that blocks until entropy > is available). So there is an overall system benefit to minimizing the > use of /dev/urandom, which was the point of my original patch. Now, _that's_ a stretch. We only read /dev/urandom once, that's all. You cannot be serious saying that a single call will deplete the system entropy. > >> 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. > > Any explanation they come up with will have to be part of our > explanation No, it doesn't. We cannot be responsible for the internals of 3rd-party libraries. > >> 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. > > In that case GnuTLS's nonce generator is random enough for our purposes, > and we have a good idea of what kind of randomness we get. Today, we do. Tomorrow, it's anyone's guess. Unless we audit their code all the time. Why should we? > >> 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. > > If we stop trusting or using GnuTLS, the code will still get a secure > random seed by hand, so that's not a problem. But currently we do trust > and use GnuTLS by default, and there are no plans to change this. That trust needs now to be ascertained even if we don't use secure communications from Emacs. So things got worse. > > 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. > > They are not the same system calls. If they were the same, you would be > right and we shouldn't bother with GnuTLS here. They are different > sequences of system calls, and the sequence that uses GnuTLS lessens > entropy consumption and simplifies audits. I've read the code and saw no differences. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 13:45:10 2016 Received: (at 22202) by debbugs.gnu.org; 19 Jan 2016 18:45:10 +0000 Received: from localhost ([127.0.0.1]:54015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLbHC-0001Km-6M for submit@debbugs.gnu.org; Tue, 19 Jan 2016 13:45:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43944) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLbHB-0001D4-Cv for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 13:45:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLbH5-00026v-DO for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 13:45:04 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLbGr-0001xj-AD; Tue, 19 Jan 2016 13:44:49 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2290 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLbGq-0007bD-Ee; Tue, 19 Jan 2016 13:44:48 -0500 Date: Tue, 19 Jan 2016 20:44:56 +0200 Message-Id: <83egddbe8n.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <569E748F.6090800@cs.ucla.edu> (message from Paul Eggert on Tue, 19 Jan 2016 09:38:23 -0800) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <569E748F.6090800@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, johnw@gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de > From: Paul Eggert > Date: Tue, 19 Jan 2016 09:38:23 -0800 > > This is just a minor issue, one that has been blown all out of > proportion. This is unfair: if this minor issue was important enough for you to make those changes, then objecting to them cannot be considered "blowing it all out of proportion". From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 16:49:28 2016 Received: (at submit) by debbugs.gnu.org; 19 Jan 2016 21:49:28 +0000 Received: from localhost ([127.0.0.1]:54126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLe9Y-0000fe-Gu for submit@debbugs.gnu.org; Tue, 19 Jan 2016 16:49:28 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41831) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLe9W-0000fN-WE for submit@debbugs.gnu.org; Tue, 19 Jan 2016 16:49:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLe9P-0007SY-4Y for submit@debbugs.gnu.org; Tue, 19 Jan 2016 16:49:21 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLe9O-0007SO-Uo for submit@debbugs.gnu.org; Tue, 19 Jan 2016 16:49:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLe9K-0006WH-H9 for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 16:49:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLe9G-0007NQ-OZ for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 16:49:14 -0500 Received: from plane.gmane.org ([80.91.229.3]:49526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLe9G-0007MY-G3 for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 16:49:10 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aLe9E-0000Hf-E7 for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2016 22:49:08 +0100 Received: from 82-69-64-228.dsl.in-addr.zen.co.uk ([82.69.64.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jan 2016 22:49:08 +0100 Received: from andrewjmoreton by 82-69-64-228.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jan 2016 22:49:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Date: Tue, 19 Jan 2016 21:48:58 +0000 Lines: 35 Message-ID: <86mvs1fdf9.fsf@gmail.com> References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82-69-64-228.dsl.in-addr.zen.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) Cancel-Lock: sha1:3No5cr+JqrjBElLzcPrqsxKhQ7I= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) On Tue 19 Jan 2016, John Wiegley wrote: >>>>>> Eli Zaretskii writes: > >> 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. > > From what I've read, I agree with you Eli. If we can open /dev/urandom, why do > we need a dependency on GnuTLS to effectively do the same thing? > > What critical feature is GnuTLS buying for us that would make this worthwhile, > Paul? As far as I can see, this set of patches attempted to fix a minor problem, but in doing so: - added unnecessary dependencies on gnutls libraries - broke the Windows builds (which use runtime linking for gnutls) - broke all builds configured with "--without-gnutls" I am happy for the original issue to be addressed, but only if all of the issues listed above are addressed. In particular, it must remain possible to build on a system that does not have gnutls headers and libraries installed, or to disable gnutls support even if the headers and libraries are present. AndyM From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 19:39:13 2016 Received: (at 22202) by debbugs.gnu.org; 20 Jan 2016 00:39:13 +0000 Received: from localhost ([127.0.0.1]:54161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLgnp-0006WZ-Fb for submit@debbugs.gnu.org; Tue, 19 Jan 2016 19:39:13 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48429) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLgnn-0006WJ-KI for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 19:39:12 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BD0511608D3; Tue, 19 Jan 2016 16:39:05 -0800 (PST) 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 Ze4aVy34rBHF; Tue, 19 Jan 2016 16:39:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A0272160D77; Tue, 19 Jan 2016 16:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 m_O21_K9p-50; Tue, 19 Jan 2016 16:39:03 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 815591608D3; Tue, 19 Jan 2016 16:39:03 -0800 (PST) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems To: Eli Zaretskii References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <569E6D43.5080705@cs.ucla.edu> <83k2n5bfjv.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <569ED727.5060509@cs.ucla.edu> Date: Tue, 19 Jan 2016 16:39:03 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <83k2n5bfjv.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 22202 Cc: rcopley@gmail.com, 22202@debbugs.gnu.org, johnw@gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 01/19/2016 10:16 AM, Eli Zaretskii wrote: >> Cc: 22202@debbugs.gnu.org, rcopley@gmail.com, deng@randomsample.de >> From: Paul Eggert >> Date: Tue, 19 Jan 2016 09:07:15 -0800 >> >> On 01/19/2016 08:24 AM, Eli Zaretskii wrote: >>> So it's a bug or misfeature in GnuTLS. >> GnuTLS has been operating that way for a while, and it works. Calling >> its behavior a "bug or misfeature" seems a stretch. > You said it was a problem to have one more handle open, not I. So > it's you who maintains this is a problem (a.k.a. "misfeature"). If > you are now saying it's okay to have the device open, then it's not a > problem to have it open twice for a short while. There is no contradiction here. Although having multiple file descriptors for the same file is only a minor problem, that does not mean it is not a problem at all, nor does it mean that the minor problem is entirely in GnuTLS as opposed to being in the combination of GnuTLS and Emacs. I did not say GnuTLS's behavior is a misfeature or bug; such a characterization would go too far. > You cannot be serious saying that a single call will deplete the > system entropy. Although the entropy will not be completely depleted, reading excess bytes from /dev/urandom can exhaust the entropy pool more quickly. On GNU/Linux, processes reading /dev/urandom can fairly quickly drain system entropy down to a couple hundred bits. Reads of /dev/random can then drain the remaining bits and subsequent reads will hang. Although the kernel eventually will reacquire system entropy, acquisition rates can be less than one bit per second, so reading excess data from /dev/urandom is not cost-free here. > >>>> 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. >> Any explanation they come up with will have to be part of our >> explanation > No, it doesn't. We cannot be responsible for the internals of > 3rd-party libraries. We are not responsible for GnuTLS internals, but for audits we are responsible for explaining unusual behaviors. It's like many other aspects of libraries that Emacs uses: for example, although we are not responsible for ImageMagick internals, if those internals allocate a lot of memory and cause Emacs to hang or crash, we are responsible for the overall behavior. >>>> 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. >> In that case GnuTLS's nonce generator is random enough for our purposes, >> and we have a good idea of what kind of randomness we get. > Today, we do. Tomorrow, it's anyone's guess. Unless we audit their > code all the time. Why should we? We never really needed to audit the GnuTLS code in the first place. We went into it only because of concerns that GnuTLS might not do the right thing, due to lack of understanding about GnuTLS. These concerns have been addressed, and there should be no need to keep revisiting the issue. > That trust needs now to be ascertained even if we don't use secure > communications from Emacs. Sorry, I'm not following. If the point is that GnuTLS should be trusted for secure communications (which is relatively complicated) but not for generating nonces (which is relatively simple) then I don't see a sound basis for this worry. If GnuTLS can't be trusted for simple building blocks, why trust it for complex things? Especially when the complex things are based on the simple building blocks? >>> 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. >> They are not the same system calls. If they were the same, you would be >> right and we shouldn't bother with GnuTLS here. They are different >> sequences of system calls, and the sequence that uses GnuTLS lessens >> entropy consumption and simplifies audits. > I've read the code and saw no differences. You can try running it both ways under "strace" in GNU/Linux. You should see different sequences of system calls involving /dev/urandom. That's what happened for me. >> This is just a minor issue, one that has been blown all out of >> proportion. > This is unfair: if this minor issue was important enough for you to > make those changes, then objecting to them cannot be considered > "blowing it all out of proportion". Yes, a simple objection to a minor change would not blow it all out of proportion. But this long thread is more than that. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 19 22:31:36 2016 Received: (at 22202) by debbugs.gnu.org; 20 Jan 2016 03:31:36 +0000 Received: from localhost ([127.0.0.1]:54246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLjUe-0004Fg-Dh for submit@debbugs.gnu.org; Tue, 19 Jan 2016 22:31:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37876) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLjUd-0004FT-LL for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 22:31:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLjUX-00056b-VG for 22202@debbugs.gnu.org; Tue, 19 Jan 2016 22:31:30 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLjUW-00056G-2U; Tue, 19 Jan 2016 22:31:28 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1aLjUU-0005F5-SU; Tue, 19 Jan 2016 22:31:27 -0500 From: Glenn Morris To: Andy Moreton Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <86mvs1fdf9.fsf@gmail.com> X-Spook: Watergate Secure Border Initiative Belknap Axis of Evil X-Ran: d&~CjW~wJ+oXKP!Cg+IsBb0";J5OH"9z~\zL7(^[c0SzT|{@:MwZm\of,sVNrT;yubnQ:. X-Hue: yellow X-Attribution: GM Date: Tue, 19 Jan 2016 22:31:26 -0500 In-Reply-To: <86mvs1fdf9.fsf@gmail.com> (Andy Moreton's message of "Tue, 19 Jan 2016 21:48:58 +0000") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Andy Moreton wrote: > - broke all builds configured with "--without-gnutls" AFAICS, you are mistaken. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 20 09:07:14 2016 Received: (at submit) by debbugs.gnu.org; 20 Jan 2016 14:07:14 +0000 Received: from localhost ([127.0.0.1]:54516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLtPl-00067C-TZ for submit@debbugs.gnu.org; Wed, 20 Jan 2016 09:07:14 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36085) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLtPj-00066v-Ih for submit@debbugs.gnu.org; Wed, 20 Jan 2016 09:07:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLtPa-000703-Ar for submit@debbugs.gnu.org; Wed, 20 Jan 2016 09:07:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLtPa-0006zy-7q for submit@debbugs.gnu.org; Wed, 20 Jan 2016 09:07:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLtPZ-0008KJ-CQ for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 09:07:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLtPW-0006xw-6v for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 09:07:01 -0500 Received: from plane.gmane.org ([80.91.229.3]:42172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLtPW-0006xo-0J for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 09:06:58 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aLtPU-0001of-5y for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 15:06:56 +0100 Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2016 15:06:56 +0100 Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2016 15:06:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Date: Wed, 20 Jan 2016 14:06:42 +0000 Lines: 24 Message-ID: References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <86mvs1fdf9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt) Cancel-Lock: sha1:Go8gMryfsmWwSNwiQQ0a3qzAylo= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) On Tue 19 Jan 2016, Glenn Morris wrote: > Andy Moreton wrote: > >> - broke all builds configured with "--without-gnutls" > > AFAICS, you are mistaken. I may well be, but please explain. src/sysdep.c (at emacs-25 commit c5ee6de21d4b) contains: #include "gnutls.h" #if 0x020c00 <= GNUTLS_VERSION_NUMBER && !defined WINDOWSNT # include #else # define emacs_gnutls_global_init() Qnil # define gnutls_rnd(level, data, len) (-1) #endif How can this build properly on a non-Windows system which does not contain an installed "gnutls.h" header ? AndyM From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 20 09:12:10 2016 Received: (at 22202) by debbugs.gnu.org; 20 Jan 2016 14:12:10 +0000 Received: from localhost ([127.0.0.1]:54520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLtUY-0006ER-Fs for submit@debbugs.gnu.org; Wed, 20 Jan 2016 09:12:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37507) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLtUW-0006EC-Ri for 22202@debbugs.gnu.org; Wed, 20 Jan 2016 09:12:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLtUL-0000DW-VZ for 22202@debbugs.gnu.org; Wed, 20 Jan 2016 09:12:03 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLtUL-0000DO-Si; Wed, 20 Jan 2016 09:11:57 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3535 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLtUL-0000uj-9Z; Wed, 20 Jan 2016 09:11:57 -0500 Date: Wed, 20 Jan 2016 16:12:09 +0200 Message-Id: <83egdc9w7a.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-reply-to: (message from Andy Moreton on Wed, 20 Jan 2016 14:06:42 +0000) Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <86mvs1fdf9.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22202 Cc: 22202@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Andy Moreton > Date: Wed, 20 Jan 2016 14:06:42 +0000 > > On Tue 19 Jan 2016, Glenn Morris wrote: > > > Andy Moreton wrote: > > > >> - broke all builds configured with "--without-gnutls" > > > > AFAICS, you are mistaken. > > I may well be, but please explain. > src/sysdep.c (at emacs-25 commit c5ee6de21d4b) contains: > > #include "gnutls.h" > #if 0x020c00 <= GNUTLS_VERSION_NUMBER && !defined WINDOWSNT > # include > #else > # define emacs_gnutls_global_init() Qnil > # define gnutls_rnd(level, data, len) (-1) > #endif > > How can this build properly on a non-Windows system which does not > contain an installed "gnutls.h" header ? That's src/gnutls.h header that comes with Emacs sources. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 20 10:15:34 2016 Received: (at submit) by debbugs.gnu.org; 20 Jan 2016 15:15:34 +0000 Received: from localhost ([127.0.0.1]:55445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLuTu-00080Q-JR for submit@debbugs.gnu.org; Wed, 20 Jan 2016 10:15:34 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53300) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aLuTs-00080C-9g for submit@debbugs.gnu.org; Wed, 20 Jan 2016 10:15:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLuTj-0007Po-Qn for submit@debbugs.gnu.org; Wed, 20 Jan 2016 10:15:26 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:39505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLuTj-0007Ph-Nx for submit@debbugs.gnu.org; Wed, 20 Jan 2016 10:15:23 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLuTd-0007QR-IS for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 10:15:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLuTX-0007Ks-TP for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 10:15:17 -0500 Received: from plane.gmane.org ([80.91.229.3]:47611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLuTX-0007KA-Nz for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 10:15:11 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aLuTV-0004uJ-Ke for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2016 16:15:09 +0100 Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2016 16:15:09 +0100 Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2016 16:15:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems Date: Wed, 20 Jan 2016 15:15:02 +0000 Lines: 32 Message-ID: References: <569BF8F7.3090904@cs.ucla.edu> <83fuxuevs2.fsf@gnu.org> <569D5004.5080701@cs.ucla.edu> <83h9iad26y.fsf@gnu.org> <569DCAD4.30606@cs.ucla.edu> <83y4blbkrj.fsf@gnu.org> <86mvs1fdf9.fsf@gmail.com> <83egdc9w7a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) Cancel-Lock: sha1:wt+1FfiB3tAXHtrYF3fQ2j7Ex+8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) On Wed 20 Jan 2016, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Wed, 20 Jan 2016 14:06:42 +0000 >> >> On Tue 19 Jan 2016, Glenn Morris wrote: >> >> > Andy Moreton wrote: >> > >> >> - broke all builds configured with "--without-gnutls" >> > >> > AFAICS, you are mistaken. >> >> I may well be, but please explain. >> src/sysdep.c (at emacs-25 commit c5ee6de21d4b) contains: >> >> #include "gnutls.h" >> #if 0x020c00 <= GNUTLS_VERSION_NUMBER && !defined WINDOWSNT >> # include >> #else >> # define emacs_gnutls_global_init() Qnil >> # define gnutls_rnd(level, data, len) (-1) >> #endif >> >> How can this build properly on a non-Windows system which does not >> contain an installed "gnutls.h" header ? > > That's src/gnutls.h header that comes with Emacs sources. Thanks - I knew it had to be something obvious. Sorry for the noise. AndyM From unknown Thu Aug 14 21:53:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 18 Feb 2016 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator