virtualenv Sandbox escape

[BakedPotato999]

Exploit Title: virtualenv Sandbox escape
Date: 2018-9-30
Exploit Author: Topsec Technologies Inc. - vr_system
Version: 16.0.0
Tested on: kali linux
CVE : None

root@kali:~#pip install virtualenv
root@kali:~#virtualenv test_env
root@kali:~#cd test_env/
root@kali:~/test_env#source ./bin/activate
(test_env) root@kali:~/test_env#`
`2、Sandbox escape
(test_env) root@kali:~/test_env#python $(bash >&2)
root@kali:~#
(test_env) root@kali:~/test_env#python $(rbash >&2)
root@kali:~#```

[fgeek]

CVE-2018-17793 has been assigned to this issue (not requested by me).

[Brcrwilliams]

Could you please explain the security impact here? Calling bash to get back to the normal shell does not seem like a vulnerability to me. I do not think that anyone was under the impression that virtualenv allows you to safely run untrusted shell commands, that is not what it is for.

[jsegitz]

I asked MITRE to reject the CVE

[BakedPotato999]

Normal as follows:
(test_env) r0ot#python $(sh 1>&2)
(test_env) r0ot#
(test_env) r0ot#python
Python 2.7.15 (default, May 1 2018, 05:55:50)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import os
os.system("$(sh 1>&2)")
(test_env) r0ot#
If you execute malicious code:
(test_env) r0ot#python $(bash >&2)
r0ot#
POC:
(test_env) r0ot#python
Python 2.7.15 (default, May 1 2018, 05:55:50)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import os
os.system("$(bash >&2)")
r0ot#

[Brcrwilliams]

If you execute malicious code

Yes, and if you jump off a building you might hit something on the way down. It doesn't really matter since you're already in big trouble from jumping to begin with.

[BakedPotato999]

PYTHON in the sandbox is not 100% secure, and vulnerabilities can result in bypassing the sandbox protection. What are the reasons for using the sandbox?
If the sandbox is difficult to fix, it is recommended to avoid risk in the code and be prompted in the sandbox description.

[0cjs]

@BakedPotato999 Python in the virtualenv "sandbox" is 0% secure; it's neither designed to nor does it provide any protection against malicious code. You seem very confused about the purpose of virtualenv.

[BakedPotato999]

@BakedPotato999 Python in the virtualenv "sandbox" is 0% secure; it's neither designed to nor does it provide any protection against malicious code. You seem very confused about the purpose of virtualenv.

I think the applications running in this Virtualenv are independent and will not affect your existing operating system. Closing the sandbox will restore all operations. With the sandbox, you can test programs and software that might be risky. Is that right?

[0cjs]

Nope, completely wrong. The purpose of a virtualenv is to let you use a specific Python interpreter and set of Python packages (instead of the system- and userdir-installed packages) to run programs in an otherwise normal environment.

The "sandbox," such as it is, should by default not include system and user packages, just the ones installed in the virtualenv. But there's nothing stopping you from, e.g., changing sys.path to bring back in default system or user packages.

Nor should anything stop you from doing that. The Python interpreter in a virtualenv should be able to do all operations that the system Python interpreter (if any) can do when run by the same user. To do otherwise would break many common and expected uses of a virtualenv.

[zoidyzoidzoid]

@BakedPotato999 virtualenv/bin/activate basically just puts the Python executable in the virtual environment earlier in your path. It's not built for security.

[gaborbernat]

I'll close this as invalid.

[disconnect3d]

I just wonder, how did you come with virtualenv being a sandbox @BakedPotato999 ?

I searched through docs, github and with a git grep and the only sandbox occurence is this one:

James Gardner has written a tutorial on using virtualenv with Pylons.

which links to http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox (which has sandbox in the url).

By the way, the url is dead and it is here https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;).

[offlinehacker]

The fact that there exists "exploit" now https://www.exploit-db.com/exploits/45528/ and that security trackers of major distros treat this as vulunerability is rather funny.

[Ekultek]

I guess we might be able to use this as a privilege escalation, I’m going to try it actually

[Ekultek]

0day confirmed! :D

[0cjs]

Very amusing, ha ha and all that, but given that a CVE has been created for this and several other trackers are also listing it, it's now reaching the point of wasting significant time that should be spent on real security issues, in other words, we now do have a sort of DoS on our security infrastructure. So let's put this to bed now please: this "sandbox escape" is not a vulnerability.

[Ekultek]

@0cjs I just proved it can be used to gain root access, how is that not a vulnerability?

[0cjs]

1. I cannot see evidence in your screenshot that you used anything related to virtualenv to gain root access. It's a little suspicious that it's mentioning what appears to be a Ruby Version Manager installation in root's home dir there, too, though there are explanations for that compatible with a real exploit.
2. I cannot think of a plausible mechanism for doing what you did outside of exploiting something outside of virtualenv, since virtualenv has no and uses no suid or similar files, nor at any point does it assume privileges of any user other than the one running it. (I'm not saying that the mechanism doesn't exist, but you need to provide at least some indication of where this problem might be. If you've reported it responsibly, you need to say so, and to whom you've reported it.)

One plausible explanation for the above is that the blanked-out lines in your screenshot include sudo -s and a password prompt. That, along with a partially-removed RVM installation for the root user, would produce exactly that output, without exploiting anything at all.

[Ekultek]

@0cjs I actually blanked it out because it worked, I’m still testing to ensure it wasn’t because of my outdated system, I’m actually in agreement that it was a different kernel exploit that happened to show itself within virtualenv, once again testing still.

[0cjs]

Well, you should confirm things a little more before you report tools that, by design, allow you to run arbitrary programs and code as the current user. Reporting this as a virtualenv vulnerability makes about as much sense as reporting it as a Bash vulnerability because you also used Bash above, or a GCC vulnerability because it was used to compile some code you ran at some point.

[Ekultek]

I didn’t report anything...?

[Margaruga]

root@kali:~/test_env#python $(bash >&2)

Wow, that's nice, but you don't really need to use $()...you could just...

root@kali:~/test_env#echo "this is quackery"

to "bypass" the virtualenv sandboxing mechanisms.

[Ivoz]

@BakedPotato999 you managed to get from executing arbitary python (or other) code as root... to executing arbitrary python (or other) code as root. What do you suggest is security problem that pops up from the former situation to the latter?

[ghost]

Woah, what a serious issue. How can I use software meant to do one thing if it can not securely do some thing else? Please advise.

[gbougakov]

@Ednix liveoverflow?

[0cjs]

@Ednix You can't. You must never use a Unix shell again because it can't be securely used for some purposes.

[valknight]

In fact, let's never use computers again. Dangerous things they are, they can be used for many purposes.

[ssbarnea]

In fact this "issue" reminded me that it may be possible to use for addressing #1334 - does anyone has some POC code that we can start with?

[bac]

Nexus by Sonatype provides a proxy for pypi.org. The proxy allows quarantining any package with a vulnerability score over a given threshold.

Due to this misguided CVE virtualenv has been quarantined. When misunderstandings result in CVEs being filed it has real impact on users, as well as the waste of contributor time and effort.

Sorry if that is stating the obvious but this issue is impacting me directly.

[jsegitz]

MITRE set the CVE to disputed. Maybe you can get Sonatype to honor this information.

[amine177]

In fact, let's never use computers again. Dangerous things they are, they can be used for many purposes.

We shouldn't live at all, life is dangerous