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 <>;
[download]

An attack:

mysetuid.pl 'cat /etc/shadow |'
[download]

Well, at least taint catches this problem:

Insecure dependency in piped open while running with -T switch
[download]

Update: Oops, I guess just /etc/shadow would have worked in this case!

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.

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');
[download]

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>'
[download]

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. ;)

Paul Fenwick
Perl Training Australia

How about a web application where the user provides a filename? A bit contrived, sure, but I think it fits the criteria.

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?

perl -ne 1 *
[download]

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

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*!!]