Bug 1016979

Summary:	python-pip: DoS by other users on the same system
Product:	[Other] Security Response	Reporter:	Ratul Gupta <ratulg>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	metherid, tflink
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-09 17:41:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1016980, 1016981
Bug Blocks:

Description Ratul Gupta 2013-10-09 05:53:28 UTC

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 05:55:13 UTC

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 17:41:31 UTC

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.