From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66390: `man' allows to inject arbitrary shell code Date: Sun, 08 Oct 2023 08:28:00 +0300 Message-ID: <831qe5znrz.fsf@gnu.org> References: <83wmvyzir2.fsf@gnu.org> <585dcaf0-358e-4a9d-84d1-6fd9c2c8aec5@gmail.com> <83v8bizf9r.fsf@gnu.org> <1865abb8-16cd-4570-9a8a-87cf9430583d@gmail.com> <875y3iigua.fsf@gmx.de> <83o7hazap7.fsf@gnu.org> <87mswugyoq.fsf@gmx.de> <83jzryz6op.fsf@gnu.org> <87a5sugwcx.fsf@gmx.de> <83h6n2z3tr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17979"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66390@debbugs.gnu.org, michael.albinus@gmx.de To: Max Nikulin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 08 07:29:02 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qpMLe-0004P0-9q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 08 Oct 2023 07:29:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qpMLN-0003gx-14; Sun, 08 Oct 2023 01:28:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qpMLL-0003gW-F2 for bug-gnu-emacs@gnu.org; Sun, 08 Oct 2023 01:28:43 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qpMLL-0006mh-7C for bug-gnu-emacs@gnu.org; Sun, 08 Oct 2023 01:28:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qpMLe-0005D0-IT for bug-gnu-emacs@gnu.org; Sun, 08 Oct 2023 01:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Oct 2023 05:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66390 X-GNU-PR-Package: emacs Original-Received: via spool by 66390-submit@debbugs.gnu.org id=B66390.169674291919987 (code B ref 66390); Sun, 08 Oct 2023 05:29:02 +0000 Original-Received: (at 66390) by debbugs.gnu.org; 8 Oct 2023 05:28:39 +0000 Original-Received: from localhost ([127.0.0.1]:56159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qpMLG-0005CJ-Uo for submit@debbugs.gnu.org; Sun, 08 Oct 2023 01:28:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qpMLF-0005C3-M9 for 66390@debbugs.gnu.org; Sun, 08 Oct 2023 01:28:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qpMKq-0006c3-90; Sun, 08 Oct 2023 01:28:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FbsC3Lvb4QvyOXnYGMG78UTZ0S0zdMth7soLVjPBWuE=; b=NqcPuaKnO4EU 0vQjyHkAVLK4ZtxLZ3BqiD5vqYAupkKT4wCrsXmIsJPaBkzNVLOD8ZMLvgEQd/CM8TVDeGa+qnIB0 iBr+WFIG5gIBxmbu9aFbjY3qeJMbaRxFhkrufgj7tcDdkTgjc/EFbfVl4pFmjXpvQYh3Mz6aNtpqj vP+6K9rGuMNb+DXThaXu1HROBystlJlpSkOUxEELZGJKWfiRZsu5xeUzqujZ2/yFRdobluj6m20Rw il/r0goucse8Rh+EEkL3ZxdB0ZXCi0OCxE8TyH3+G7QaXPszIYIoRRu3XiRMQr6Ba2v4PxWtuan8m bgQL0mND5NF7x4d5G8Wpxg==; In-Reply-To: (message from Max Nikulin on Sun, 8 Oct 2023 10:37:33 +0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272060 Archived-At: > Date: Sun, 8 Oct 2023 10:37:33 +0700 > Cc: 66390@debbugs.gnu.org > From: Max Nikulin > > On 08/10/2023 01:26, Eli Zaretskii wrote: > > > > So the problem _is_ with the shell? If so, the best way of avoiding > > these problems is not invoke 'man' via the shell, but via call-process > > and its ilk instead. > > It will be great if it is possible to avoid shell in the middle. However > - man.el uses pipes with sed and awk to post-process output of man > executable. > - if support of remote man files is considered then it is even more hard > to avoid shell. SSH assumes shell commands. Even if sometimes the shell cannot be avoided (which has yet to be established, AFAIU), it's not an argument against avoiding it where possible, because that solves any security issues, definitely those you brought up. > I had in mind using at least `shell-quote-argument'. That doesn't work with 'man', which has its own ideas about quoting, besides shell-related quoting. > The issues of sanitizing outputs in callers > - If there was a safe function in man.el then callers code would be more > simple, so it would be less probable to introduce bugs in such code. > - behavior of the `man' emacs command is *underspecified*, so it is hard > to provide safe argument for it. Some parenthesis are allowed as in > "man(1)" others may be interpreted by shell. > - `shell-quote-argument' in callers would rely on man.el implementation > details at best or may even lead to undefined behavior since I see have > no way to bypass some processing of the argument of the `man' emacs command. Reiterating what you already said doesn't help to have a productive discussion. > Execution a part of `man' emacs command argument by shell is a surprise > to the user any case. Ideally elisp code should prevent it and man.el > should emit an error. IMO, this ideal cannot be reached in practice, let alone kept for any length of time. Systems are adding strangely-named man pages all the time. We had quite a few bug reports about that during the recent years. > Attempts to call of `man' from other packages is an open door for > security vulnerabilities. Then perhaps those other packages shouldn't call 'man'.