in reply to Re^2: Doubt in perl taint
in thread Doubt in perl taint

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 :-))

Replies are listed 'Best First'.
Re^4: Doubt in perl taint
by ikegami (Patriarch) on Dec 13, 2008 at 17:31 UTC
    You went way beyond making observations. You falsely claimed the actions were a result of using tainting. You falsely claimed the actions were performed by Perl. Not only is it done by the setuid which you didn't even mention, ls isn't even setuid!
[reply]
[d/l]
      No, ikegami, I believe I didn't either go "way beyond making observations", nor "falsely claim the actions were a result of using tainting" - all I did was to attempt to help the poster by giving the benefit of my industrial experience.

      In this case, the, admittedly not entirely exhaustive (project time pressures prevailed on us) investigations into problems we were experiencing revolved around the following...

      • Remove tainting - perl ran the script
      • Change the permissions on the called binarys' containing directory - perl ran the script
      • Copy the called binary from the 'open' directory to a more 'restrictive' directory and change to call to an absolute, from a relative, call - once again, perl ran the script
      Ergo, we concluded, tainting must be checking permissions of the containing directory. The setuid thing is a red herring, since, in our case, the binary was merely an e-mail client called indirectly from a CGI script.

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

        I didn't either go "way beyond making observations", nor "falsely claim the actions were a result of using tainting"

        Your claim that "taint checking isn't confined to the code - the checking involves things like [...] permissions on directories" is false. Which also means you couldn't have observed it.

        Remove tainting - perl ran the script

        Can't be. Tainting doesn't check permissions. 

        $ cat > child
#!/usr/bin/perl
print("child\n");

$ chmod a=rwx,u+s child

$ ls -l child
-rwsrwxrwx 1 ikegami group 34 2008-12-13 10:39 child

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

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

        [download]

        With and without tainting, Perl successfully executed the world-writable child ($? != -1).

        The setuid thing is a red herring, since, in our case, the binary was merely an e-mail client called indirectly from a CGI script.

        I've already shown that executing world-writable files is not prevented by tainting. If it's not setuid, it's something else. But not tainting. 

        $ cat > child
#!/usr/bin/perl
print("child\n");

$ chmod a=rwx,a-s child

$ ls -l child
-rwxrwxrwx 1 ikegami group 34 2008-12-13 10:39 child

$ perl -T -e'%ENV=(); system("./child") and die("error: $?")'
child

        [download]

        Even with tainting, Perl successfully executed the world-writable child ($? != -1) and it ran without error ($? == 0).

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom