On Saturday February 4 2017 13:56, in comp.lang.python, "Wildman" <best_...@yahoo.com> wrote:
> On Sat, 04 Feb 2017 18:25:03 +0000, Grant Edwards wrote: > >> On 2017-02-04, Wildman via Python-list <python-list@python.org> wrote: >> >>> No, I do not know. You might try your question in a linux specific >>> group. Personally I don't understand the danger in having the dot >>> in the path. The './' only means the current directory. >> >> It allows a malicous user to put an evil executable someplace public >> like /tmp and have it executed accidentally. For example, let's say >> this executable file was named "sl" and placed in /tmp. >> >> ------------------------------sl------------------------------ >> #!/bin/bash >> rm -rf $HOME >> -------------------------------------------------------------- >> >> The next time you are in the /tmp directory looking for something, can >> you guess what happens when you mistype "ls" as "sl"? >> >>> DOS and Windows has searched the current directory since their >>> beginning. Is that also dangerous? >> >> Yes. > > Your scenario assumes the malicious user has root access > to be able to place a file into /tmp. It doesn't take root access to write a file to /tmp In fact, /tmp is specifically set up to allow /any/ user to create /any/ file or directory in it. Witness: guest@bitsie:~$ whoami guest I'm not the root account guest@bitsie:~$ groups users audio video cdrom plugdev scanner Nor do I have proxy root access (wheel group) guest@bitsie:~$ ls /tmp 58949ba84867f 58949bab2fe41 ksocket-lpitcher/ 58949ba87a976 gpg-15lbqc/ lost+found/ 58949ba87b6d7 kde-lpitcher/ ssh-0DwhGZKgCeHE/ That's what /tmp has in it right now guest@bitsie:~$ cat >/tmp/dothis <<EOF > #!/bin/bash > echo gotcha > EOF There. I've created a script as a file in /tmp No root access required; no special privileges at all guest@bitsie:~$ chmod a+x /tmp/dothis Hey! I've even made the file executable guest@bitsie:~$ ls -l /tmp total 120 -rw------- 1 lpitcher users 23735 Feb 3 10:03 58949ba84867f -rw------- 1 lpitcher users 23735 Feb 3 10:03 58949ba87a976 -rw------- 1 lpitcher users 23735 Feb 3 10:03 58949ba87b6d7 -rw------- 1 lpitcher users 23735 Feb 3 10:03 58949bab2fe41 -rwxr-xr-x 1 guest users 24 Feb 4 14:05 dothis* drwx------ 2 lpitcher users 4096 Feb 4 10:10 gpg-15lbqc/ drwx------ 2 lpitcher users 4096 Feb 4 13:47 kde-lpitcher/ drwx------ 2 lpitcher users 4096 Feb 4 14:01 ksocket-lpitcher/ drwx------ 2 root root 4096 Jan 10 2012 lost+found/ drwx------ 2 lpitcher users 4096 Feb 4 10:10 ssh-0DwhGZKgCeHE/ See? /tmp/dothis is an executable file, owned by guest guest@bitsie:~$ /tmp/dothis gotcha See? It is executable Now, imagine that guest had, instead, written /tmp/sl as #!/bin/bash cd $HOME rm -rf ./ and made it executable. If /tmp were part of the $PATH, and there were no other executables named "sl" found in PATH directories before the /tmp directory, then anyone making that simple typo would execute guest's /tmp/sl and lose their home directory. > And there would > have to be some reason why I would be looking around in > /tmp. If you've set your $PATH to include /tmp, then /that's/ the "reason why" you'd "be looking around in /tmp". But, this argument can be said for /any/ directory that untrusted users have write access to (including your own $HOME directory); include that directory in your $PATH, and you risk executing a trojan binary. > After 10 years of using Linux, it hasn't happened > yet. And last I would have to be a complete idiot. > > I suppose all that could be a reality, but, how many > computers do you know of have been compromised in this > manor? Probably many, especially in high-use, public or semi-restricted systems like those found in Universities, libraries, and other "public" institutions. Even corporate systems have this exposure, which is why large corporations spend a lot of money on Information Systems security. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list