Re^2: use lib './' security safe?

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.

Comment on Re^2: use lib './' security safe? Download Code

Replies are listed 'Best First'.
Re^3: use lib './' security safe? by Ven'Tatsu (Deacon) on Jul 20, 2004 at 14:00 UTC
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]

Replies are listed 'Best First'.

Re^3: use lib './' security safe?
by Ven'Tatsu (Deacon) on Jul 20, 2004 at 14:00 UTC

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]