Relying on the tainted state of anything is less secure than being certain to clean it properly. Taint mode is a safety net, and now there's an undocumented hole in the net.
This might not be a common issue, but someone somewhere might get bit by it. It only takes one vocal person who gets bit by it to further the "Perl is insecure" meme, no matter that it's the safety net he was counting on that failed.
More philosophically, if the docs and tutorials are going to tout Taint mode as a general tool for improving security, then the security docs covering that should be very accurate and precise. That someone gets burned by following directions about the enhanced security layer offered by a broadly recommended module is just a bad way for an application's security to fail.
You might take issue with Taint.pm being widely suggested as a security improvement, but I think it would be hard to argue that isn't the case. So long as it is promoted, it should provide at least what the docs specifically say it does.
| [reply] |
I'll try a different tack. In order for this to be more than a documentation problem, a piece of < 5.10 code that works correctly, would have to fail when run on 5.10.
So, let's try and construct a piece of code that would meet that criteria.
- We need a piece of tainted data:
my $tainted = <STDIN>;
- Next, we need to pack that data:
my $stillTainted = pack 'a*', $tainted;
- Finally, we need to use the still tainted data to do something that would have rejected it:
open my $fh, '>', $stillTainted or die $!;
And there's the problem. With < 5.10, that will always fail with Insecure dependency in open while running with -T switch ..., because they never did anything to untaint it. And any usage that wouldn't fail under < 5.10, still won't fail (and will still be secure) under 5.10.
The above sequence wouldn't fail under 5.10, but the problem only affects new code, and that can be addressed by a documentation change (if that's the right way to go), rather than a code change.
My point was that it doesn't make any existing (pre-5.10) code that works, less secure when that code is moved to 5.10, because if it worked securly pre-5.10, it'll still work securely.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
I think I see the assumptions you're making that I'm not.
I though you were assuming only new code is run under new versions of the language system. You address that here, though.
Your other assumption is that "working properly" under 5.8.8 doesn't include failing with a Taint warning when a piece of tainted data makes it somewhere that matters. I think that's exactly proper, because the scalar that finally gets used for a file open or somesuch might have had its value assigned from different places based on different conditions. Remember that the taintedness follows the scalar value and not the variable.
if ( 1 == $x ) {
... # $y cleaned
} else {
... # $y not cleaned
$y = pack "A*", $y;
if ( tainted( $y ) ) {
$y =~ s/[;\\'"\*]//g;
}
}
open my $file, '<', $y;
Yes, there are probably better ways that could've been written. However, pushing Taint.pm as a safety net means that perfectly written software isn't its target anyway.
| [reply]
[d/l] |