in reply to Re^2: pack() untaints data : bug or undocumented Perl 5.10 feature?
in thread pack() untaints data : bug or undocumented Perl 5.10 feature?

Seems to be a storm in a teacup to me too. Given that I can untaint input using 

echo print 'Some piece of nasty code'|perl -Tne"m[(.+)];$_=$1;eval;"
Some piece of nasty code

[download]

I don't see any additional risk by allowing my $untainted = unpack 'A*', $tainted;.

Nor any lesser risk by not allowing it.

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: pack() untaints data : bug or undocumented Perl 5.10 feature?
by mr_mischief (Monsignor) on Apr 07, 2008 at 14:01 UTC
    In an abstract world where we didn't have a prior version, you'd be right. People would just know to untaint before using pack() or unpack() instead of after, and they'd do that.

    As it is, perlsec says that only by using a regex or by making the scalar a hash key can you untaint it. The behavior of pack "a*", $val and pack "A*", $val used to leave the value tainted. Now it does not.

    There is probably code somewhere that takes advantage of that fact, and under 5.10.0 that code is now less secure.

[reply]
[d/l]
[select]
      There is probably code somewhere that takes advantage of that fact, and under 5.10.0 that code is now less secure.

      So, someone, somewhere might be unpacking a tainted string and relying upon the resultants continued tainted status to prevent them from ... ?

      I agree that departure from the documented behaviour is not good, but I would be a little leary about labelling it as a "security risk".

      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]
        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]

In Section Meditations