Bug 1016979 - python-pip: DoS by other users on the same system
python-pip: DoS by other users on the same system
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20131008,reported=2...
: Security
Depends On: 1016980 1016981
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-09 01:53 EDT by Ratul Gupta
Modified: 2014-01-27 03:41 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-09 13:41:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ratul Gupta 2013-10-09 01:53:28 EDT
It is found that a flaw in PIP could allow other users on the same system to DoS that system. PIP uses a non random per-user build directory in /tmp, which means that any user can prevent other user from installing packages.

There could be a --build-directory function to override this, but it was not found in the manual pages. It would be better to use the tempfile.mkdtemp() to create the build directory.

References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725847
http://osdir.com/ml/general/2013-10/msg16902.html
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1161936.html
Comment 1 Ratul Gupta 2013-10-09 01:55:13 EDT
Created python-pip tracking bugs for this issue:

Affects: fedora-all [bug 1016980]
Affects: epel-all [bug 1016981]
Comment 2 Vincent Danen 2013-10-09 13:41:31 EDT
Despite this being reported as a security flaw, I don't see it as one.  Clearly you can override the build directory, and because pip is doing these ownership checks (which is the right thing to do), it's not possible for another user to inject arbitrary code to be executed by a different user.

There is no denial of service to the system -- there is only a denial of service to a user trying to install a pip-based package.  Arguably, this "denial of service" is the right thing to do.

And it is documented (on Fedora I see no pip manpage).  The output of "pip install --help" clearly shows:

-b, --build <dir>           Directory to unpack packages into and build in. The default in a virtualenv is "<venv path>/build". The default for global installs is "<OS temp dir>/pip-build-<username>".

Also, since the package is not installed before the build, it doesn't impact any existing script functionality as they would either a) not run (the package was not installed) or b) run with an old version (this call to pip was to upgrade an existing package).

A few other notes:

- pip uses tempfile.gettempdir() which will respect the environment variable $TMPDIR (so in my case it used ~/tmp/pip-build-vdanen instead of /tmp)
- pip should check directory permissions to ensure it's not world-writable (it doesn't)
- pip should check for ownership/existence of subdirectories beneath the build directory prior to unpacking archives (it doesn't)

Even with that last, however, I don't see a security flaw as the user running pip would have had to create and/or change permissions on the top-level pip-build-USER directory first.

So it can definitely be better, but I don't see any trust boundary crossed here.  Feel free to re-open if I've missed something, but this strikes me as a non-issue as far as any security-relevance goes.

Note You need to log in before you can comment on or make changes to this bug.