From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Date: Tue, 15 Aug 2017 22:06:38 -0700 Organization: UCLA Computer Science Department Message-ID: References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> <83o9rignt6.fsf@gnu.org> <83d17whl72.fsf@gnu.org> <8e6de468-600c-4f2d-a21a-c2ff3a63d065@cs.ucla.edu> <83zib0g221.fsf@gnu.org> <2bb4b7ee-6bf9-df3d-5cd8-ae7992b9f2e7@cs.ucla.edu> <83wp64fdc4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1502860041 17008 195.159.176.226 (16 Aug 2017 05:07:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 Aug 2017 05:07:21 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 16 07:07:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhqXv-0003rP-Id for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Aug 2017 07:07:11 +0200 Original-Received: from localhost ([::1]:50204 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhqY1-0002d8-Rm for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Aug 2017 01:07:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhqXq-0002bl-VM for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 01:07:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhqXm-0007T8-VR for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 01:07:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59679) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dhqXm-0007Sy-R9 for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 01:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dhqXm-00068Z-Go for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 01:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2017 05:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27986 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 27986-submit@debbugs.gnu.org id=B27986.150286000923547 (code B ref 27986); Wed, 16 Aug 2017 05:07:02 +0000 Original-Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 05:06:49 +0000 Original-Received: from localhost ([127.0.0.1]:40127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhqXZ-00067i-Co for submit@debbugs.gnu.org; Wed, 16 Aug 2017 01:06:49 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhqXX-00067V-Bv for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 01:06:48 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 99EC6160869; Tue, 15 Aug 2017 22:06:39 -0700 (PDT) Original-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 vHaDN3bP924r; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A5FA816086A; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-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 prAQ1nS0k-H5; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 80787160869; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) In-Reply-To: <83wp64fdc4.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135800 Archived-At: Eli Zaretskii wrote: > Knowing how Emacs works is not enough: they need to actually know the > name of the directory to create, By "knowing how Emacs works" I meant all of Emacs, including the Lisp pro= gram=20 that it is running. We cannot rely on security-via-obscurity; we must ass= ume=20 that the attackers know not only the Emacs C source code, but the Lisp co= de that=20 Emacs runs. Such an attacker will know the name of the directory to creat= e. >>> And how is this case different from the case that Emacs calls >>> (rename-file A B) thinking B doesn't exist (e.g., because some prior >>> code tested that)? >> >> The case in question trashes a directory that the attacker lacks permi= ssion to. >> The case you're talking about does not: it merely causes rename-file t= o fail. >=20 > No, it's the same use case. In both of them the attacker creates a > directory ahead of Emacs using it in some system call. Sure, but in the use case I'm talking about, the attacker can trash the v= ictim's=20 directory even though it's write-protected. In the case you're talking ab= out,=20 the attacker can't do anything other than what the attacker could do alre= ady. >> Another possibility is to implement new functions (say: file-copy, fil= e-rename, >> file-link, file-symlink, and directory-copy) that behave like the exis= ting >> functions except without the security hole, modify callers to use thes= e new >> functions, and then mark the existing functions as deprecated due to s= ecurity >> concerns. >=20 > If no other solution is possible, maybe this is what we should do. If > we decide to go that way, we should also decide what to do with the > interactive use of those functions: whether to call the old or the new > variant, because we need to keep backward compatibility there as well. I don't see why. If a user calls M-x copy-file interactively they'll get = the old=20 function; if they call M-x file-copy they'll get the new one. Admittedly = there=20 will be confusion (see below). >> I suspect that this would be more disruptive overall than the proposed >> change, though (albeit disruptive in a different way). >=20 > How so? It'll be disruption caused by the extra complexity: pairs of functions th= at do=20 nearly the same thing, with user confusion over which function to call, a= nd=20 people calling the wrong one. Tramp will need at least four new methods t= o=20 support, probably more. The complexity and confusion will go on and on, a= nd will=20 cost more than will be saved by the backward compatibility. It would be w= orth=20 all this trouble if people needed the old behavior, but they mostly do no= t.