Re^2: Why do poisoned null attacks still work ?

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 :)

Comment on Re^2: Why do poisoned null attacks still work ?

Replies are listed 'Best First'.
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]