From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?UTF-8?Q?Bay=C4=B1rl=C4=B1/Kammer?=) Newsgroups: gmane.emacs.bugs Subject: bug#21702: shell-quote-argument semantics and safety Date: Sun, 18 Oct 2015 21:12:34 +0200 Message-ID: <874mhoq9ct.fsf@T420.taylan> References: <871tcstkuk.fsf@T420.taylan> <83pp0chzax.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445195599 2569 80.91.229.3 (18 Oct 2015 19:13:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 19:13:19 +0000 (UTC) Cc: 21702@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 18 21:13:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZntOI-0002nt-FA for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2015 21:13:10 +0200 Original-Received: from localhost ([::1]:35244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZntOH-0004Qu-LJ for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2015 15:13:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZntOE-0004Qp-7u for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 15:13:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZntOA-0000Pc-V0 for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 15:13:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZntOA-0000PY-RA for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 15:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZntOA-0005au-BL for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 15:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: taylanbayirli@gmail.com (Taylan Ulrich =?UTF-8?Q?Bay=C4=B1rl=C4=B1/Kammer?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Oct 2015 19:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21702 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21702-submit@debbugs.gnu.org id=B21702.144519556121477 (code B ref 21702); Sun, 18 Oct 2015 19:13:02 +0000 Original-Received: (at 21702) by debbugs.gnu.org; 18 Oct 2015 19:12:41 +0000 Original-Received: from localhost ([127.0.0.1]:55364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZntNo-0005aK-Di for submit@debbugs.gnu.org; Sun, 18 Oct 2015 15:12:40 -0400 Original-Received: from mail-wi0-f169.google.com ([209.85.212.169]:36270) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZntNk-0005aB-Ua for 21702@debbugs.gnu.org; Sun, 18 Oct 2015 15:12:37 -0400 Original-Received: by wicfx6 with SMTP id fx6so23220924wic.1 for <21702@debbugs.gnu.org>; Sun, 18 Oct 2015 12:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=3mpjrz6f0vUOLpBmQJLUMUbQz3Z+Ad0bV9E/rxyKVM4=; b=LLp0R69lrJqiWCt6ATStSHwxxoOwR6bi9yK4lO7JoPzymPlRnBEbX45lpFPaPpUoae QQSfrTqGzQGSOqgiCRV557wT3/hFIbzuAaHqfU3vo4FwqVlDlYGgq8bvyH2TqEFi9J1n KpZlp5E1tCt4YFPx0YzJTI+pc00Yvp6/gYilUr5iLQ/Qs+8KLkDJ6DwSasRh2YeqVjla rIBsn639VuRJC+rt+2HPLHtiQKulILCq6F7WUHh3V4XKrxxqjwvY90uSQyK82bpZA4r1 RBc4xw5YYzwUDE4mYOeyIvMmc5yu6laoqCKYKEV0gFT8rrwIxVWwgaWa5sDp3XuGUY8p qfCQ== X-Received: by 10.180.102.135 with SMTP id fo7mr4585949wib.0.1445195556214; Sun, 18 Oct 2015 12:12:36 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id uq5sm35557308wjc.3.2015.10.18.12.12.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 12:12:35 -0700 (PDT) In-Reply-To: <83pp0chzax.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 18 Oct 2015 20:16:54 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107716 Archived-At: Eli Zaretskii writes: >> From: taylanbayirli@gmail.com (Taylan Ulrich >> Bay=C4=B1rl=C4=B1/Kammer) >> Date: Sun, 18 Oct 2015 14:36:03 +0200 >>=20 >> The documentation of shell-quote-argument only says >>=20 >> Quote ARGUMENT for passing as argument to an inferior shell. >>=20 >> It's unclear for which shells this is supposed to work. > > I fixed the doc string to clarify that this function works correctly > with the system's standard shell. > >> In a recent thread in emacs-devel, it has been demonstrated that if >> the result is passed to csh, it can allow an attacker to execute an >> arbitrary shell command > > As I understand it, csh is not the standard shell on Posix systems, so > the fixed doc string now says not to expect it to work with csh. > >> The function should clearly document >>=20 >> 1) for which shells will the quoting work absolutely, i.e. lead to >> the given string to appear *verbatim* in an element of the ARGV of >> the called command, >>=20 >> 2) optionally, for which shells will the quoting at least prevent >> code injection, >>=20 >> 3) optionally, for which shells and character sets for ARGUMENT will >> the quoting work absolutely, >>=20 >> 4) optionally, for which shells and character sets for ARGUMENT will >> the quoting at least prevent code injection, >>=20 >> 5) optionally, for which shells will the quoting work at all even if >> it provides no clear semantics, such that one can at least use it >> with data coming from trusted sources (e.g. other parts of Emacs's >> source code, or the user sitting in front of Emacs), where it's the >> user's/programmer's responsibility to stick to values for ARGUMENT >> that are intuitively known to be unproblematic even if the character >> set isn't well-defined. >>=20 >> Currently #5 seems to be implied for all shells, for lack of further >> documentation. Possibly, the function was never meant to be used with >> untrusted data, but there's no warning against doing so either. > > I thin 1) is now covered, and the rest are optional. In particular, > our way to provide better safety is not by documenting APIs that could > be maliciously abused, but by marking the related variables as unsafe > unless they have special predefined values. So I don't think we > should extend this particular doc string with safety information. Hm, there seems to be a fundamental difference in mindset here in how one might use Elisp. I'd like to point out that (in the most extreme cases) people have actually been writing web servers and other such programs in Elisp for which one would normally use a general-purpose language. That is, "APIs that could be maliciously abused" is not the right way to look at it. It's not about the Elisp programmer abusing the API, it's about a malicious data source exploiting a (potential) flaw in an Elisp function, which Elisp programmers have relied on and thus made their programs vulnerable to code injection. That's why I was being so careful with regard to the safety guarantees of the "shell-quasiquote" package I contributed. I would like people to be able to use that as part of a general-purpose Elisp language, and so being safe against code injection is an absolute must. They might after all use it as part of a network-facing service. Actually that might also apply when using e.g. TRAMP, which also communicates with remote hosts and is a normal part of Emacs. I've been told it receives file names from remote hosts and passes them through shell-quote-argument before giving them to a shell. So maybe my concerns apply there as well. Given that, "I think 1) is now covered" is not very relieving to hear. It amounts to "I think this is safe against code injection" which is rather alarming to hear. Either it's very confidently known to be safe and so one may use it for network-facing code, or it's not confidently known to be safe and so one shouldn't use it for network-facing code. This should be documented clearly especially so that users who aren't very aware of injection attacks won't nonchalantly use the function for their network-facing code (when the function isn't known to be safe for this), but also so that users who are aware of such issues know they can use the function and don't instead invent their own thing (when it is known to be safe). Does that make sense? Taylan