From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.bugs Subject: bug#8427: [SECURITY] sql.el -- comint process passwords are leaked to ps(1) listing Date: Sun, 15 Dec 2019 23:59:28 -0500 Message-ID: References: <-DPnoQRPO3mztTMZP0CLEkVHEueQfRbf1NL2NMBa_alnqjzctP5kLNyD-Gd_yioQqTu-QiEXfLGzidBeSrX0jY_-tlyrBEnMU5Mo5febRng=@protonmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002eba8a0599cb14a2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="201546"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "8427@debbugs.gnu.org" <8427@debbugs.gnu.org>, Stefan Kangas To: Michael Mauger Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 16 06:00:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1igiUU-000qEy-IA for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Dec 2019 06:00:18 +0100 Original-Received: from localhost ([::1]:46276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igiUN-00074Z-Mv for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Dec 2019 00:00:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56859) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igiUH-00074P-4I for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 00:00:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1igiUF-0000ww-4r for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 00:00:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59888) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1igiUE-0000wo-V1 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 00:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1igiUE-000529-T3 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 00:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Hyatt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Dec 2019 05:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8427 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 8427-submit@debbugs.gnu.org id=B8427.157647238819249 (code B ref 8427); Mon, 16 Dec 2019 05:00:02 +0000 Original-Received: (at 8427) by debbugs.gnu.org; 16 Dec 2019 04:59:48 +0000 Original-Received: from localhost ([127.0.0.1]:37628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1igiTz-00050O-Nk for submit@debbugs.gnu.org; Sun, 15 Dec 2019 23:59:48 -0500 Original-Received: from mail-qt1-f169.google.com ([209.85.160.169]:41707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1igiTx-000505-7q for 8427@debbugs.gnu.org; Sun, 15 Dec 2019 23:59:46 -0500 Original-Received: by mail-qt1-f169.google.com with SMTP id k40so1042865qtk.8 for <8427@debbugs.gnu.org>; Sun, 15 Dec 2019 20:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fAH/Y5vNjr7mHFJWi8NMogSD8vghHju9NZjE9BsMfTw=; b=IBGJzgjKdJTe9j+T2kLiSbsLy75inT/bO3xqBfPPW1HGct2pYhKksPHC9TtT18G+8Y QPY+xd2SXkCLo95cdawFD5AcUIuww3vBszUN9SoiWiHOVsHK9TiSRIkC4IKjwuTkeR4X 17uiF7DaT1qXWOeUoc/BLJo4U6QR/TFrT5TutZjkUuONJR7pueP4ljcXrwuvg1uilZwS F3f/vmkTpNQACv9Lk0y+5j/orzgTe1gWsTYJhQIG6w/LKDey2PgEXjPHPsVewrzNlbMJ PbWyuaUyjul5caFCGsBtTMR57yPNbn/7ZQRS97l8aBBsQjROTSZ8JwPmEIXc95hjOBCu fo0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fAH/Y5vNjr7mHFJWi8NMogSD8vghHju9NZjE9BsMfTw=; b=YB3un51z3mOUWSYEIaRzwjSJaWk4RKvYnLcCHKmcSpIGNTKXnI1D69IwoI7xaBDdpk xMQ9nF4IfPCW1o+gjiy0/V41yfG28OA2OorY/LV5OXcYPcCRTFl3ce+FPeqhL05TpNnk VOqfYDhEFYCmGFpkIVsssYFiQ/b2/yYMZMLxGXXogaz/2LZE0HUmTAB3Wh9f89WBETt8 QysXxDMhKqCopHDKLfhpif/UqSvmN1lM5yga6uyF89gw0eUVK7D/xL1ejv9RTrJHzepe v4cMbqVKu5wWMUlHLuZZzUTppEvKgWp9d3WMukOv6W/21Fa8/SmGP8ztCVqhlTZzEO7n GExg== X-Gm-Message-State: APjAAAXhJh3VaZkGsg7ddBvFw2HkUdVxXAEBKwUYwH62oUiNUPx0wfuF EPtG0P2T4GrdFrABtRYPUEbjXwp0Lvp3gDFd5Q0= X-Google-Smtp-Source: APXvYqzk01ZtuV8xxz5zpz0oOWIn+FjiJbP4IQ+d598y/dBUR9kD2vQ6bl/6IWiMBqGbmNfEThM6igM09iWgXAwSCJg= X-Received: by 2002:ac8:1415:: with SMTP id k21mr22303442qtj.80.1576472379568; Sun, 15 Dec 2019 20:59:39 -0800 (PST) In-Reply-To: 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: 209.51.188.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:173415 Archived-At: --0000000000002eba8a0599cb14a2 Content-Type: text/plain; charset="UTF-8" Any input on this? I believe this fixes the issue, and would prefer to revise this while I still remember the details. I'm happy to submit this as well. On Mon, Nov 11, 2019 at 12:31 AM Andrew Hyatt wrote: > > I've simplified an implementation along the lines you suggest, and > tested it via ert. I'm attaching the latest version of the patch. > Please let me know what you think. > > > > Michael Mauger writes: > > > On Saturday, November 2, 2019 1:10 AM, Andrew Hyatt > wrote: > > > >> Michael Mauger mmauger@protonmail.com writes: > >> > >> > On Sunday, October 20, 2019 8:56 PM, Andrew Hyatt ahyatt@gmail.com > wrote: > >> > > >> > >> Your advice is good, but following it led me to some complexity I can't > >> seem to get away from. Perhaps you have some insight, so let me explain. > >> The issue is that, yes, I can not advise the comint function. However, > >> if I supply my own function, then I have to remove the > >> comint-watch-for-password-prompt, supply my own function, then restore > >> it when the user has entered their password (so it can handle subsequent > >> password entries). This juggling of the normal > >> comint-watch-for-password-prompt method, plus the fact that we basically > >> have to reimplement part of it, gives me pause - I think it's probably > >> too hacky a solution. > >> > >> There's a few ways out. We could introduce a variable used in > >> sql-product-alist that tells SQL not to prompt for a password because > >> the db will just get it via the comint password function. That would > >> probably work well, but it wouldn't store the sql-password at all, that > >> variable would be unused. Maybe that's OK, maybe not - I don't have a > >> good sense for it. > >> > >> Or, we could make this auto-password-supplying per-buffer a part of > >> comint itself. That would widen the scope of the fix, but it would > >> probably be the best of both functionality and simplicity. > >> > >> What do you think? > >> > > > > I totally understand the complexity, but I don't think it has too be too > > complicated to address. > > > > First the sql.el only solution: If the sql-comint function decides to > pass > > the password via stdin then it can set a buffer-local flag indicating > this > > and then replace `coming-watch-for-password-prompt' on the > > `comint-output-filter-functions' list with the sql version of the > function. > > The sql password function would be something along the lines of: > > > > ;; TOTALLY NOT TESTED > > (defun sql-watch-for-password-prompt (string) > > "blah blah ;)" > > (if sql-will-prompt-for-password > > ;; (based on comint-watch-for-password-prompt) vvv > > (when (let ((case-fold-search t)) > > (string-match (or (sql-get-product-feature sql-product > 'password-prompt-regexp string) > > comint-password-prompt-regexp))) > > (when (string-match "^[ \n\r\t\v\f\b\a]+" string) > > (setq string (replace-match "" t t string))) > > (let ((comint--prompt-recursion-depth (1+ > comint--prompt-recursion-depth))) > > (if (> comint--prompt-recursion-depth 10) > > (message "Password prompt recursion too deep") > > ;;; ^^^ > > ;;; automagically provide the password > > (let ((proc (get-buffer-process (current-buffer)))) > > (when proc > > (funcall comint-input-sender proc sql-password)))))) > > ;; Back to default behavior > > (comint-watch-for-password-prompt string)) > > ;; Make sure we don't supply again > > (setq-local sql-will-prompt-password nil)) > > > > That should get you close without too much difficulty. Of course, it > requires a > > that a password-prompt-regexp feature is defined for the sql product and > that the > > sql-comint function defines a buffer-local flag > `sql-will-prompt-for-password' in > > it is deferring to stdin. > > > > The other solution would involve modifying comint to call a hook if set > to supply > > a password or nil. This would probably be a simpler change but may get > more > > broader attention. When the hook function is not set or returns nil then > do the > > default behavior of calling `comint-send-invisible' otherwise just send > the password > > > > There are some edge cases here, but this hopefully helps. Also, > obviously, test cases > > are needed given that if this breaks, we break the sql interactive world! > > > > -- > > MICHAEL@MAUGER.COM // FSF and EFF member // GNU Emacs sql.el maintainer > --0000000000002eba8a0599cb14a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Any input on this?=C2=A0 I believe this fixes the issue, a= nd would prefer to revise this while I still remember the details.=C2=A0 I&= #39;m happy to submit this as well.

