in reply to Re^4: Taint problems
in thread Taint problems

Silas,

$0 is trivial to manipulate (cp real.pl evil.pl) so I was rather horrified to see that FindBin relied on $0. Fortunately, ikegami pointed out that FindBin is tainted so I can take a deep breath and relax a bit but my off the cuff answer would be "all of them".

Replies are listed 'Best First'.
Re^6: Taint problems
by ikegami (Patriarch) on Dec 10, 2008 at 20:11 UTC
    "cp real.pl evil.pl" is not reason enough to taint $0. Copying the file isn't "evil". It doesn't get you anything. For copying to be of any consequence, it would have to copy both the owner and the setuid bit. But if you can copy the owner, you can already impersonate the owner so it doesn't buy you anything you don't already have.

      Um, yeah, bad example, I was only trying to show how easy it is to manipulate $0.

      In C it's easy to manipulate argv[0] with the exec family. There are rather more sophisticated attacks as well. I learned a long time ago that you can't trust argv[0] or names in the process table.

      In any case, $0 isn't reliable and there's plenty of reasons to taint it, even if cp isn't the reason. I do, however, feel much better knowing that FindBin isn't as unsafe as I first thought.

        I was only trying to show how easy it is to manipulate $0.

        Why are you trying to show that? Changing $0 isn't bad, as long as it points to the script being executed.

        there's plenty of reasons to taint it

        "Plenty"? I'd be interested in hearing some. I can only think of one, the ability to change the file to which the file name points after perl has read it. Mind you, that one reason is enough to warrant tainting.

        In C it's easy to manipulate argv[0] with the exec family

        Aye, for all binary executables, it's possible to execute the program will telling it it's a different file.

        That doesn't work work for script executables (such as Perl), because the interpreter must be able to locate the script to execute.