tainting?

[hearts]

question: what does taint mean/do?

Added -T taint checking to the header of the CGI script

[Deb]

Freeware CGI Scripts are available for download all over the Web. But how many of them are really secure? When you download a script do you check all the logic to make sure it is secure? Do you read through each line of code and anticipate all the ramifications? Most of the time the answer is "no". After all, the whole point of downloading software is to get it and run it for free WITHOUT having to do a lot of work.

I'm writing this to tell you that there isn't any free lunch out there. The more complicated a CGI script is, the more likely you will want to find someone else who has already programmed it and avoid doing the work yourself.

The problem is that regardless of how good the author is, every large program has a good probability of having bugs -- some of them may be security bugs.

One very good way to lock out security bugs in Perl code is to turn on TAINT mode. TAINT mode puts a Perl script into "PARANOID" mode and treats ALL user supplied input as tainted and bad unless the programmer explicitly "OKs" the data.

I couldn't have said it better http://www.aota.net/ubb/wink.gif

You'll find the above and more info at http://www.extropia.com/faq/taintmode.html#what

Hope this helps
Deb

[jenili]

hearts,
http://www.aota.net/ubb/Forum11/HTML/000016.html
ChrisH posted a nice explanation of this there.

jeni

[ChrisH]

Actually . . . I think it was you! http://www.aota.net/ubb/smile.gif

[hearts]

thanks..but Deb covered it.. http://www.aota.net/ubb/smile.gif

[colulus]

In light of suExec, what can happen with tainted code? If for example someone uses the following in their cgi

print "userid: ";
chop($pat = <STDIN>);
print 'grep $pat *';


and the visitor enters
userid: ; rm *

... what will happen?

Will the server be hosed? Will only the website's account contents be deleted? Or will much less damage occur? Just curious how Futurequest servers respond to shell commands entered from cgi.

Thanks

[Terra]

Simple, it would delete any files that your userid has permissions to remove...

In short, it would lunch your account...

A word of the wise, do not use either:
system()
or
backticks: `command`

Always try and use the perl self-pipe exec trick to make sure you don't get snagged by metacharacters...


open(C, "-|") || exec ('/bin/ls', '-ls');
@filelist = <C>;
close C;
chomp @filelist;

I leave further research to those willing to find explanations of this on the web...

--
Terra
--I once did '-|-' and was rather embarrassed--
FutureQuest

[colulus]

Thanks Terra,
I'll get to digesting this snippet. I'm just learning Perl.

Last night I was reading through a recent Wired (with an Intel personality on the cover), and found an article about "decoding DVD in less than seven lines of code". A solution named grpff was a slurry perl six lines long. I look forward to understanding RE's and perl syntax well enough to understand that thing. The article does give a color coded tour of the script's basic functionality.

http://www-tech.mit.edu/V121/N12/col12yue_c.12c.html
http://www.prenhall.com/divisions/bp/app/malaga/apr2001.html#grpff
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/

[Rich]

I leave further research to those willing to find explanations of this on the web...
I have yet to understand why this works. I have read lots of documentation about HOW to do this but not WHY it works.

Questions:

(1) What makes an exec inside a child process safer than an exec inside the parent process?

(2) If you are passing inside the exec some user-supplied input, what makes the metacharacters inside the user-supplied input magically disappear just because it's used in the child rather than the parent?

Rich

[Terra]

Rich:

Simply, you are bypassing the shell and passing the command *directly* to the kernel exec() call...

There is no shell meta-character processing going on...

BTW, the self-pipe trick is sort of a perl idiom...

--
Terra
--It's fairly simple once you turn your brain sideways--
FutureQuest

[Rich]

Thanks, Terra.

My brain is currently inside-out, but a couple more tugs ought to get it sideways again. :)

I've actually used this construct before but I wasn't really sure exactly why it worked. So, let me see if I understand what you're saying...

The shell will be involved in the parent when the piped handle is created to the exec, but not in the child because you are then doing i/o directly with the handle?

Rich
-- crossing fingers

[Terra]

In short:

open (I, "-|")
setup pipe on descriptors 4 and 5
fork (parent gets child pid)
parent: close 5
parent: reads from 4 (stalls)
parent: close 4
dup2(5, 1) "remaps 5 to STDIN"

|| exec '/usr/bin/id';
from the fork child gets 0, hence child doing the 'exec'
entire perl child is exec'd (replaced) with /usr/bin/id
/usr/bin/id output goes to STDOUT

@slurp = <I>;
is simply reading the results of 'Child STDOUT --> Parent STDIN'

In the Parent and Child relationship, the pipes are reversed and interlocked with Parent reading from STDIN and Child writing to STDOUT

Child --STDOUT--> PIPE --STDIN--> Parent

and the entire time, the Child exec *never* touches or needs the 'csh' to launch the final '/usr/bin/id' program...

All:
$my_id = `/usr/bin/id`

basically does is:
$sh -c /usr/bin/id

hence susceptible to being tricked by bad characters...

The '/usr/bin/id ; /bin/BadThing' only affects the command shell as ';' is a command separator... exec() has no clue how to handle that and sees it as one big happy command that will probably just give you unexpected results...

That is about as simplistic as I can explain the self-pipe trick...

--
Terra
--Ever feel like the monkey sitting on top of the organ grinder's box--
FutureQuest

[Rich]

The '/usr/bin/id ; /bin/BadThing' only affects the command shell as ';' is a command separator... exec() has no clue how to handle that and sees it as one big happy command that will probably just give you unexpected results...
That's the part I keep scratching my head over...

If exec doesn't care in the child, why would an exec in the parent care?

If a forked process can invoke exec without using the shell, then why can't the parent?

# parent.pl
exec `goodstuff;badstuff`;

How can a spawned (child) process inherit a capability that the parent did not possess?

Rich

[Terra]

Simple, if you exec in the parent - the the parent is replaced by whatever you exec...

Read:
$man 3 exec
keep scratching
8}

--
Terra
--Unix 101--
FutureQuest

[Rich]

Simple, if you exec in the parent - the the parent is replaced by whatever you exec..
Which should be true in the child also...

From perldoc exec:

If there is more than one argument in LIST, or if LIST is an array with more than one value, calls execvp(3) with the arguments in LIST. If there is only one scalar argument or an array with one element in it, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is /bin/sh -c on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to execvp, which is more efficient.

Note that the stated reason for whether or not the shell is involved relates to whether or not metacharacters are present.

Summary:

(1) The documentation states the shell is invoked when metacharacters are involved with no mention of "except if this is a child process".

(2) However, the examples using piped child processes indicate that child processes inherit some "magical" shell by-passing capabilities that the parent did not possess with respect to scalar arguments.

I guess I'll just go on living with the fact that there is some undocumented mechanism going on here that allows this to happen and either no one else understands it either or else they do not know how to put it in to words. %)

Rich

[Terra]

Which should be true in the child also...
exactly... ;)

The Parent needs to live in order to process what the Child produces...

If you exec the Parent, then what remains to process the output?

--
Terra
--The world would be a better place if more Parents would listen to their Child(ren)--
FutureQuest