in reply to Re^3: Runtime Taint Enable
in thread Runtime Taint Enable

Any external data can (and should) be marked as tainted. This includes but is not limited to: the results of system calls, database results, and anything that is derived from these. Basically, anything that came from outside your program should be viewed as suspect when thinking about taint.
That I disagree with. If I'm in full control of my box, I may consider any file (especially configuration files) on the box to be safe (and if I couldn't, why would I trust /usr/bin/perl?). I might consider all modules safe. All environment variables to be under my control. But not the data that I'm reading from a socket, because that's outside of my control.

There are a lot of situation where I turn on taint checking because there's a limited amount of external data that I consider tainted. (Basically, this boils dows to the fact that what is external data for me doesn't coincide with what Perl considers to be external data - and I don't blame Perl for that, because Perl can't know.)

Replies are listed 'Best First'.
Re^5: Runtime Taint Enable
by thor (Priest) on Feb 24, 2005 at 17:08 UTC
    Okay...I'll bite. Consider the following program: 
    use warnings;
use strict;

foreach my $file (<*>) {
   if ($file =~ m/(.*)/) { #we trust everything from *our* box
      $file = $1;
      my $rc = system("rm", $file);
   }
}

    [download]
    Now consider this file listing: 
    -rw-rw-r--   1 thulben  thulben         1 Feb 24 11:03 -rf
-rwxr-xr-x   1 thulben  thulben       254 Feb 24 10:59 unsafe.pl*

    [download]
    Whoops!

    thor

    Feel the white light, the light within
    Be your own disciple, fan the sparks of will
    For all of us waiting, your kingdom will come

[reply]
[d/l]
[select]
      So the question is - how did those files get on the system. Most likely they are user files created in some user usable process/cgi - so the filenames themselves would be considered user data and *hopefully* taint mode would be enabled before dealing with user data. If it isn't user data from a user usable process - then it might be a good idea at this point to check for rootkits.

      Either way - things might be legitimate on this box - these may be perfectly legal files. The process just needs to be sure to enable taint mode before doing such horridly taint unsafe operations.

      It seems the higher the risk, or the more unknown the modules are that are being used, the closer to the beginning of the script that taint mode should be enabled. In a setuid situation it should probably be so close the beginning of the script that you use the -T.

      Oh - I see you untainted - so tainting doesn't matter. Well there are a few things going in your favor. First - for this operation to work you had to be chrooted into the directory or else rm $file isn't going to work. That, or the filename returned by the <*> is going to contain the full filename /path/to/file/-rf which will most likely just give an error. So this case probably wasn't a tragedy. There are worse filenames though that certainly would cause trouble like "foo; rm -rf /" (The entire quoted string is the filename). This then becomes an issue not of taint/untaint but vs sane programming practices - such as using unlink and rmdir and File::Path::rmtree and avoiding system and exec were possible. And certainly not blindly untainting things "we" trust.

      As a foot note - I've managed to create files like that before (on accident) and getting rid of them is a pain (without perl). But, in a production environment, people with the ability to put such files in places that will get read and actually do put such files in those places - those people ought to have access revoked. The hand creating of such a file indicates that much worse things almost happened at the file creation.

      Again - thanks for your cautionary reponse. I agree. ++

      my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]

In Section Seekers of Perl Wisdom