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



Subject: Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
Date: Sun, 27 Sep 2015 12:35:09 +0200
To: bug-UI-Dialog [...] rt.cpan.org
From: Matthijs Kooijman <matthijs [...] stdin.nl>
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
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

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>
Subject: Re: [rt.cpan.org #107364] Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
Date: Sun, 27 Sep 2015 18:28:23 +0200
To: "Kevin C. Krinke via RT" <bug-UI-Dialog [...] rt.cpan.org>
From: Matthijs Kooijman <matthijs [...] stdin.nl>
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
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

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
Subject: CVE-2008-7315 assigned
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
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
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
Subject: Re: [rt.cpan.org #107364] Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
Date: Tue, 13 Oct 2015 11:45:31 +0200
To: "Kevin C. Krinke via RT" <bug-UI-Dialog [...] rt.cpan.org>
From: Matthijs Kooijman <matthijs [...] stdin.nl>
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
Download signature.asc
application/pgp-signature 819b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #107364] Security problem: improper shell escaping in whiptail, cdialog and kdialog backends
Date: Tue, 13 Oct 2015 19:59:29 -0400
To: bug-UI-Dialog [...] rt.cpan.org
From: Kevin Krinke <kevin [...] krinke.ca>
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
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.