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