Taint mode does that, and more. It forces the programmer to specify and launder what form of input they require. If you don't use Taint mode in your publically accessible programs, or are too generous in whitewashing your input data, that's still a fault of the programmer though.

The function is documented to open the specified file. It should either do that or return an error, not (attempt to) open a different file.

Yes, but unless you plan to replace even more of the OS by Perl, what better way of opening a file do you see than asking the OS to open it?

Of course, Perl could try to wrap all C APIs that are known to take a C string and prevent passing a filename to them that contains a \0, but enabling Taint mode does about the same unless you're actively opening that door again.

That's true, but let me just ask you this. If you were to write an extensive secure programming tutorial for Perl developers within your company, would you just say "always use -T or I will kill you" and hope they do, or would you also explicitly mention poisoned nulls on system calls and describe the attack ?

If the later, then I can't see why you wouldn't be keen to have the issue totally eliminated by a simple (I'm guessing) change to the interpreter. It would save you some typing in your tutorial, if nothing else :)

I think you're being a bit unreasonable in this reply. There are a large number of things that you shouldn't pass to open (or anything outside your program). Yes, 'somebody' could document all of the many exploits that can be prevented by using -T, but a desire to avoid -T is no reason to complain about perl not covering up holes in the underlying OS's system calls. And Yes, if you are writing a program that takes input from the untrusted, you should understand the weaknesses of the APIs and system calls to which you are passing off this untrusted data. This is the whole point of taint mode.

If the later, then I can't see why you wouldn't be keen to have the issue totally eliminated by a simple (I'm guessing) change to the interpreter.

You're welcome to write a patch, and submit it to p5p.

• If you're in a hostile environment, use taint.
• A NUL byte is illegal in filenames on most OSses, including Unix and Windows flavours. It's not like "I give 'open' a valid filename, and it opens another file".
• It doesn't behave any different from the underlaying system functionality.
• There's actually a documented 'trick' that makes use of NUL characters (if you want to open a file containing trailing whitespace - this predates 3-arg open).
• Perl core developers may be smart, but there are only a few. Things will only change if someone has an itch to scratch. They don't scratch other peoples itches. If noone is bothered enough by this issue to write a patch, it will be there for years to come. Scanning for NUL bytes doesn't seem to require an enormous amount of tuits.

A NUL byte is illegal in filenames on most OSses

And so is the pipe in Windows, yet.

>perl -wle"open my $fh, '>', 'a|' or die $!"
Invalid argument at -e line 1.

>dir /b a
File Not Found
[download]

It doesn't behave any different from the underlaying system functionality.

So I'm expected to know the underlying function call used for each system and ignore the documentation?

There's actually a documented 'trick' that makes use of NUL characters (if you want to open a file containing trailing whitespace - this predates 3-arg open).

People use my ... if ...; too even though it's documented to be invalid Perl. The solution is to provide a better alternative (state vars and 3-arg open).

Perl core developers may be smart, but there are only a few.

You've been defending the behaviour up until now, yet you now say it's only present because noone's gotten around to fixing it?

Is that even the case, or did they reject a fix?

The solution is to provide a better alternative

Providing a better alternative doesn't imply making the old behaviour illegal - specially not if it's documented and people rely on it. And note that my ... if ...; only worked as an artifact of the implementation - and then only under certain conditions.

Is that even the case, or did they reject a fix?

AFAIK, noone on p5p is considering this issue a huge problem (as far as I can see, it's not even in perltodo), and noone ever proposed to change/fix it - I cannot recall it being rejected. Which means that if you^* think it's important enough to fix, you should do the work. Either by writing a patch (it's probably to late to get it into 5.10.1), or at least by lobbying your case on p5p, and finding someone else to do the work for you.

Bitching about it on perlmonks is an inefficient way to change perl.

^*That's a generic you.

Excellent answer, thankyou.

I agree that scripts *should* use taint, but what if they don't ? A quick search of the bugtraq archives found http://www.securityfocus.com/archive/1/317234, which to my reading looks like a dodgy old CGI script that would cease to be exploitable if the Perl interpreter had poisoned null countermeasures. Seems like a good thing to me, maybe I will take a stab at writing a patch.

Thanks again

I agree that scripts *should* use taint, but what if they don't ?

Then they don't, and take a risk. I don't find, in general, the argument "what if people ignore the safety devices we give them?" very valid.

http://www.securityfocus.com/archive/1/317234, which to my reading looks like a dodgy old CGI script that would cease to be exploitable if the Perl interpreter had poisoned null countermeasures.

From the description of the code, it seems that 1) the code doesn't use taint - the substitution on the cookie failed, so the cookie would still have been tainted. 2) the cookie is interpolated into a string, then evalled. I'm pretty sure that leaves many other possibilities to execute arbitrary code.

Seems like a good thing to me, maybe I will take a stab at writing a patch.

You might consider using an embedded NUL for system calls a warning - people can than use FATAL to upgrade the warning to an exception.

Yes, it would be quite trivial to get Perl's open-like constructs to fail (actually die) when given a filename matching /\0./s, and that would quite simply be a "good thing" despite all of the apologists in this thread and in p5p (notably excepting ikegami -- thanks). This should also apply to the stat-like constructs, of course.

I encourage you to visit corehackers and submit your patches in that much more receptive environment (compared to p5p). This would be a very nice improvement to Perl's security vulnerabilities.

I'm curious - wouldn't that prevent you from opening files with UTF-16 encoded names under windows? Or does that use an entirely different API?

If that's not a problem, I'm all for making it fatal.

Perl's open can't be used for opening UTF-16-encoded filenames under Windows. To be clear, all filenames are encoded in UTF-16 under the covers in Windows, but the string (of bytes) passed to Perl's open is (eventually) interpretted as a string of 8-bit characters in the current "code page". Passing a UTF-16 string to Perl's open would result in a file with a one-byte name being opened (until this crazy behavior is fixed, at which point it would die).

In some future version of Perl, it would be nice if open (and lots of other things) could handle out-of-current-code-page characters in filenames (on Win32). That would surely be provided by allowing a Perl-Unicode string to be used as a filename. Internally, perl would notice the "is UTF-8" bit on the string and then translate that string into UTF-16 and then call the alternate underlying API that expects UTF-16 strings. I've actually written code that does this as updates to Win32API::File that I really need to finish merging and testing. /:

- tye        

open uses the 8-bit ("A") API. It can't open files with names with wide characters. If it could, you'd probably pass it as a Perl string and it would encode it to UCS-2le for you, so there would be no problem.

Let try to push it for 10.0.1/5.8.10

The 5.8 branch is dead, and the 5.10 branch is in a partial code freeze in preparation for the release of 5.10.1.