Re^8: Taint problems

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.

Comment on Re^8: Taint problems Download Code

Replies are listed 'Best First'.
Re^9: Taint problems by rowdog (Curate) on Dec 14, 2008 at 18:58 UTC
I was trying to show how easy it was to manipulate $0 because FindBin relies on it. In the "real world", no one uses FindBin just for curiosity, they use it to find related files. If I can fool FindBin, I can probably feed bogus data into the script by making it read my files instead of the owner's. Which could lead to a successful exploit. Which is why I was worried about FindBin in the first place. I agree that exec(3) alone is insufficient to exploit $0. I suppose that saying "there's plenty of reasons to taint" $0 is a bit imprecise. I agree that the challenge here is to point the filename to a different file but there are multiple attack vectors which might work (gaming the filesytem, a private, hacked, perl executable, doing "exec" without exec(3), etc). So, yes, one reason, but a number of ways to attack. On reflection, my opinion is that tainting is insufficient and relying on $0 (and thus FindBin) for anything is likely to be insecure. Usually, people untaint by pattern matching for allowed characters and a usefully bogus $0 could probably slip through. I don't really have the time or desire to work out the attacks on FindBin when I can just hardwire my paths and be sure. Just FYI, I used to wear a white hat but I've been out of the game for a number of years and my memory is not so great anymore, so I could easily be wrong about everything.	[reply]
Re^10: Taint problems by ikegami (Patriarch) on Dec 14, 2008 at 22:30 UTC
In the "real world", no one uses FindBin just for curiosity, they use it to find related files. If I can fool FindBin, I can probably feed bogus data into the script by making it read my files instead of the owner's. Please show me how you can fool $0 so that it finds the wrong files. You mentioned copying the script, but that doesn't fool the script into looking in the wrong spot. Installing the program in a different directory is not "fooling $0". Remember, if the user can copy the script, then he can modify the script. And if he can modify the script, it doesn't matter if you can trust `$0` or not. You don't worry about allergies when someone's pointing a gun at you. hacked perl executable doing "exec" without exec(3) Same thing goes for `perl`, the OS and the hardware. If the attacker can overtake these, it doesn't matter if $0 can be trusted or not. The attacker can already do everything he wants. but there are multiple attack vectors which might work Again, like what? So far, you've only mentioned the one I came up with (gaming the file system). On reflection, my opinion is that tainting is insufficient and relying on $0 (and thus FindBin) for anything is likely to be insecure. How can tainting `$0` be insufficient (which means it IS insecure) if you're content with considering `$0` as LIKELY to be insecure?	[reply] [d/l] [select]