SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |    Help    |   

SecurityTracker
Archives


Welcome to SecurityTracker!
 
Click to Sign Up
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com

Sign Up!





Category:  Application (Generic)  >  Python Vendors:  Python.org
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.
Aug 29 2002 (Debian Issues Fix) Python Temporary File Bug May Let Local Users Obtain Elevated Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix.
Jan 23 2003 (Red Hat Issues Fix) Python Temporary File Bug May Let Local Users Obtain Elevated Privileges   (bugzilla@redhat.com)
Red Hat has released a fix.



 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





Home   |    View Topics   |    Search   |    Contact Us   |    Help

Copyright 2002, SecurityGlobal.net LLC