Skip Menu |
 

This queue is for tickets about the UI-Dialog CPAN distribution.

Report information
The Basics
Id: 107364
Status: resolved
Priority: 0/
Queue: UI-Dialog

People
Owner: kevin [...] krinke.ca
Requestors: matthijs [...] stdin.nl
Cc: CARNIL [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.13



MIME-Version: 1.0
X-Spam-Status: No, score=-1.9 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9] autolearn=ham
Content-Disposition: inline
X-Preliminary-Spam-Score: -1.4 (-)
X-Spam-Flag: NO
X-PGP-Fingerprint: E7D0 C6A7 5BEE 6D84 D638 F60A 3798 AF15 A156 5658
Content-Type: multipart/signed; boundary="TO+C2CEso28YlQFN"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Message-ID: <20150927103509.GX27418 [...] login.tika.stderr.nl>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Spam-Score: -1.9
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 0E0C5240467 for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Sun, 27 Sep 2015 06:35:26 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y7kL9pTSvko for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Sun, 27 Sep 2015 06:35:24 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id B24D9240107 for <bug-UI-Dialog [...] rt.cpan.org>; Sun, 27 Sep 2015 06:35:23 -0400 (EDT)
Received: (qmail 15194 invoked by alias); 27 Sep 2015 10:35:22 -0000
Received: from tika.stderr.nl (HELO tika.stderr.nl) (94.142.244.14) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sun, 27 Sep 2015 03:35:16 -0700
Received: from [10.42.0.16] (helo=login.tika.stderr.nl ident=mail) by mail.local with smtp (Exim 4.80) (envelope-from <matthijs [...] stdin.nl>) id 1Zg9IU-0005EJ-4u for bug-UI-Dialog [...] rt.cpan.org; Sun, 27 Sep 2015 12:35:12 +0200
Received: (nullmailer pid 32212 invoked by uid 2001); Sun, 27 Sep 2015 10:35:09 -0000
Delivered-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
Return-Path: <matthijs [...] stdin.nl>
X-RT-Mail-Extension: ui-dialog
X-Original-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
X-Spam-Check-BY: la.mx.develooper.com
X-PGP-Key: http://www.stderr.nl/static/files/gpg_pubkey.asc
Date: Sun, 27 Sep 2015 12:35:09 +0200
X-PGP-Note: Previous key 8A2FAFBC replaced on 2014-09-07
X-Spam-Level:
To: bug-UI-Dialog [...] rt.cpan.org
From: Matthijs Kooijman <matthijs [...] stdin.nl>
X-RT-Interface: Email
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 2733
Download (untitled) / with headers
text/plain 2.6k
Hi, it seems that the whiptail, cdialog and kdialog backends apply some improper escaping in their shell commands, causing special characters present in menu item titles to be interpreted by the shell. This includes the backtick evaluation operator, so this constitutues a security issue, allowing execution of arbitrary commands if an attacker has control over the text displayed in a menu. Here's a minimal script showing the problem: #!/usr/bin/perl use UI::Dialog; my $d = new UI::Dialog ( order => ["whiptail"], height => 20, listheight => 5, debug => 1); my @items = (1, "Running Debian `cat /etc/debian_version `"); my $selected = $d->menu( text => "Correctly escaped `here`", list => \@items); Which produces: Debug: /usr/bin/whiptail --menu "Correctly escaped \`here\`" "20" "65" "5" "1" "Running Debian \\`cat /etc/debian_version \\`" ┌───────────────────────────────────────────────────────────────┐ │ Correctly escaped `here` │ │ │ │ 1 Running Debian \8.0 │ As you can see, the ` are escaped using \, but then the \ is additionally escaped itself, voiding its use. Adding some debugging output in the menu() function in Backend/Whiptail.pm showed that this line escapes the `: my $args = $self->_pre($caller,@_); And this line then additionally escapes the \, breaking things: my $command = $self->_mk_cmnd(" --menu",@_); This problem only occurs for the "list" option, not for the "text" option. I suspect that plain strings work and strings in arrays break, perhaps because _pre references arrays instead of copying them? I haven't actually confirmed this, though. What's interesting is that the zenity backend also uses shell commands, but does not have this problem. Looking at its list() function (which is called by menu()), it is similar to Whiptail's menu() but has: my $command = $self->_mk_cmnd(" --list",$args); so it passes $args instead of @_. Applying the same change to Whiptail also makes Whiptail work correctly, but my Perl-fu is not strong enough to know why, or if this would be a solution. I suspect that some other functions (checklist(), radiolist(), perhaps others) will suffer from the same problem, but I have not tested this. I would think this problem would need a CVE assigned and perhaps be coordinated with the Linux distribution security teams. Let me know if you want to do this, else I'll contact the Debian security team and ask them to handle this. Gr. Matthijs
Content-Description: Digital signature
Content-Type: application/pgp-signature; name="signature.asc"
Content-Length: 819
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

