Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

use lib './' security safe?

by SavannahLion (Pilgrim)
on Jul 20, 2004 at 02:30 UTC ( [id://375765] : perlquestion . print w/replies, xml ) Need Help??

SavannahLion has asked for the wisdom of the Perl Monks concerning the following question:

While creating a new custom module that needs to be installed alongside its parent script, I realized that I didn't know if declaring:
use lib './';
is actually a wise thing to do.

I checked the Llama and the Mouse but I didn't find any mention of any security risk. So I ask this. Is there a potential security risk to specifying the local directory into @INC that I should be aware of?

I noticed that @INC apparently doesn't specify the local directory by default, so I figure there's probably some compelling reason for it not to.

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

Replies are listed 'Best First'.
Re: use lib './' security safe?
by PodMaster (Abbot) on Jul 20, 2004 at 06:22 UTC
    Turning taint on removes "." from "@INC".
    C:\>perl -le"print for @INC" c:/Perl/lib c:/Perl/site/lib . C:\>perl -Tle"print for @INC" c:/Perl/lib c:/Perl/site/lib C:\>

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      After reading your little blurb, I went back and looked at my configuration files for my editor. I configured three different Perl launch options. The primary one I've been using for testing/checking my scripts straight from the editor has -wT (it launches Perl from a command prompt). When I run the script via Apache, I've been leaving off -wT.

      I think I did it this way because a problem I can't figure out is when I run the script from my editor, Perl balks at having #!perl -T. Perl claims declaring -T is too late. But that line works fine with Apache. I'd configure Apache to include -T automatically (if it was possible), but the production server doesn't have Perl configured that way. Oh well.

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

Re: use lib './' security safe?
by beable (Friar) on Jul 20, 2004 at 03:28 UTC
    Are you sure that @INC doesn't include the current directory? I ran this program, and "." was at the end of the array:
    perl -e 'print "@INC\n"'
Re: use lib './' security safe?
by SavannahLion (Pilgrim) on Jul 20, 2004 at 05:09 UTC
    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

      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 "./";
      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.

        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.

Re: use lib './' security safe?
by ercparker (Hermit) on Jul 20, 2004 at 03:41 UTC
    on most systems I've seen, "." is included in @INC
    I checked the following :
    • FreeBSD 5.0 (perl v5.8.0)
    • Darwin(perl v5.8.1)
    • Redhat (perl v5.8.3)
    Each of these have current dir included in @INC
    unshift(@INC, "./");
    perldoc lib
    I don't know of any security issues that would cause
      unshift would be bad. That puts "./" at the start of the search list, which means standard module names could be overridden by placing bogus ones in the CWD.
      push @INC,"./";
      Better, but it isn't going to affect use statements, since those are evaluated at compile time. So,
      use lib "./";
      is even better.
      But best is:
      use lib /some/absolute/path/that/you/control;
      Update: use lib "./" is worse than unshift @INC,"./" because it also prepends "./" to the search path, but does so at compile time, where it can affect other use statements.
Re: use lib './' security safe?
by dave_the_m (Monsignor) on Jul 20, 2004 at 14:14 UTC
    Having '.' in @INC is moderately dangerous. For example, consider a script that did something like
    BEGIN { eval { require "Some::Optional::Module" } }
    If you can persuade someone (preferably root) to run that script in a directory you have control of, on a system whose Perl installation doesn't have Some::Optional::Module, then bingo!

    Dave.

Re: use lib './' security safe?
by hbo (Monk) on Jul 20, 2004 at 03:58 UTC
    According to the 3rd Blue Camel, "." should be in the default @INC, so adding it shouldn't be necessary for 5.6 and before. However, my Perl 5.8.1 shows this:
    hbo@owen|1347> perl -e 'print join "\n",@INC' /usr/lib/perl5/5.8.1/i686-linux /usr/lib/perl5/5.8.1 /usr/lib/perl5/site_perl/5.8.1/i686-linux /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl
    So it appears that the default has changed for 5.8, which came out after the last edition of Programming Perl.
    Update: This is wrong. See beable's correction below.

    Since use et al take the first match, there shouldn't be a danger of loading a bogus standard module if you have "."at the end of @INC. It's similar to having "./" at the end of your Unix PATH, however, in that what "./" means changes with your CWD. This opens up a possibility of loading a non-standard module that you don't expect. If you have root, (or administrator for *ix challenged) it's good practise to install your modules in the site_perl directories.

    For my personal software, I create and use a ~/lib/perl and include the following at the top of my scripts:

    use lib /path/to/my/home/lib/perl;
    That way I avoid the pesky relative path.
      Are you sure you didn't miss the dot on the end? Please run this: perl -e 'print join "\n",@INC,"\n"'
        Yup, you are correct. The "." appeared at the beginning of my prompt on the next line and I missed it.