[CentOS] bash - safely pass untrusted strings?

[Garrick Staples]

On Tue, Feb 26, 2008 at 08:25:54AM -0800, Benjamin Smith alleged:
> On Tuesday 26 February 2008, Ralph Angenendt wrote:
> > > There is no mechanism for escaping untrusted input?
> > 
> > Correct. At least there's no magic quoting function.
> 
> Ok. So I'm going to have to pull up my sleeves and do this with sed/awk pipes. 
> Got it. I'll quit looking for a simply solution to this (I thought) simple 
> problem.
> 
> Now for a more philosophical question....
> 
> WHY THE @!#! NOT?!?!?
> 
> Bash is used, extensively in many cases, to deal with untrusted data. 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. 
> 
> Yet there exists NO MECHANISM for simply ensuring that a given argument is an 
> escaped string? 
> 
> How many "homebrew" ISP or hosting administration scripts could be compromised 
> by simply putting a file in your home directory called ";rm -rf /" ? 

It's not as bad as you think because of the order of operations.

In all cases, these perform exactly as a string should regardless of inner
characters.

$ f='echo a; echo b'
$ $f
a; echo b

$ dq="echo a; echo b; echo \`\ '\ \""
$ $dq
a; echo b; echo `\ '\ "
$ echo $dq
echo a; echo b; echo `\ '\ "
$ `$dq`
-bash: a;: command not found
$ `echo $dq`
a; echo b; echo `\ '\ "

-- 
Garrick Staples, GNU/Linux HPCC SysAdmin
University of Southern California

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20080226/dfd2681e/attachment.sig>