And if the user decides to type '|rm -rf' as an argument to a perl script, they could just as easily type 'rm -rf' at that same command line.
What about when the script runs as a different user than the one calling the script? This could be used to run a command with greater priviledge than one normally has.
For example, given mysetuid.pl
print <>;
An attack:
mysetuid.pl 'cat /etc/shadow |'
Well, at least taint catches this problem:
Insecure dependency in piped open while running with -T switch
Update: Oops, I guess just /etc/shadow would have worked in this case!
| [reply] [Watch: Dir/Any] [d/l] [select] |
As you point out, if real and effective user ids are different, taint mode is enabled automatically. So even if a script relying upon <> is accidently given the setuid bit, nothing nasty happens. That means the attack is not an attack.
My question still stands.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] [d/l] |
As you point out, if real and effective user ids are different, taint mode is enabled automatically. So even if a script relying upon <> is accidently given the setuid bit, nothing nasty happens. That means the attack is not an attack.
Except that taint doesn't stop you opening a file for reading. So, is there anything that taint considers opening "for reading", and which one would not be able to invoke using the 3-argument open? Well, there is, and it's hardly ever seen:
open(FH, '<&=0');
The special <&=n sequence instructs Perl to duplicate an existing filehandle. What interesting things can setuid programs have open that an attacker may wish to read? How about /etc/passwd after a getpwent() call?
perl -T -MFcntl=SEEK_SET -e'getpwent(); open(FH,q{<&=3}) or die $!; se
+ek(FH,0,SEEK_SET); print <FH>'
When running as root, the getpw* calls open /etc/shadow to read the password. My box closes the file immediately after, but do you trust every system to do that?
Network sockets, configuration files, or anything else that uses a filehandle is fair game for this attack. A setuid program that has open filehandles to privileged resources runs the very real risk of revealing information it shouldn't if you can get it to use a 2-argument open with user input.
Remember, taint doesn't help you here. We're opening a file for reading. ;)
| [reply] [Watch: Dir/Any] [d/l] [select] |
| [reply] [Watch: Dir/Any] |
Did you know the P5P refuse to fix the magical open for <>, it uses 2 argument open internally,
I haven't made up my mind on this yet, but what do you see wrong with that?
Like diotalevi always says: it is possible, even easy, to construct files with weird filenames on Unix. Unlike on Windows, special characters are not disallowed, only inconvenient. A user can use '|rm -rf /' as a file name, and then a simple invocation of
perl -ne 1 *
is enough to delete all the files you have write access to.
'Fixing' it, to use the 3-arg variant would entail throwing away a bunch of useful behaviours that the user can invoke from the command line.
Indeed, that is their excuse. | [reply] [Watch: Dir/Any] [d/l] [select] |
With your 2-arg using <>, how do you plan to deal with the guy in marketting when he's named something cute like "<< EXTRA!! >>"?. It's a filename so it should be maximally useful to the human using it. Probably a non-geek. The name supports having useful punctuation in it. It'd be nice if perl didn't croak when it tried to read the contents of that file. [Added: See what sucks is this "croak or nasal-demons on bad filenames" is that the calling program can be 100% sane and not have the shell invoked at all. perhaps just an execvp. This FUBARs all perl programs using the -p and -n switches too. *grumpy*!!]
| [reply] [Watch: Dir/Any] |