in reply to Why do poisoned null attacks still work ?

A couple of things:
  • Comment on 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 15:13 UTC

    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?

[reply]
[d/l]
[select]
      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.

[reply]
[d/l]

        Just an FYI for everyone, I dug through Perl's RT and found a ticket on the issue. Every comment from P5P implies it's not a bug, but officially the ticket is still open.

[reply]
Re^2: Why do poisoned null attacks still work ?
by pubnoop (Acolyte) on Jul 22, 2009 at 15:13 UTC

    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

[reply]
      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.
[reply]
        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.

        In this specific case, there is a test that a filename including the cookie string exists before the eval. Poisoned null on the stat call allows that test to be fooled. Without the poisoned null trick, only existing directory names can be shoved into the string to be evaled, making the exploit harder and maybe impossible in some cases.

        I bet there are more scripts out there that are currently exploitable due to poisoned null. Wouldn't it be nice (from the web hoster's point of view) for those vulnerabilities to vanish the next time the hoster upgrades Perl ?

[reply]

In Section Seekers of Perl Wisdom