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

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

I don't know much about web apps, so you tell me. Is there any way that input from a user via a web app will be used by <>, without the programmer explictly assigning it to @ARGV? Even then, shouldn't all cgi scripts have taint mode enabled?

If the programmer is going to ignore taint or detaint and then assign unvetted filenames from an unknown user into @ARGV, do you think that changing the magic open to use the 3-arg variant will stop them?

Aren't they just as likely to use the 2-arg open themselves, or a piped open, or IO::Pipe or $secretInfo = `cat $filename`;?

Also, don't most cgi scripts run under userids that have specifically restricted privileges, and rooted to heavily restricted portions of the server directory space specifically to prevent or severally restrict the possibility of this kind of damage?

---

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.

I don't know much about web apps, so you tell me. Is there any way that input from a user via a web app will be used by <>, without the programmer explictly assigning it to @ARGV?

Since no one else has, I'll tell you. Yes, there is. It's sort of a holdover from back when ISINDEX was actually common. When called with a query string not containing an equals sign ("=") the query string is supplied to the script via argv. If the query string contains one or more plus signs ("+") then the string is split on those and each fragment becomes a separate argument in argv.

For example... put this in a cgi script...

#!/usr/bin/perl 
print "Content-type: text/plain\n\n";
print while (<>);
[download]

And then open http://yourhost/path/to/that/script.cgi?script.cgi+script.cgi And you should see the source of the script printed twice.

Don't leave that on your server, of course.

-sauoq
"My two cents aren't worth a dime.";

I'm not sure how @ARGV and <> came into the picture, but your points are well-made. I was just suggesting one possible way the three-arg open was superior to the two-arg version. And again, the example was a bit contrived. :)