Re: Why do poisoned null attacks still work ?

Replies are listed 'Best First'.
Re^2: Why do poisoned null attacks still work ? by ikegami (Patriarch) on Jul 22, 2009 at 14:37 UTC
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.	[reply]
Re^3: Why do poisoned null attacks still work ? by Corion (Patriarch) on Jul 22, 2009 at 15:39 UTC
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.	[reply]
Re^4: Why do poisoned null attacks still work ? by ikegami (Patriarch) on Jul 22, 2009 at 17:10 UTC
what better way of opening a file do you see than asking the OS to open it? Noone denies that `open(2)` will be called. The question is what else needs to be done. If your interface and the system's differ (as they do here), you need to take steps to handle incompatibilities. Perl could try to wrap all C APIs that are known to take a C string Try? They're already wrapped. Systems calls don't know anything about scalars and Perl's stack. The problem is in the conversion from scalars to C-strings, and that occurs entirely in Perl. Besides, "it's hard to catch every instance so we shouldn't fix any instance" is a very lame argument.	[reply] [d/l]
Re^5: Why do poisoned null attacks still work ? by Corion (Patriarch) on Jul 22, 2009 at 21:24 UTC
Re^6: Why do poisoned null attacks still work ? by ikegami (Patriarch) on Jul 22, 2009 at 22:53 UTC
Some notes below your chosen depth have not been shown here
Re^2: Why do poisoned null attacks still work ? by pubnoop (Acolyte) on Jul 22, 2009 at 14:48 UTC
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 :)	[reply]
Re^3: Why do poisoned null attacks still work ? by Anonymous Monk on Jul 22, 2009 at 20:02 UTC
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.	[reply]
Re^3: Why do poisoned null attacks still work ? by JavaFan (Canon) on Jul 22, 2009 at 14:58 UTC
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.	[reply]