[8940] in bugtraq
Re: PATH variable in zip-slackware 2.0.35
daemon@ATHENA.MIT.EDU (Patrick J. Volkerding)
Tue Jan 5 05:37:31 1999
Date: Mon, 4 Jan 1999 15:02:54 -0600
Reply-To: "Patrick J. Volkerding" <gonzo@RRNET.COM>
From: "Patrick J. Volkerding" <gonzo@RRNET.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.GSO.3.96.990104020718.3438E-100000@krad.tlorah.net>
On Mon, 4 Jan 1999, Rattle wrote:
> As far as I can remember, "/usr/andrew" and "." have been in the PATH
> on every version of Slackware I have ever installed. Which probably
> meants its even in pre 2.0 releases.
>
> While the presence "/usr/andrew" is (in most cases) nothing more than
> "clutter", having "." is your path is a very common mistake admins make.
> Mainly because people can be to lazy to type ./configure when installing
> packages. As previously mentioned, this can is used by the common script
> kiddie to easily make a suid shell or other 4xxx toy for himself.
>
> Many a machine has been cracked by someone inserting a script named "ls"
> in the /tmp dir.
I'm catching a bit of flamage on this one (and might change what's always
been the default), but the here are the rules I have always gone by:
1. If you tend to type without thinking at the '#' prompt, tend to input
a lot of typos, or are just really paranoid in general, you might not
want '.' in your path at all.
2. If you put '.' first in your $PATH, you are asking for trouble.
Obviously, it would need to be first for the 'ls' kiddie script in
/tmp attack mentioned above to work.
3. If you put '.' last in the $PATH, it's a minimal risk, IMHO. If you
use normal care in user-writable directories you're not likely to ever
have a problem. Attacks would depend on specific typos in specific
user-writable directories matching the filename of an attack script.
This would be extremely rare.
However, if you fall into catagory (1), you can change the default
$PATH easily. It's hardly a hidden setting.
> Also, there are hooks in various Slackware startup scripts (ie:
> /etc/rc.d/rc.inet2) to startup various daemons that are not installed by
> default. The first one that comes to mind is sshd. While this is not a
> security risk (as it only looks to the dirs "/usr/sbin" and
> "/usr/local/sbin"). I may be mistaken (Its kinda late here.. heh), but I
> can sware that it is not commented out by default. As I said, not a
> blatent security risk, but if you have sshd installed, but don't want it
> to run.. You may want to comment that out. (And if you don't use
> ssh/scp, you should..)
This is not a security risk, or any problem at all in fact. How could it
be? Only root can install things in /usr/sbin and /usr/local/sbin.
My $0.02, :)
Patrick J. Volkerding
Slackware Linux maintainer
