Re: question on having . as LOAD_PATH (ruby)

2006-01-07 Thread Junichi Uekawa
Hi perl and pyhton people,

Sorry for the crosspost; contrary to what's said in perl-policy and
python-policy, '.' seems to be included in module search-path.  I find
it uneasy considering we have quite a few tools running as root. Is
this intentional or unintentional?

regards,
junichi



The following is a full posting I made to debian-security@lists.debian.org:

At Sat, 07 Jan 2006 21:44:24 +0900,
Junichi Uekawa wrote:
> 
> Hi,
> 
> > > Hi,
> > > 
> > > I am wondering what the security implications of having a LOAD_PATH
> > > that includes '.' is.
> > 
> > Gerenally speaking, having . in any path is a bad idea.  You are correct
> > to feel uneasy about it.  Can . not be prepended to the path
> > specifically if desired (as in the shell PATH=.:$PATH)?  If it can, I
> > would suggest a bug filed for removal of . in path, with a README entry
> > detailing how to readd it if you want it.
> 
> Somebody in @jp pointed out to me that perl and python are not much 
> better in this respect, since perl and python do have '.' in their 
> load paths; of course, if @INC is handled properly, it wouldn't be a threat.
> 
> 
> Example of a perl session:
> $ perl -e 'print "@INC\n"'
> /etc/perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 
> /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 
> /usr/local/lib/site_perl .
> 
> 
> 
> [12:50:30]dancer64:tmp> cat a.pl
> #!/usr/bin/perl -w
> 
> BEGIN {
> eval qq {
> use  ;
> };
> if ($@)
> {
>  print STDERR "feature  not available\n" ;
> }
> }
> [12:50:34]dancer64:tmp> ./a.pl
> feature  not available
> 
> If I have:
> [21:42:25]dancer64:tmp> cat .pm
> print "r00t!!\n";
> 1;
> [21:42:29]dancer64:tmp> ./a.pl
> r00t!!
> 
> 
> 
> I haven't been able to verify I can exploit it with python, since it seems to 
> be changing behavior when it's not executed as ./XXX:
> 
> [12:39:00]dancer64:tmp> apt-listchanges
> Usage: apt-listchanges [options] {--apt | filename.deb ...}
> [12:39:33]dancer64:tmp> /usr/bin/apt-listchanges
> Usage: apt-listchanges [options] {--apt | filename.deb ...}
> [12:39:08]dancer64:tmp> cp /usr/bin/apt-listchanges .
> [12:39:08]dancer64:tmp> ./apt-listchanges
> hello r00t
> 
> hello r00t
> 
> Traceback (most recent call last):
>   File "./apt-listchanges", line 218, in ?
> main()
>   File "./apt-listchanges", line 44, in main
> config = apt_listchanges.Config()
> AttributeError: 'module' object has no attribute 'Config'
> 
> 
> [12:39:10]dancer64:tmp> cat apt_listchanges.py
> print "hello r00t\n"
> 
> [12:39:23]dancer64:tmp> cat apt_pkg.py
> print "hello r00t\n"
> 
> 
> regards,
>   junichi
> 
> -- 
> [EMAIL PROTECTED],netfort.gr.jp}   Debian Project
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: question on having . as LOAD_PATH (ruby)

2006-01-07 Thread Florian Weimer
* Junichi Uekawa:

> Hi perl and pyhton people,
>
> Sorry for the crosspost; contrary to what's said in perl-policy and
> python-policy, '.' seems to be included in module search-path.  I find
> it uneasy considering we have quite a few tools running as root. Is
> this intentional or unintentional?

One more data point: when running with taint checks enabled, perl
drops "." from the library path.  So it seems it's not directly
exploitable with suidperl (unless suidperl invokes further perl
scripts without changing the current directory).

I consider this a security bug, but fixing it (by removing the current
directory from the load path) requires *extensive* testing and will
likely break existing installations. 8-(


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: question on having . as LOAD_PATH (ruby)

2006-01-07 Thread Thomas Viehmann
Junichi Uekawa wrote:
> Sorry for the crosspost; contrary to what's said in perl-policy and
> python-policy, '.' seems to be included in module search-path.  I find
> it uneasy considering we have quite a few tools running as root. Is
> this intentional or unintentional?
It doesn't seem to be the case here. The directory of the script
executed is in the path, but not '.', this looks like it should be expected.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Pixels That Rock

2006-01-07 Thread Dan
Sorry for the previous blank email. I saw your name and email address on a
website and thought you might be interested in taking a look at my new site.

www.pixelsthatrock.com 

If you are interested in trading links or something let me know. Thanks!

- Dan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]