Bugs item #1284316, was opened at 2005-09-07 17:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Mika Eloranta (mel)
Assigned to: Martin v. Löwis (loewis)
Summary: Win32: Security problem with default installation directory
Initial Comment:
(Sorry, this is a bit long since the issue is not
entirely trivial.)
This problem only exists on Windows operating systems
installed on an NTFS file system. Confirmed on several
Windows 2000, XP and Windows 2003 Server systems. All
Python versions (at least 2.x) are affected.
The default installation target directory where Python
is installation on Windows is directly under the system
drive's root directory (e.g. "C:\python24"). The file
and directory permissions inherited by the
python24-directory from the root directory are not
secure enough for keeping application binaries.
Microsoft has, in their infinite wisdom, decided that
the root directory of the system drive should allow
regular (non-admin) users to create directories and
files there. This set of permissions is inherited by
the python directory when it is created in the default
location (i.e. "C:\python24" or whatever).
This "feature" allows a regular (non-admin) user to
perform a priviledge escalation attack for example in
the following manner:
1. Figure out the name of some DLL python (or some
extension .PYD) loads using LoadLibrary() without an
absolute path.
2. Copy a DLL with the same name into the
python-directory (this should not be allowed, but it
is!) containing some code the attacker wants to run
with escalated priviledges.
3. Wait until python is run by an admin in the same
machine or by the LocalSystem account.
How to view the problematic part of the ACL:
1. Right-click the "C:\python24" directory in Windows
Explorer
2. select Properties... -> Security -> Advanced
3. In the "Permissions" tab you will see an entry for
the "Users" group, it says "Special" in the
"Permissions" column
4. Select the above entry and click "Edit..."
5. Well hidden? I think so, too.
The fix:
The proper (default) location where application
binaries should be installed is under the "c:\program
files\" directory. This directory has properly set
permissions by default.
PS. The same problem exists in ActivePerl, Ruby and
many other tools.
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2006-03-22 15:27
Message:
Logged In: YES
user_id=31435
A long time ago, Python did install (by default) under
"Program Files". I changed that, because of the endless
problems created by the frickin' embedded space, and rarer
but subtler problems due to "Program Files" not being a
DOSish 8.3 name. Overall I still think it was a good change.
Note that, unlike most Windows applications (which are
GUI-based), programming languages are _intended_ to be used
heavily from the command line, invoked by scripts, and so
on. That's what makes a space in the path endlessly
error-prone. In WinXP Pro, I noticed that MS was still
careful to put its own command-line/script tools (sort.exe,
ipconfig.exe, cscript.exe, ..., even notepad.exe) under pure
DOSish 8.3 space-free paths ;-)
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2006-03-22 14:09
Message:
Logged In: YES
user_id=21627
I completely disagree. It was wrong to give the system
default binary directory a name with a space in it, on a
system that doesn't provide command line argument vectors in
its standard API.
----------------------------------------------------------------------
Comment By: Mika Eloranta (mel)
Date: 2005-11-19 03:46
Message:
Logged In: YES
user_id=109057
Wow, even easy_install.exe from setuptools fails if python
is installed under "c:\program files":
C:\temp>easy_install
C:\program: can't open file 'files\Python24\python.exe':
[Errno 2] No such file or directory
IMHO the root cause to all these problems is the wrong
default installation directory. If the installation
directory would conform to Windows guidelines, these kind of
problems would have been easily spotted by python library
developers.
- Mika
----------------------------------------------------------------------
Comment By: Mika Eloranta (mel)
Date: 2005-11-15 06:39
Message:
Logged In: YES
user_id=109057
Please consider these points as well:
* The "program files" directory has "sensible" ACLs set by
default (the defaults are different in different OS
versions). If you install your application under "program
files", you do not need to worry about the permissions.
* The installation directory can be added to the PATH
environment variable instead of typing it every time from
console...
* The current default installation directory is teaching
python library developers bad habits of not handling Python
installed into a directory that contains spaces properly. It
is actually a miracle to find a third party library that
installs a working script (batch file) to "python/scripts"
if the python directory contains spaces.
* The "program files" directory is the standard location
where applications should be installed in Windows. This is
what Microsoft requires in their guidelines and most
applications obey them. You would not install python to
"/python24" by default in Unix would you?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-10-08 05:48
Message:
Logged In: YES
user_id=21627
I disagree that the default location of Python should be
c:\Program Files. The Python interpreter's path name is
often typed into a terminal, batch file, etc., so it needs
to be convenient to type.
I agree that the permissions are problematic; the proper
solution would be to give c:\python24 more restrictive
permissions. You can do this yourself: in the security tab,
edit the permission. In "Advanced", unselect the "Inherit
permission" checkbox, and choose "copy" when asked. Then
edit the permissions to your liking.
I can consider supporting such permission setting during
installation in the future - an invocation of cacls.exe
should do.
Notice that this is an incompatible change: as currently all
users can create files in the tree, the .pyc files are often
not created during installation, but on first use. If write
permissions are denied, normal users could not cause .pyc
creation anymore, causing increased startup costs unless the
.pyc files are created during installation.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 02:26
Message:
Logged In: YES
user_id=33168
Martin, do you know anything about this? (Sorry, don't know
who else might know.)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
