best way to ensure './' is at beginning of sys.path?

Lew Pitcher lew.pitcher at digitalfreehold.ca
Sat Feb 4 14:20:05 EST 2017


On Saturday February 4 2017 13:56, in comp.lang.python, "Wildman" 
<best_lay at 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 at 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 at bitsie:~$ whoami
  guest

I'm not the root account

  guest at bitsie:~$ groups
  users audio video cdrom plugdev scanner

Nor do I have proxy root access (wheel group)

  guest at 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 at 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 at bitsie:~$ chmod a+x /tmp/dothis

Hey! I've even made the file executable

  guest at 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 at 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





More information about the Python-list mailing list