Re: bash - safely pass untrusted strings?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Benjamin Smith wrote:
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?!?!?

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.

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

Why?

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.

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?

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.

This doesn't strike you as fundamentally borkeD?

No, if you stop bad things from happening, you'll also stop good things.

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.

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.

This just blows my mind....

What would you like your computer to prevent you from doing to yourself?

--
  Les Mikesell
   lesmikesell@xxxxxxxxx

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux