<p>virtualenv 沙盒逃逸</p>

CVE-2018-17793已分配到此问题（不是我要求的）。

你能解释一下这里的安全影响吗？ 调用 bash 以返回正常的 shell 对我来说似乎不是一个漏洞。 我不认为任何人都认为 virtualenv 允许您安全地运行不受信任的 shell 命令，这不是它的目的。

我要求 MITRE 拒绝 CVE

正常情况如下：
(test_env) r0ot#python $(sh 1>&2)
(test_env) r0ot#
(test_env) r0ot#python
Python 2.7.15（默认，2018 年 5 月 1 日，05:55:50）
[GCC 7.3.0] 在 linux2 上
输入“帮助”、“版权”、“信用”或“许可”以获取更多信息。

导入操作系统
os.system("$(sh 1>&2)")
(test_env) r0ot#
如果您执行恶意代码：
(test_env) r0ot#python $(bash >&2)
r0ot#
概念验证：
(test_env) r0ot#python
Python 2.7.15（默认，2018 年 5 月 1 日，05:55:50）
[GCC 7.3.0] 在 linux2 上
输入“帮助”、“版权”、“信用”或“许可”以获取更多信息。
导入操作系统
os.system("$(bash >&2)")
r0ot#

如果您执行恶意代码

是的，如果你从建筑物上跳下来，你可能会在下落的过程中撞到什么东西。 这并不重要，因为从一开始你就已经遇到了大麻烦。

沙箱中的 PYTHON 并非 100% 安全，漏洞可能会导致绕过沙箱保护。 使用沙箱的原因是什么？
如果沙箱难以修复，建议在代码中规避风险，并在沙箱描述中进行提示。

@BakedPotato999 virtualenv“沙箱”中的 Python 是 0% 安全的； 它既没有设计也没有提供任何针对恶意代码的保护。 你似乎对 virtualenv 的目的很困惑。

@BakedPotato999 virtualenv“沙箱”中的 Python 是 0% 安全的； 它既没有设计也没有提供任何针对恶意代码的保护。 你似乎对 virtualenv 的目的很困惑。

我认为在这个 Virtualenv 中运行的应用程序是独立的，不会影响您现有的操作系​​统。 关闭沙箱将恢复所有操作。 使用沙箱，您可以测试可能有风险的程序和软件。 那正确吗？

不，完全错误。 virtualenv 的目的是让您使用特定的 Python 解释器和一组 Python 包（而不是系统和用户目录安装的包）在其他正常环境中运行程序。

像这样的“沙箱”在默认情况下不应该包含系统和用户包，只包含安装在 virtualenv 中的包。 但是没有什么可以阻止您，例如，更改sys.path以带回默认系统或用户包。

也不应该阻止您这样做。 virtualenv 中的 Python 解释器应该能够执行系统 ​​Python 解释器（如果有）在由同一用户运行时可以执行的所有操作。 否则会破坏 virtualenv 的许多常见和预期用途。

@BakedPotato999 virtualenv/bin/activate基本上只是将 Python 可执行文件放在您路径中较早的虚拟环境中。 它不是为安全而构建的。

我会将其关闭为无效。

我只是想知道，你是怎么把 virtualenv 变成sandbox @BakedPotato999 的？

我搜索了文档、github 和git grep ，唯一的sandbox是这个：

James Gardner 编写了关于在 Pylons 中使用 virtualenv 的教程。

它链接到http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox （sandbox ）。

顺便说一句，网址已经死了，它在这里https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;)

现在存在“漏洞利用” https://www.exploit-db.com/exploits/45528/并且主要发行版的安全跟踪器将此视为漏洞这一事实相当有趣。

我想我们也许可以将其用作权限提升，我将实际尝试一下

0day确认！ :D

非常有趣，哈哈等等，但鉴于已经为
这个和其他几个跟踪器也在列出它​​，它现在到达
浪费大量时间应该花在真正的安全上
问题，换句话说，我们现在确实对我们的安全有某种 DoS
基础设施。 所以现在让我们把它放在床上：这个“沙盒逃生”
不是漏洞。

@0cjs我刚刚证明它可以用来获得 root 访问权限，这怎么不是漏洞？

1. 我无法在您的屏幕截图中看到您使用与 virtualenv 相关的任何内容来获得 root 访问权限的证据。 有点可疑的是，它也提到了root的主目录中似乎安装了Ruby 版本管理器的内容，尽管有一些解释说明它与真正的漏洞利用兼容。
2. 我想不出一种合理的机制来做你在利用 virtualenv 之外的东西之外所做的事情，因为 virtualenv 没有也不使用 suid 或类似的文件，在任何时候它也不会承担任何用户的特权，而不是运行它的人。 （我并不是说该机制不存在，但您至少需要提供一些可能出现此问题的迹象。如果您负责任地报告了它，您需要这样说，以及您向谁报告举报了。）

对上述情况的一种合理解释是，屏幕截图中的空白行包括sudo -s和密码提示。 这与 root 用户的部分删除的 RVM 安装一起，将产生完全相同的输出，而根本不会利用任何东西。

@0cjs我实际上把它

好吧，您应该在报告根据设计允许您以当前用户身份运行任意程序和代码的工具之前多确认一些事情。 将此报告为 virtualenv 漏洞与将其报告为 Bash 漏洞（因为您在上面也使用了 Bash）或 GCC 漏洞（因为它用于编译您在某个时候运行的某些代码）一样有意义。

我什么都没报告……？

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

哇，这很好，但你真的不需要使用 $() ......你可以......

root@kali :~/test_env#echo "这是骗人的"

“绕过”virtualenv 沙盒机制。

@BakedPotato999您设法从以 root 身份执行任意 python（或其他）代码......到以 root 身份执行任意 python（或其他）代码。 您认为从前一种情况弹出到后一种情况的安全问题是什么？

哇，多么严重的问题。 如果软件不能安全地做另一件事，我如何使用旨在做一件事的软件？ 请指教。

@ednix直播？

@ednix你不能。 您绝不能再次使用 Unix shell，因为它不能安全地用于_某些_目的。

事实上，我们永远不要再使用电脑了。 它们是危险的东西，它们可以用于许多目的。

事实上，这个“问题”提醒我可能可以用于解决https://github.com/pypa/virtualenv/issues/1334 - 有没有人有一些我们可以开始的 POC 代码？

Sonatype 的 Nexus 为 pypi.org 提供了一个代理。 该代理允许隔离漏洞分数超过给定阈值的任何包。

由于这个被误导的 CVE virtualenv 已被隔离。 当误解导致 CVE 被提交时，它会对用户产生真正的影响，同时也会浪费贡献者的时间和精力。

对不起，如果那是显而易见的，但这个问题直接影响了我。

MITRE 将 CVE 设置为有争议的。 也许你可以让 Sonatype 尊重这些信息。

事实上，我们永远不要再使用电脑了。 它们是危险的东西，它们可以用于许多目的。

我们根本不应该活着，生命是危险的