MIME-Version: 1.0
In-Reply-To: <20150927103509.GX27418 [...] login.tika.stderr.nl>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <20150927103509.GX27418 [...] login.tika.stderr.nl>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-19911-1443370525-1414.107364-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1538
Download (untitled) / with headers
text/plain 1.5k
Hello! Show quoted text
> it seems that the whiptail, cdialog and kdialog backends apply some > improper escaping in their shell commands, causing special characters > present in menu item titles to be interpreted by the shell. This > includes the backtick evaluation operator, so this constitutues a > security issue, allowing execution of arbitrary commands if an > attacker > has control over the text displayed in a menu.
I've been meaning to re-write the command construction routines to use proper shell escaping consistently throughout the backends. Haven't managed to find the time as of yet. Show quoted text
> I would think this problem would need a CVE assigned and perhaps be > coordinated with the Linux distribution security teams. Let me know if > you want to do this, else I'll contact the Debian security team and > ask > them to handle this.
I'm uncertain that this requires a CVE to be assigned because in order for this to be exploitable, the attacker has to have write access to the script in which case I'd say they've already compromised the box via other means... unless of course you're using UI::Dialog in some auth context? which would be strange and obviously not recommended at all. However, if you could bring this up with the various security teams and get their take on how to proceed; I think that is the best course of action. In the meantime, I'll find time to put some honest efforts into the re-write and follow up on this issue as I make headway over the course of the next week. My best, -- Kevin C. Krinke <kevin@krinke.ca>
MIME-Version: 1.0
X-Spam-Status: No, score=-3.9 tagged_above=-99.9 required=10 tests=[AWL=2.000, BAYES_00=-1.9, FROM_OUR_RT=-4] autolearn=ham
In-Reply-To: <rt-4.0.18-19911-1443370526-317.107364-6-0 [...] rt.cpan.org>
Content-Disposition: inline
X-Preliminary-Spam-Score: -2.9 (--)
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-107364 [...] rt.cpan.org> <20150927103509.GX27418 [...] login.tika.stderr.nl> <rt-4.0.18-19911-1443370526-317.107364-6-0 [...] rt.cpan.org>
X-PGP-Fingerprint: E7D0 C6A7 5BEE 6D84 D638 F60A 3798 AF15 A156 5658
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <20150927162822.GB27418 [...] login.tika.stderr.nl>
Content-Type: multipart/signed; boundary="riy+DgoZUD0gsBzk"; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Spam-Score: -3.9
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 392B52403B5 for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Sun, 27 Sep 2015 12:28:45 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byOHEsG04VJb for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Sun, 27 Sep 2015 12:28:43 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 2FC81240389 for <bug-UI-Dialog [...] rt.cpan.org>; Sun, 27 Sep 2015 12:28:43 -0400 (EDT)
Received: (qmail 28639 invoked by alias); 27 Sep 2015 16:28:42 -0000
Received: from tika.stderr.nl (HELO tika.stderr.nl) (94.142.244.14) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sun, 27 Sep 2015 09:28:30 -0700
Received: from [10.42.0.16] (helo=login.tika.stderr.nl ident=mail) by mail.local with smtp (Exim 4.80) (envelope-from <matthijs [...] stdin.nl>) id 1ZgEoJ-0005zQ-P9 for bug-UI-Dialog [...] rt.cpan.org; Sun, 27 Sep 2015 18:28:25 +0200
Received: (nullmailer pid 5584 invoked by uid 2001); Sun, 27 Sep 2015 16:28:23 -0000
Delivered-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #107364] Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
User-Agent: Mutt/1.5.23 (2014-03-12)
Return-Path: <matthijs [...] stdin.nl>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
X-RT-Mail-Extension: ui-dialog
X-PGP-Key: http://www.stderr.nl/static/files/gpg_pubkey.asc
Date: Sun, 27 Sep 2015 18:28:23 +0200
X-Spam-Level:
X-PGP-Note: Previous key 8A2FAFBC replaced on 2014-09-07
To: "Kevin C. Krinke via RT" <bug-UI-Dialog [...] rt.cpan.org>
From: Matthijs Kooijman <matthijs [...] stdin.nl>
RT-Message-ID: <rt-4.0.18-11052-1443371325-1133.107364-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Disposition: inline
X-RT-Original-Encoding: utf-8
Content-Length: 1148
Download (untitled) / with headers
text/plain 1.1k
Hey Kevin, Show quoted text
> I'm uncertain that this requires a CVE to be assigned because in order > for this to be exploitable, the attacker has to have write access to > the script in which case I'd say they've already compromised the box > via other means... unless of course you're using UI::Dialog in some > auth context? which would be strange and obviously not recommended at > all.
I have a script that parses URLs from an e-mail and uses UI::dialog to prompt me to select one. This means that sending me a specially crafted e-mail could cause execution of arbitrary commands on my system. More generally it doesn't seem unreasonable to use UI::dialog to handle untrusted user input, so I suspect there might be other scripts affected in this way as well. Show quoted text
> However, if you could bring this up with the various security teams and > get their take on how to proceed; I think that is the best course of > action.
I'll contact the Debian team, see what they think. Show quoted text
> In the meantime, I'll find time to put some honest efforts into the > re-write and follow up on this issue as I make headway over the course > of the next week.
Awesome, thanks! Matthijs
Content-Description: Digital signature
Content-Type: application/pgp-signature; name="signature.asc"
Content-Length: 819
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-11052-1443371325-1133.107364-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-107364 [...] rt.cpan.org> <20150927103509.GX27418 [...] login.tika.stderr.nl> <rt-4.0.18-19911-1443370526-317.107364-6-0 [...] rt.cpan.org> <20150927162822.GB27418 [...] login.tika.stderr.nl> <rt-4.0.18-11052-1443371325-1133.107364-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-31486-1444380853-135.107364-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 349
Download (untitled) / with headers
text/plain 349b
Hola Matthijs, I've made some progress and pushed the changes to a development branch on the github project for UI::Dialog[1]. If you could test this out to your satisfaction I'd appreciate the second set of eyes before I push a CPAN release. Thanks! [1] https://github.com/kckrinke/UI-Dialog/tree/development -- Kevin C. Krinke kevin@krinke.ca
MIME-Version: 1.0
Subject: CVE-2008-7315 assigned
In-Reply-To: <20150927103509.GX27418 [...] login.tika.stderr.nl>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <20150927103509.GX27418 [...] login.tika.stderr.nl>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-23299-1444421513-903.107364-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 217
Download (untitled) / with headers
text/plain 217b
CVE-2008-7315 has been assigned for this issue, see http://www.openwall.com/lists/oss-security/2015/10/08/6 Could you please reference it in the changes as well once there is a new fixing version? Regards, Salvatore
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-23299-1444421513-903.107364-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <20150927103509.GX27418 [...] login.tika.stderr.nl> <rt-4.0.18-23299-1444421513-903.107364-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-31900-1444421582-1715.107364-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 329
Download (untitled) / with headers
text/plain 329b
On Fri Oct 09 16:11:53 2015, CARNIL wrote: Show quoted text
> CVE-2008-7315 has been assigned for this issue, see > http://www.openwall.com/lists/oss-security/2015/10/08/6 > > Could you please reference it in the changes as well once there is a > new fixing version?
Nevermind, I see it was already. Thanks a lot for that. Regards, Salvatore
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-31486-1444380853-135.107364-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-107364 [...] rt.cpan.org> <20150927103509.GX27418 [...] login.tika.stderr.nl> <rt-4.0.18-19911-1443370526-317.107364-6-0 [...] rt.cpan.org> <20150927162822.GB27418 [...] login.tika.stderr.nl> <rt-4.0.18-11052-1443371325-1133.107364-0-0 [...] rt.cpan.org> <rt-4.0.18-31486-1444380853-135.107364-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-16750-1444674480-1782.107364-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 508
Download (untitled) / with headers
text/plain 508b
On Fri Oct 09 04:54:13 2015, KCK wrote: Show quoted text
Not satisfied with my first hacktastic attempt at fixing the problem; I've gone and re-written the entire internal command preparation semantics and arrived at what I believe is a truly consistent model for managing trusted and untrusted input. Regression testing is a manual process at this time and any/all help with this development branch would be appreciated. -- Kevin C. Krinke kevin@krinke.ca
CC: CARNIL [...] cpan.org
MIME-Version: 1.0
X-Spam-Status: No, score=-4.9 tagged_above=-99.9 required=10 tests=[AWL=1.000, BAYES_00=-1.9, FROM_OUR_RT=-4] autolearn=ham
In-Reply-To: <rt-4.0.18-16750-1444674480-19.107364-6-0 [...] rt.cpan.org>
Content-Disposition: inline
X-Preliminary-Spam-Score: -2.9 (--)
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-107364 [...] rt.cpan.org> <20150927103509.GX27418 [...] login.tika.stderr.nl> <rt-4.0.18-19911-1443370526-317.107364-6-0 [...] rt.cpan.org> <20150927162822.GB27418 [...] login.tika.stderr.nl> <rt-4.0.18-11052-1443371325-1133.107364-6-0 [...] rt.cpan.org> <rt-4.0.18-31486-1444380853-135.107364-6-0 [...] rt.cpan.org> <rt-4.0.18-16750-1444674480-19.107364-6-0 [...] rt.cpan.org>
X-PGP-Fingerprint: E7D0 C6A7 5BEE 6D84 D638 F60A 3798 AF15 A156 5658
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <20151013094531.GL8704 [...] login.tika.stderr.nl>
Content-Type: multipart/signed; boundary="UN1ZhWvvntdx6hvb"; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Spam-Score: -4.9
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 69B612400F1 for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Tue, 13 Oct 2015 05:45:47 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYloZShbQiIQ for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Tue, 13 Oct 2015 05:45:45 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 60F732400DC for <bug-UI-Dialog [...] rt.cpan.org>; Tue, 13 Oct 2015 05:45:44 -0400 (EDT)
Received: (qmail 4764 invoked by alias); 13 Oct 2015 09:45:44 -0000
Received: from tika.stderr.nl (HELO tika.stderr.nl) (94.142.244.14) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 13 Oct 2015 02:45:39 -0700
Received: from [10.42.0.16] (helo=login.tika.stderr.nl ident=mail) by mail.local with smtp (Exim 4.80) (envelope-from <matthijs [...] stdin.nl>) id 1Zlw9E-0006R2-IT; Tue, 13 Oct 2015 11:45:34 +0200
Received: (nullmailer pid 5890 invoked by uid 2001); Tue, 13 Oct 2015 09:45:32 -0000
Delivered-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #107364] Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
User-Agent: Mutt/1.5.23 (2014-03-12)
Return-Path: <matthijs [...] stdin.nl>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
X-RT-Mail-Extension: ui-dialog
X-PGP-Key: http://www.stderr.nl/static/files/gpg_pubkey.asc
Date: Tue, 13 Oct 2015 11:45:31 +0200
X-Spam-Level:
X-PGP-Note: Previous key 8A2FAFBC replaced on 2014-09-07
To: "Kevin C. Krinke via RT" <bug-UI-Dialog [...] rt.cpan.org>
From: Matthijs Kooijman <matthijs [...] stdin.nl>
RT-Message-ID: <rt-4.0.18-17578-1444729548-1928.107364-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Disposition: inline
X-RT-Original-Encoding: utf-8
Content-Length: 1193
Download (untitled) / with headers
text/plain 1.1k
Hi Kevin, I just gave the test branch a whirl, and it seems it indeed fixes the security issue. There's still two things I'm wondering: - If I include $(pwd) in a menu item, it seems that the $ is *removed* from the displayed string. When I use `, it seems a normal quote ' is displayed instead. I guess that completely removing these potentially dangerous characters is safest, but this also limits the expressiveness of scripts. Was escaping these characters instead of removing them not possible? - Looking through the commits, it seems you added support to mark input as "trusted", which I presume it will not be subjected to sanitizing / escaping. However, what's the actual usecase for this? If some script wants to include shell output inside a string, it can just run the shell itself and then pass the resulting value to UI::Dialog? Even more, I do not think all backends actually use shell commands, so embedding shell escapes wouldn't actually work with all backends? I haven't looked at the trusted input changes in much detail, since I'm not familiar with the code, and a lot of whitespace changes clouded that diff. Gr. Matthijs
Content-Description: Digital signature
Content-Type: application/pgp-signature; name="signature.asc"
Content-Length: 819
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

MIME-Version: 1.0
X-Spam-Status: No, score=-6.599 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, FROM_OUR_RT=-4, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-17578-1444729548-642.107364-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-107364 [...] rt.cpan.org> <20150927103509.GX27418 [...] login.tika.stderr.nl> <rt-4.0.18-19911-1443370526-317.107364-6-0 [...] rt.cpan.org> <20150927162822.GB27418 [...] login.tika.stderr.nl> <rt-4.0.18-11052-1443371325-1133.107364-6-0 [...] rt.cpan.org> <rt-4.0.18-31486-1444380853-135.107364-6-0 [...] rt.cpan.org> <rt-4.0.18-16750-1444674480-19.107364-6-0 [...] rt.cpan.org> <20151013094531.GL8704 [...] login.tika.stderr.nl> <rt-4.0.18-17578-1444729548-642.107364-5-0 [...] rt.cpan.org>
X-Virus-Checked: Checked
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.180.109.200 with SMTP id hu8mr23265128wib.86.1444780769295; Tue, 13 Oct 2015 16:59:29 -0700 (PDT)
Message-ID: <CADAZLbNds9M-ZzP3996x=Tw0C13pEpRHnK_GLGwYWTOJPrfEPg [...] mail.gmail.com>
Content-Type: multipart/alternative; boundary="e89a8f3bab3f8857870522053c78"
X-Spam-Score: -6.599
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 91BB7240029 for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Tue, 13 Oct 2015 19:59:40 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHo+vhAfBIcG for <cpan-bug+UI-Dialog [...] hipster.bestpractical.com>; Tue, 13 Oct 2015 19:59:39 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id ADAED240026 for <bug-UI-Dialog [...] rt.cpan.org>; Tue, 13 Oct 2015 19:59:38 -0400 (EDT)
Received: (qmail 4825 invoked by alias); 13 Oct 2015 23:59:37 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com) (209.85.212.175) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 13 Oct 2015 16:59:35 -0700
Received: by wieq12 with SMTP id q12so56900393wie.1 for <bug-UI-Dialog [...] rt.cpan.org>; Tue, 13 Oct 2015 16:59:29 -0700 (PDT)
Received: by 10.194.236.72 with HTTP; Tue, 13 Oct 2015 16:59:29 -0700 (PDT)
Received: by 10.194.236.72 with HTTP; Tue, 13 Oct 2015 16:59:29 -0700 (PDT)
Delivered-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #107364] Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
Return-Path: <kevin [...] krinke.ca>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+UI-Dialog [...] hipster.bestpractical.com
X-RT-Mail-Extension: ui-dialog
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:date :message-id:subject:from:to:content-type; bh=5EntB/FtStBiSfUC0vZsnL/6e/P9YqcTMiIsCL5sWpY=; b=dQV188LpoWOI1J63Bknno0c5dMOIJiGc5Hj4qn5ZJ7rSqn1kDxJW3iuM15a4ognOHm Y0uJIJKZk8HQIGc7DAjhjg1WX4/OUbHdhxmYcsKJRxePLMgS8jFSeekgZGMdg9RRAl/K Fj0gzq052CmHGFPPHb6OQ3gP/CXGFRXFnzHXUhhTnsd1eLjjV+ok78Zo+nppoo9n7Jmp ph5qHjv2BC7Xc8yzvHrX5yg7kgOyfociQnzUCHtpsPT9f0F7wNyS4CgfpOuq++0rvwXu vQRMiApdGLOGzGxxcXKNJN01PW5ateFZ7y2zIcg6/Am75fzZ0WPy9JwgHG+bU3GQSr80 /r2g==
Date: Tue, 13 Oct 2015 19:59:29 -0400
X-Spam-Level:
X-Originating-Ip: [69.165.131.5]
To: bug-UI-Dialog [...] rt.cpan.org
X-GM-Message-State: ALoCoQlVZjStkQfmHQbgSXZorrvRB4sQHg7AZp54T7PCXsA4I1Y51/EUsYMKVMCdhtHWLv4U9q7L
From: Kevin Krinke <kevin [...] krinke.ca>
RT-Message-ID: <rt-4.0.18-3765-1444780781-1546.107364-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 2745
Download (untitled) / with headers
text/plain 2.6k
Hi Matthijs, On Oct 13, 2015 5:46 AM, "Matthijs Kooijman via RT" < bug-UI-Dialog@rt.cpan.org> wrote: Show quoted text
> > Queue: UI-Dialog > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=107364 > > > Hi Kevin, > > I just gave the test branch a whirl, and it seems it indeed fixes the > security issue. There's still two things I'm wondering: > > - If I include $(pwd) in a menu item, it seems that the $ is *removed* > from the displayed string. When I use `, it seems a normal quote ' is > displayed instead. I guess that completely removing these potentially > dangerous characters is safest, but this also limits the > expressiveness of scripts. Was escaping these characters instead of > removing them not possible?
The escaping proved to be unreliable and I quickly hit corner cases where you'd see \'s but the $( got removed from the output by the shell, or rather, $( isn't a variable and was replaced with null space. Show quoted text
> - Looking through the commits, it seems you added support to mark input > as "trusted", which I presume it will not be subjected to sanitizing > / escaping. However, what's the actual usecase for this? If some > script wants to include shell output inside a string, it can just run > the shell itself and then pass the resulting value to UI::Dialog? > Even more, I do not think all backends actually use shell commands, > so embedding shell escapes wouldn't actually work with all backends?
All backends use system() with the exception of ASCII. I personally have scripts that utilize sub-commands which I trust the input from and so this feature makes sense to me. The default behaviour is the safest possible while still allowing for the programmer to explicitly enable the trust-input behavior. Also, I would like to maintain as much backwards compatibility as possible, otherwise there's a lot of things I'd fundamentally change. Show quoted text
> I haven't looked at the trusted input changes in much detail, since > I'm not familiar with the code, and a lot of whitespace changes > clouded that diff.
There should be an option on github to ignore the whitespace when viewing changes. The general indentation over the years has somehow gotten mangled with tabs and inconsistent spacing... figured I'd cleanup as much of the code as I can before putting things on back to maintenance only mode. As a final note, I figured out a simple path to unit testing the problem. Half of the backends are in compliance, others need work still. Just found out Xdialog has been removed from debian completely and I can't even compile it from source because libgtk1.2-dev doesn't exist in debian either! *sighs* I'm going to attempt porting Xdialog to Mate at some point. My best, Kevin
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 3355
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-3765-1444780781-1546.107364-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-11052-1443371325-1133.107364-6-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-14131-1454263303-147.107364-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2977
Download (untitled) / with headers
text/plain 2.9k
On Tue Oct 13 19:59:41 2015, KCK wrote: Show quoted text
> Hi Matthijs, > > On Oct 13, 2015 5:46 AM, "Matthijs Kooijman via RT" < > bug-UI-Dialog@rt.cpan.org> wrote:
> > > > Queue: UI-Dialog > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=107364 > > > > > Hi Kevin, > > > > I just gave the test branch a whirl, and it seems it indeed fixes the > > security issue. There's still two things I'm wondering: > > > > - If I include $(pwd) in a menu item, it seems that the $ is *removed* > > from the displayed string. When I use `, it seems a normal quote ' is > > displayed instead. I guess that completely removing these potentially > > dangerous characters is safest, but this also limits the > > expressiveness of scripts. Was escaping these characters instead of > > removing them not possible?
> > The escaping proved to be unreliable and I quickly hit corner cases where > you'd see \'s but the $( got removed from the output by the shell, or > rather, $( isn't a variable and was replaced with null space. >
> > - Looking through the commits, it seems you added support to mark input > > as "trusted", which I presume it will not be subjected to sanitizing > > / escaping. However, what's the actual usecase for this? If some > > script wants to include shell output inside a string, it can just run > > the shell itself and then pass the resulting value to UI::Dialog? > > Even more, I do not think all backends actually use shell commands, > > so embedding shell escapes wouldn't actually work with all backends?
> > All backends use system() with the exception of ASCII. > > I personally have scripts that utilize sub-commands which I trust the input > from and so this feature makes sense to me. The default behaviour is the > safest possible while still allowing for the programmer to explicitly > enable the trust-input behavior. > > Also, I would like to maintain as much backwards compatibility as possible, > otherwise there's a lot of things I'd fundamentally change. >
> > I haven't looked at the trusted input changes in much detail, since > > I'm not familiar with the code, and a lot of whitespace changes > > clouded that diff.
> > There should be an option on github to ignore the whitespace when viewing > changes. > > The general indentation over the years has somehow gotten mangled with tabs > and inconsistent spacing... figured I'd cleanup as much of the code as I > can before putting things on back to maintenance only mode. > > As a final note, I figured out a simple path to unit testing the problem. > Half of the backends are in compliance, others need work still. Just found > out Xdialog has been removed from debian completely and I can't even > compile it from source because libgtk1.2-dev doesn't exist in debian > either! *sighs* I'm going to attempt porting Xdialog to Mate at some point. > > My best, > Kevin
-- Kevin C. Krinke <kevin@krinke.ca> GPG Key: http://bit.ly/1eXz4W8


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.