Re^3: Insecure dependency in open

I've reread the postings till now twice, but I haven't seen one important bit mentioned yet. You have repeatedly said you didn't set -T and that you have also played with trying to 'matchup' the $EUID $UID values to 'satisfy' Perl. But... it doesn't work that way.

You have obviously read the perldiag section:

The tainting mechanism is turned on when you're running setuid or setgid, or when you specify -T to turn it on explicitly.

However I don't think you understood the timing. When perl starts it notices the mismatch in uid/gid values and at that point turns on taint mode. And barring magic, taint mode stays on from the start of the program onwards. You can't turn off taint mode just by un-mismatching the uid/gid values.

Start a perl program in setuid mode and you get taint mode for free. You didn't have to ask for it, but perl wants to protect you from yourself. This only sank in the most recent time I did it to myself. So then I went off and did the untainting manipulations needed to 'clean' the data, because the program _might_ be run in taint mode, depending on the conditions when starting it.

Comment on Re^3: Insecure dependency in open

Replies are listed 'Best First'.
Re^4: Insecure dependency in open by argv (Pilgrim) on Jan 22, 2007 at 02:32 UTC
My original post said that the program is setgid, not setuid. For slightly more context, the application in this case is a shell-like interpreter that is sgid so it can read/write data out of a common file shared by other users of the app. It happens to let you run shell commands, but (and here's where I'm uncertain), it doesn't setgid back to your real gid when it forks. I'll have to look into why this is the case. But, that aside for the moment: The real issue for me is perl's decision about what to protect. It's true that if I'm opening a file that's owned by ME, even if taint is on, then perl doesn't complain. However, if I open a symlink to exactly that same file (even if the symlink is owned by someone else), I would say that it still shouldn't complain... but it does, leaving me with no possible way to open that file for writing. I may not know (or even care) what that symlink points to, if I say "open '>filename'" I want it to open, truncate and return me a filehandle, so long as the OS gives its blessing. If I had a handle to the file, I could call `FH->untaint()`, but I can't get a handle because perl won't let me open it for writing in the first place. I realize I could examine the file to see if it's a symlink, follow to where it goes, and then do the open call, but frankly, that's what perl should be doing before it decides to bar me from having access. What mechanism do I have at my disposal? And more importantly, what mechanisms does perl provide to anyone using similar conditions? Please don't suggest having a wrapper application that resets my gid, because that won't address potentially more complicated perl apps and modules that may not have that option. I'd like to see a perl-based programmatic api for dealing with this sort of thing. I think it'd be best to just have a new form of "no taint"-type of option with appropriate params that doesn't cause previously documented behaviors to break. I'd even accept a new param for sysopen() to get around this. I don't want to dismiss how nice it is for perl to keep you from hurting yourself when using the basic, straight-up simple API of perl, but having very specific mechanisms to get around such protections is also part of the spirit of perl. Dan Heller http://www.danheller.com	[reply] [d/l]
Re^5: Insecure dependency in open by shmem (Chancellor) on Jan 22, 2007 at 08:29 UTC
Easiest way to fix that symlink stuff is `$file = readlink($file) if -l $file;` [download] Don't fight your tools. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply] [d/l]


Keep It Simple, Stupid
	PerlMonks