[CentOS] bash - safely pass untrusted strings?

Benjamin Smith lists at benjamindsmith.com
Tue Feb 26 19:22:55 UTC 2008


On Tuesday 26 February 2008, Les Mikesell wrote:
> > 
> > WHY THE @!#! NOT?!?!?
> 
> The shell is 'supposed' to be run by a user that is allowed to run any 
> command he wants, and permission/trust issues are handled by the 
> login/authentication process that happens before you get to the shell. 
> If you give the shell a bad command under your own account, it's not 
> supposed to second guess what you wanted.

I'm not asking for this. I'm only asking for the option to be able to trust 
that a parameter is... a parameter. EG: 

file: script1.sh 
#! /bin/bash
script2.sh $1 
exit 0; 

file: script2.sh 
#! /bin/bash 
echo $1; 

$ script1.sh "this\ parameter"; 

I get output of "this"! script2 gets two parameters! I want a way for 1 
parameter to STAY 1 parameter upon request, so that script2.sh would 
output "this parameter", like 

file:script1.sh 
#! /bin/bash
PassToShell2=escapethis $1; 
script2.sh $PassToShell; 
exit 0; 

> > Bash is used, extensively in many cases, to deal with untrusted data.
> 
> Why?

How about an installer script? How about a magical script copied from TLDP to 
rename all files in pwd? 

> > This can 
> > include random file names in user home directories, parameters on various 
> > scripts, etc. It's highly sensitive to being passed characters that have, 
> > over the past NN years, resulted in quite a number of security holes and 
> > problems. 
> 
> If it hurts, don't do it.  Build your own argument list and exec 
> programs directly if you want to avoid shell command line parsing.

So, I'm supposed to know the contents of a user's home directory? And code for 
these in advance? 

> > Yet there exists NO MECHANISM for simply ensuring that a given argument is 
an 
> > escaped string? 
> 
> What does that mean?  If you can define it you can make it happen, but 
> who knows what characters at what depth of quoting will have some 
> special meaning?

Can I define it? Thought I did that already:
http://us.php.net/manual/en/function.escapeshellarg.php

Or its perl equivalent: 
http://search.cpan.org/~gaas/URI-1.35/URI/Escape.pm

See how I'd like to see it in implementation in above example, "passToShell2"

> > How many "homebrew" ISP or hosting administration scripts could be 
compromised 
> > by simply putting a file in your home directory called ";rm -rf /" ? 
> 
> Probably none that are still in business.

Google "bash howto" for lots of vulnerable and problematic examples. Here's a 
beaut that fails if you have a file called "-a" in the pwd, see "File 
re-namer". It's a renamer that doesn't, if the file contains any spaces, 
dashes, etc. 

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-12.html#ss12.1

Here's what I get: 

mv: invalid option -- a
Try `mv --help' for more information.

Or with a file with a space: 
echo "blah" > "d"; 
echo "blah" > "d foo"; 

The TLDP's example doesn't move file "d foo". I get: 
mv: cannot stat `d': No such file or directory
mv: cannot stat `foo': No such file or directory

So I ask again: This doesn't strike you as fundamentally borkeD? The emperor 
wears no clothes! 

> > This doesn't strike you as fundamentally borkeD?
> 
> No, if you stop bad things from happening, you'll also stop good things.

Yes. But you don't have to stop the good things. I think the *OPTION* of 
saying "parameter 1 is STILL parameter 1" is a good thing. If you want to 
leave things be, so be it. See my above example. 

> > Why would we accept a work 
> > environment that is effectively laden with randomly placed, loaded rat 
traps? 
> > Not trying to bash (ahem) bash needlessly, but this is a problem that so 
> > smacks of 1977... 
> 
> The problem is that you aren't using the shell as intended.  If you run 
> it under your own user id, it does exactly what you tell it to do and 
> there is no element of trust involved.

The problem, as I see it, is that the shell provides access variables without 
any means of preserving them as variables across calls and incantations.

> > I guess I just hadn't noticed how bad this was, since I started using PHP 
as 
> > shell scripts years ago to run everything, despite the mild performance 
hit. 
> > escapeshallarg() and addslashes() combined with a few backticks provides 
easy 
> > access to the power of the shell, and excellent "don't need to worry about 
> > it" security. 
> 
> Errr what???  Php has about the worst security history of any program 
> around.

Thanks for confusing the issue with a red herring. Or should I ignore the 
buggy and probably vulnerable TLDP example above? Maybe a google search 
for "bash escape vulnerability" might illuminate the issue I speak of?

> > This just blows my mind....
> 
> What would you like your computer to prevent you from doing to yourself?

I hate to belabor it: give me the OPTION to trust that I can keep a single 
parameter as a single parameter across incantations and calls. If I'm looping 
thru a listing files, I should be able to trust that my $FILENAME variable 
contains the name of... a file! If I want to pass parameter 1 of my script to 
another script, that other script should be ABLE get my parameter 1 as... 
parameter 1! 

A simple call that lets me take a string and get a passable parameter would 
suffice. 

You want to apply scripts that break with a space in a file name? Great. Have 
at it. I don't want to detract from your ability to make an alphabet soup of 
your directories with borken examples from TLDP, and all the goodness that 
implies to you. 

But I think admins the world over would like it if a simple, one-liner could 
be added to ensure that a single parameter remains a single parameter!

Am I being unclear?
-- 
--
Only those who reach toward a goal are likely to achieve it. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the CentOS mailing list