Author mel
Recipients
Date 2005-09-07.21:34:44
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
(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.
History
Date User Action Args
2007-08-23 14:34:21adminlinkissue1284316 messages
2007-08-23 14:34:21admincreate