in reply to use lib './' security safe?

After reading the responses here. I went back to the Windows box I'm using (my Linux test box has been offline for almost two years now :( ). Yeah, . is indeed at the end of that list.

So I went back and removed the lib "./" decleration. And voila! My problem didn't come back. Ggrrrrrr!

I have no idea what was wrong before. Nor why I can't recreate the problem at this hour. I'm tired, I'm going to bed. This has been a horrible day for me. I spent all day fussing with existing flaky code and none actually writing new code. Might be time to repair the Linux box and get it running again.

So I guess the answer to my question: There is probably minimal security risk, it's there by default. Though I concure with hbo that I feel more comfortable with an absolute path. I just hate changing path information when I move the script from the Windows box to the UNIX box. Howver, I don't think I agree with him about . being a security risk with bogus modules place in the CWD. If someone breaks into the system and is able to place bogus modules in the CWD, I seriously doubt that not having . in the @INC would make any sort of difference. That's just my thinking though. I could be way wrong about that logic train.

----
Thanks for your patience.
Prove your knowledge @ HLPD

Replies are listed 'Best First'.
Re^2: use lib './' security safe?
by hbo (Monk) on Jul 20, 2004 at 05:24 UTC
    Sorry you had an unproductive day. I've had a few like that myself.

    After correcting myself and being corrected by others, I beg to differ slightly with your final conclusion. 

      use lib "./";

    [download]
    actually does have security implications. If "./" is first in the module searh list, then a file called,for example, "CGI.pm," in the directory your script runs in, would alter the effect a use CGI; directive would have, if it appeared after the first use statement. In other words, you could be vulnerable to a trojan horse attack.

    Of course, since "./" appears in the load path by default after all the other paths, this danger is considerably lessened. But for myself, I still dislike relying on a relative path to load code. When you don't have absolute control of the working directory your script will run from, it's better to use absolute paths for security's sake.

[reply]
[d/l]

      I don't think that '.' in @INC is a security risk in the same way as '.' in $ENV{PATH} would be.

      With PATH there is a risk of root cd'ing into a directory and running a trojaned ls compromising the system. An attacker might have write access to their home directory, which would be expected (under the assumption that the attacker is an authorised user)

      With @INC if the attacker can write a trojaned CGI.pm then they would have write access to the directory, and the could just as easily unlink the script it self and replace it with a trojaned version.

      Correct me if I'm missing something.

[reply]

In Section Seekers of Perl Wisdom