Re^5: Doubt in perl taint

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

Comment on Re^5: Doubt in perl taint Download Code

Replies are listed 'Best First'.
Re^6: Doubt in perl taint by ikegami (Patriarch) on Dec 13, 2008 at 18:43 UTC
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]
Re^7: Doubt in perl taint by Bloodnok (Vicar) on Dec 13, 2008 at 22:42 UTC
I have presented a simplified version of the investigations we made - as a direct consequence of which, a multi-million pound project was delivered on time ... just. BTW, I notice in your example, you run in the CWD and invoke via `./` - have you tried running your script in e.g. `$HOME`, setting the permissions on `/usr/bin` to `0755`, putting `/usr/bin` on your path (if it isn't there already) and invoking relatively using `$PATH` e.g. invocation by `ls`; as in the OP ? A user level that continues to overstate my experience :-))	[reply] [d/l] [select]
Re^8: Doubt in perl taint by ikegami (Patriarch) on Dec 14, 2008 at 01:58 UTC
While it has to be more permissive than 755, I stand corrected. `$ cp /bin/ls /tmp/ikegami/ $ chmod 777 /tmp/ikegami/ $ chmod 700 /tmp/ikegami/ls $ perl -T -e'%ENV=(PATH=>"/tmp/ikegami/"); system("ls") and die("error +: $?");' Insecure directory in $ENV{PATH} while running with -T switch at -e li +ne 1.` [download] (I used /tmp since I don't have root access.)	[reply] [d/l]