Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Become a Partner and License Our Database or Notification Service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Python Temporary File Bug May Let Local Users Obtain Elevated Privileges
|
|
SecurityTracker Alert ID: 1005155 |
|
CVE Reference: CAN-2002-1119
(Links to External Site)
|
Date: Aug 29 2002
|
Impact: Execution of arbitrary code via local system, Root access via local system, User access via local system
|
Fix Available: Yes
Vendor Confirmed: Yes
|
Description: A vulnerability was reported in Python. A local user may be able to execute arbitrary commands with elevated privileges.
It is reported that a local user can cause any program that uses os.execvp and os.execvpe to invoke an arbitrary program. Platforms
that support symbolic links and have predictable process IDs are reportedly affected.
A local user can create a symbolic link
from a predictable temporary filename to another file on the system, such as a malicious application of the local user's choice.
Then, when an application that uses os.execvp[e] runs, the linked file may be executed with the privileges of the calling application.
Zack
Weinberg reported this flaw.
|
Impact: A local user may be able to execute arbitrary programs on the system. The privileges that the programs would run with depends on
the privileges of the affected application that uses the vulnerable Python call. It is possible that a local user may be able to
obtain elevated privileges.
|
Solution: A patch is available in CVS:
http://www.python.org/download/
|
Vendor URL: www.python.org/ (Links to External Site)
|
Cause: State error
|
Underlying OS: Linux (Any), UNIX (Any)
|
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Thu, 29 Aug 2002 02:00:51 -0400
Subject: [Python-Dev] Weird error handling in os._execvpe
|
http://mail.python.org/pipermail/python-dev/2002-August/027229.html
On Thu, Aug 01, 2002 at 01:23:03PM -0400, Guido van Rossum wrote:
> > Can anyone explain why it is done this way?
>
> Because not all systems report the same error for this error condition
> (attempting to execute a file that doesn't exist).
That's unfortunate. The existing code is buggy on at least three
grounds:
First and most important, it's currently trivial to cause any program
that uses os.execvp[e] to invoke a program of the attacker's choice,
rather than the intended one, on any platform that supports symbolic
links and has predictable PIDs. My tempfile rewrite will make this
much harder, but still not impossible.
Second, the BeOS code will silently delete the file '/_#.# ## #.#' if
it exists, which is unlikely, but not impossible. A user who had
created such a file would certainly be surprised to discover it gone
after running an apparently-innocuous Python program.
Third, if an error other than the expected one comes back, the loop
clobbers the saved exception info and keeps going. Consider the
situation where PATH=/bin:/usr/bin, /bin/foobar exists but is not
executable by the invoking user, and /usr/bin/foobar does not exist.
The exception thrown will be 'No such file or directory', not the
expected 'Permission denied'.
Also, I'm not certain what will happen if two threads go through the
if not _notfound: block at the same time, but it could be bad,
depending on how much implicit locking there is in the interpreter.
I see three possible fixes. In order of personal preference:
1. Make os.execvp[e] just call the C library's execvp[e]; it has to
get this stuff right anyway. We are already counting on it for
execv - I would be surprised to find a system that had execv and
not execvp, as long as PATH was a meaningful concept (it isn't, for
instance, on classic MacOS).
2. Enumerate all the platform-specific errno values for this failure
mode, and check them all. On Unix, ENOENT and arguably ENOTDIR. I
don't know about others.
3. If we must do the temporary file thing, create a temporary
_directory_; we control the contents of that directory, so we can
be sure that the file name we choose does not exist. Cleanup is
messier than the other two possibilities.
zw
|
|
Go to the Top of This SecurityTracker Archive Page
|