in reply to Re^2: Why do poisoned null attacks still work ?
in thread Why do poisoned null attacks still work ?

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.

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

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

      As (the string parts of) Perl scalars always are terminated with a \0, I doubt that there is much conversion happening at the interface between Perl and the C library. But as Taint will catch this and other errors, I don't see why there should be another system.

[reply]
[d/l]
        They're not always. While places that omit the trailing NUL tend to get fixed, it's also considered a bug to expect it to be present from what I've seen.
[reply]

In Section Seekers of Perl Wisdom