in reply to Insecure dependency in open

Probably one of the components of the filename passed as an argument to open is tainted. Untaint it (carefully) and it should work; if it doesn't, post your open statement, and the statements that assigned to any variables that are used in the open string. Or better yet, create a minimal test case, which will probably help you in figuring out what's going on. You can use Scalar::Util::tainted to see what's getting tainted, and you should probably also read perlsec to understand what rules Perl enforces when running in taint mode.

As others have mentioned, Perl automatically runs in taint mode when it is setuid or setgid. That is almost always the right thing to do, but if you don't like it, you can always recompile your copy of Perl with that code commented out. You could also blindly untaint all of your data, run your program under sudo instead of making it setgid, or write a wrapper program which sets up the GIDs then exec's a copy of the real program, which if you're careful will not be running in taint mode.


--
sgifford's Web page

Replies are listed 'Best First'.
Re^2: Insecure dependency in open
by argv (Pilgrim) on Jan 22, 2007 at 05:02 UTC
    well, after a lot of tests of different conditions, there are many permutations that have unearthed themselves that I wasn't aware of. Namely, using the Scalar::Util suggestion from sgifford, it turns out that the filename used was derived from an environment variable, which caused the taint. The fact that it was a symlink owned by root turns out to have been a red herring, and irrelevant to the problem. I can't say I'd have figured this out without having used the tainted() function from the Util package.

    Now that all the sleuthing has been done to determine exactly "why" the filename was tainted, I can program around it accordingly. I'm still feeling residual commitment to my statement that perl needs some programmatic way around this sort of thing, but I'm not exactly sure what that would look like... In principle, I like having the protection for basic stuff, but I also want all that rope to hang myself, should I choose to do so. :-|

    Dan Heller
    http://www.danheller.com
[reply]
[d/l]
      This is when taint mode is at its most useful: you didn't realize that the security of your program depended in part on an environment variable, Perl noticed that it did, and stopped the program before it did something that might be dangerous. It forced you to find the dependency, think about whether it's a real security problem or not, and then deal with it appropriately.

      If there had been an easy way to turn off taint mode, you most likely would have turned it off based on your faulty assumptions about the problem coming from symlink ownership. Instead, you found a possible bug you didn't know about, and probably made your program more secure.

      And the world is safe again. TaintMode++.


      --
      sgifford's Web page
[reply]
        Furthermore, if a perl script could turn off the taint mode, then any bug in the script could be exploited to take advantage of it. "Hey, he turns off taint checking in line 93 so he can open through a symlink... that gives me an idea!"

        --
        [ e d @ h a l l e y . c c ]

[reply]
        Ok, then can you please clarify why STDIN is tainted? I'm scratchin' my head long and hard on this one? What's perl protecting me from now?

        Dan Heller
        http://www.danheller.com
[reply]
      A wise man once said you can find the rope if you RTFM.
[reply]

In Section Seekers of Perl Wisdom