Re: ./ in PATH, always bad?

[Nathan Weston <nweston@hamilton.edu>]

On Friday 13 July 2001 05:53 pm, Craig Dickson wrote:
> D-Man wrote:
> > Sure it's a "flaw" :  suppose someone creates an executable trojan in
> > "the current directory" named 'cd'.  If '.' is the first thing in the
> > path you will execute the trojan rather than the usual /bin/cd.
>
> s/cd/ls/g for a better argument. cd is a shell builtin; there is no
> /bin/cd.
>
> Having to type ./ in front of a program's name when it's in the current
> directory is pretty trivial, and when you understand the potential
> danger of having . in your path, you just don't do it ever again.
>
> Trivial example: I want a file that Joe has which he has chmodded to
> 600, i.e. he can read and write it, but nobody else can even read it. So
> I put something in my home directory that I think he'll want to see, and
> I also put a trojan script there which will copy the file for me and
> chown it to me. I create symlinks in my home directory pointing to the
> script, named "ls", "cp", "cat", and "mv". I tell Joe to look in my
> directory for the file, but "forget" to tell him its exact name (or I
> get it trivially wrong). Joe cd's to my directory and types "ls"... my
> script is executed and I get the file, all because Joe is the sort of
> guy who likes having . in his path.
>
> Of course, if he just looks in my directory without cd'ing to it, this
> won't work, but a lot of people have this interesting habit of always
> cd'ing to wherever they think something is, rather than just referencing
> it by relative or absolute directory name, so a trick like this will
> work surprisingly often once you know that someone has . in his path.
>
> Craig

Correct me if I'm wrong, but I thought that the items in the path were 
searched in order. So if your path is "/bin:/usr/bin:./", it will only search 
./ if it doesn't find the command in /bin or /usr/bin. Which means that there 
is much less danger of someone replacing a standard program with a trojan. 

Also, if we are talking about a single-user workstation, this seems like less 
of an issue, b/c someone has to crack your user account at least in order to 
do something like this. And if they crack that account, they've got access to 
all the important stuff (ie, your personal files, which can't be simply 
reinstalled) anyway.

I make no claims to be an expert (or even particularly knowledgable) when it 
comes to security, so someone please let me know if I'm entirely off base 
here.

Nathan