lakshmananindia has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks,
First I will explain what I understood about perl taint.

It will prevent you from using or relying on data that was provided from outside the script.

Is this right?

If right, then please look the code below 

use strict;
use warnings;
system("ls");

[download]
When I run this script with -T switch, it tells
Insecure $ENV{PATH} while running with -T switch at a.pl line 32. error
But my question is, inside the script only I gave the input. So why it is telling error.

If my understanding is wrong on perl taint, please correct me.

Replies are listed 'Best First'.
Re: Doubt in perl taint
by Skeeve (Parson) on Dec 13, 2008 at 07:08 UTC

    You want to execute ls

    Q: But which ls?

    A: The one the system seems fit.

    Q: But how does the system decide which fits?

    A: By consulting the $PATH environment variable

    Q: Who sets this?

    A: Someone, but not your script. So data from outside!

    s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
    +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
[reply]
[d/l]
[select]
Re: Doubt in perl taint
by ikegami (Patriarch) on Dec 13, 2008 at 07:13 UTC

    The initial state of your process's environment is controlled by the parent process, and is thus tainted. 

    $ echo '#!/usr/bin
> echo owned
> ' > ~/evil/ls

$ chmod 755 ~/evil/ls

$ PATH=~/evil/:"$PATH" script.pl
owned

    [download]

    The environment needs to be scrubbed.

[reply]
[d/l]
Re: Doubt in perl taint
by nagalenoj (Friar) on Dec 13, 2008 at 09:04 UTC
    Dear monk,

    Perl Taint the use of a potentially "unsafe" operation to be illegal. Potentially "unsafe" operations are operations that have a potentially permanent destructive effect if the wrong parameters are passed.

    Potentially unsafe operations include, but are not necessarily limited to, system calls of any sort such as using system(), backticks or piped open() calls, open calls that can write to disk, unlink() which deletes files, and rename().

    Kindly refer the following url for more,

    http://gunther.web66.com/FAQS/taintmode.html
[reply]
Re: Doubt in perl taint
by Bloodnok (Vicar) on Dec 13, 2008 at 12:08 UTC
    As others have pointed out, taint checking isn't confined to the code - the checking involves things like the run-time environment and when I say environment, I mean things like permissions on directories &/or files that your script accesses, having potentially unsafe directories on your path etc.

    By way of explanation, there used to be a security hole on Solaris whereby /usr/bin was installed with permissions of 777 such that running a perl script (using -T) in which access was made to a binary e.g. ls, in the directory, then the script failed taint checking becuase the whole world & his uncle could potentially overwrite the accessed binary.

    A subsequent security patch modified the permissions to 755 - at which point perls' taint checking found no problem with the use of the binary (tho' may have found problems elsewhere in the code;-).

    For the case I have in mind, the system had both /usr/bin/ls & /bin/ls - where the permissions on /bin were 755 - changing the call from `ls` to `/bin/ls` provided an interim fix.

    HTH ,

    A user level that continues to overstate my experience :-))
[reply]
[d/l]
[select]

      the checking involves things like the run-time environment and when I say environment, I mean things like permissions on directories &/or files that your script accesses, having potentially unsafe directories on your path etc.

      perl does none of those things. Tainting doesn't cause Perl to check anything but the taint flag on Perl values.

      then the script failed taint checking becuase the whole world & his uncle could potentially overwrite the accessed binary.

      Not at all. 

      $ cat child
#!/usr/bin/perl
print("child\n");
$ ls -l child
-rwxrwxrwx 1 ikegami group 34 2008-12-13 08:15 child
$ perl -T -e'%ENV=(); system("./child") and die("error: $?")'
child

      [download]

      Now, the system won't let me run a world-writable setuid program, but that has nothing to do with Perl. 

      $ chmod a+s child
$ perl -T -e'%ENV=(); system("./child") and die("error: $?")'
Setuid/gid script is writable by world.
error: 6400 at -e line 1.

      [download]
[reply]
[d/l]
[select]
        ikegami, I was giving the poster the benefit of observations made and indeed, documented on a Solaris 6/ActiveState perl 5.004 (they wouldn't consider getting more up to date due to the security accreditation process) project.

        Setting the setuid bit is, at best, a high risk strategy. Solaris has considered setuid scripts a security risk (and thus not honoured the setuid bit on a script) for an awfully long time - since @ least Solaris 6 QU 0898 - or earlier.

        A user level that continues to overstate my experience :-))
[reply]

Back to Seekers of Perl Wisdom