Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!agate!cgd From: cgd@ocf.Berkeley.EDU (Chris G. Demetriou) Newsgroups: comp.unix.admin Subject: Re: Mysterious security hole Message-ID: Date: 12 Jun 91 00:36:02 GMT References: <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: UCB Open Computing Facility Lines: 82 In-Reply-To: SCHDAVZ@YaleVM.YCC.Yale.Edu's message of 10 Jun 91 17: 15:40 GMT In article <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: > >This probably isn't so mysterious, but the subject line has got to be zippy or >nobody'll read my post. not so mysterious...and people would probably read it...but here's a response. > >The 'login' command initializes PATH with (among other useful directories) >'.'. 'su' leaves '.' out. A footnote to a Unix book I have here hints at a >security hole involving the _position_ of '.' in PATH, claiming that having >'.' first is dangerous. It doesn't say why. Having . first in a path can in fact be dangerous... Think about how commands are found by the shell, using PATH: The shell check to see if the command is in the first directory in the path. If so, it uses it. Next, it tries the second directory listed, then the third, etc. (Note that this is a simplified explanation - for non-relative paths, the shell hashes the entries in the directory, for quick lookup... but in terms of effect, the above description suffices.) Say, for example, that PATH is set so that . comes before /bin - Also, say that someone has in a directory a shell script, executable, or whatever named the same as a common command in /bin such as, say, rm. Say that another user is wandering around, looking for interesting items, and while in the directory containing rm, they say rm ~/foofile or whatever, to get rid of one of their files (legitimately). instead of /bin/rm being executed, ./rm is, because it's in the PATH first. ./rm might, for example, create a program which is set-uid to the person who ran ./rm, or might remove all the files of the person who executed it, or whatever... you can probably see how this can cause problems for normal users. Then imagine that same situation for root, and consider that in many cases, root's PATH doesn't contain all of the standard directories that a user's PATH does. Also, consider that root occasionally has to do things in other people's accounts... All a hacker needs is a few seconds with root access to make an almost-permanent breach of security (if they know what they're doing). A hacker can create such a program to do this, and can probably position it in such a place that root and/or other users will accidentally run it, and compromise their accounts (or, for root, the system). Moral of the story: (1) root shouldn't have . in his/her PATH, and (2) users should have . as close to the end of their path as possible, if at all. cgd cgd@ocf.Berkeley.EDU OCF Staff - But these words are mine, *ALL MINE*... -- < Chris G. Demetriou | "Everybody's playing the game, > < cgd@ocf.berkeley.edu | But nobody's rules are the same. > < ...!ucbvax!ocf!cgd | Nobody's on nobody's side." - Chess > <=============================================================================> < Annoyance for hire. Name a time. Name a place. Name a target. I'm there.>