On Mon, Nov 11, 2019 at 12:31 AM Andrew = Hyatt <ahyatt@gmail.com> wrot= e:

I've simplified an implementation along the lines you suggest, and
tested it via ert. I'm attaching the latest version of the patch.
Please let me know what you think.



Michael Mauger <mmauger@protonmail.com> writes:

> On Saturday, November 2, 2019 1:10 AM, Andrew Hyatt <ahyatt@gmail.com> wrote:
>
>> Michael Mauger mmauger@protonmail.com writes:
>>
>> > On Sunday, October 20, 2019 8:56 PM, Andrew Hyatt ahyatt@gmail.com wrote:
>> >
>>
>> Your advice is good, but following it led me to some complexity I = can't
>> seem to get away from. Perhaps you have some insight, so let me ex= plain.
>> The issue is that, yes, I can not advise the comint function. Howe= ver,
>> if I supply my own function, then I have to remove the
>> comint-watch-for-password-prompt, supply my own function, then res= tore
>> it when the user has entered their password (so it can handle subs= equent
>> password entries). This juggling of the normal
>> comint-watch-for-password-prompt method, plus the fact that we bas= ically
>> have to reimplement part of it, gives me pause - I think it's = probably
>> too hacky a solution.
>>
>> There's a few ways out. We could introduce a variable used in<= br> >> sql-product-alist that tells SQL not to prompt for a password beca= use
>> the db will just get it via the comint password function. That wou= ld
>> probably work well, but it wouldn't store the sql-password at = all, that
>> variable would be unused. Maybe that's OK, maybe not - I don&#= 39;t have a
>> good sense for it.
>>
>> Or, we could make this auto-password-supplying per-buffer a part o= f
>> comint itself. That would widen the scope of the fix, but it would=
>> probably be the best of both functionality and simplicity.
>>
>> What do you think?
>>
>
> I totally understand the complexity, but I don't think it has too = be too
> complicated to address.
>
> First the sql.el only solution: If the sql-comint function decides to = pass
> the password via stdin then it can set a buffer-local flag indicating = this
> and then replace `coming-watch-for-password-prompt' on the
> `comint-output-filter-functions' list with the sql version of the = function.
> The sql password function would be something along the lines of:
>
>=C2=A0 =C2=A0 =C2=A0;; TOTALLY NOT TESTED
>=C2=A0 =C2=A0 =C2=A0(defun sql-watch-for-password-prompt (string)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"blah blah ;)"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(if sql-will-prompt-for-password
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; (based on comint-watch-for-= password-prompt)=C2=A0 vvv
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (let ((case-fold-search = t))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(s= tring-match (or (sql-get-product-feature sql-product 'password-prompt-r= egexp string)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comint-passwo= rd-prompt-regexp)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (string-match &qu= ot;^[ \n\r\t\v\f\b\a]+" string)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq string (re= place-match "" t t string)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((comint--prompt-r= ecursion-depth (1+ comint--prompt-recursion-depth)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (> comint= --prompt-recursion-depth 10)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(m= essage "Password prompt recursion too deep")
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; ^^^ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;; autom= agically provide the password
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((pr= oc (get-buffer-process (current-buffer))))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(w= hen proc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0(funcall comint-input-sender proc sql-password))))))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Back to default behavior
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(comint-watch-for-password-prompt str= ing))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0;; Make sure we don't supply again
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(setq-local sql-will-prompt-password nil)) >
> That should get you close without too much difficulty. Of course, it r= equires a
> that a password-prompt-regexp feature is defined for the sql product a= nd that the
> sql-comint function defines a buffer-local flag `sql-will-prompt-for-p= assword' in
> it is deferring to stdin.
>
> The other solution would involve modifying comint to call a hook if se= t to supply
> a password or nil. This would probably be a simpler change but may get= more
> broader attention. When the hook function is not set or returns nil th= en do the
> default behavior of calling `comint-send-invisible' otherwise just= send the password
>
> There are some edge cases here, but this hopefully helps. Also, obviou= sly, test cases
> are needed given that if this breaks, we break the sql interactive wor= ld!
>
> --
> MICHAEL@MAUGER= .COM // FSF and EFF member // GNU Emacs sql.el maintainer
--0000000000002eba8a0599cb14a2--