<p>virtualenv Sandbox-Flucht</p>

CVE-2018-17793 wurde diesem Problem zugewiesen (von mir nicht angefordert).

Könnten Sie bitte die Sicherheitsauswirkungen hier erläutern? Das Aufrufen von bash, um zur normalen Shell zurückzukehren, scheint mir keine Schwachstelle zu sein. Ich glaube nicht, dass irgendjemand den Eindruck hatte, dass Sie mit virtualenv nicht vertrauenswürdige Shell-Befehle sicher ausführen können, dafür ist es nicht gedacht.

Ich habe MITRE gebeten, den CVE abzulehnen

Normal wie folgt:
(test_env) r0ot#python $(sh 1>&2)
(test_env) r0ot#
(test_env) r0ot#python
Python 2.7.15 (Standard, 1. Mai 2018, 05:55:50)
[GCC 7.3.0] unter Linux2
Geben Sie "Hilfe", "Copyright", "Credits" oder "Lizenz" ein, um weitere Informationen zu erhalten.

Importieren von OS
os.system("$(sh 1>&2)")
(test_env) r0ot#
Wenn Sie Schadcode ausführen:
(test_env) r0ot#python $(bash >&2)
r0ot#
POC:
(test_env) r0ot#python
Python 2.7.15 (Standard, 1. Mai 2018, 05:55:50)
[GCC 7.3.0] unter Linux2
Geben Sie "Hilfe", "Copyright", "Credits" oder "Lizenz" ein, um weitere Informationen zu erhalten.
Importieren von OS
os.system("$(bash >&2)")
r0ot#

Wenn Sie bösartigen Code ausführen

Ja, und wenn Sie von einem Gebäude springen, können Sie auf dem Weg nach unten etwas treffen. Es spielt keine Rolle, da Sie bereits vom Springen an in großen Schwierigkeiten sind.

PYTHON in der Sandbox ist nicht 100% sicher und Schwachstellen können dazu führen, dass der Sandbox-Schutz umgangen wird. Was sind die Gründe für die Verwendung der Sandbox?
Wenn die Sandbox schwer zu reparieren ist, wird empfohlen, Risiken im Code zu vermeiden und in der Sandbox-Beschreibung dazu aufgefordert zu werden.

@BakedPotato999 Python in der virtualenv "Sandbox" ist 0% sicher; es ist weder dafür konzipiert, noch bietet es Schutz vor bösartigem Code. Sie scheinen sehr verwirrt über den Zweck von virtualenv zu sein.

@BakedPotato999 Python in der virtualenv "Sandbox" ist 0% sicher; es ist weder dafür konzipiert, noch bietet es Schutz vor bösartigem Code. Sie scheinen sehr verwirrt über den Zweck von virtualenv zu sein.

Ich denke, die Anwendungen, die in diesem Virtualenv ausgeführt werden, sind unabhängig und haben keinen Einfluss auf Ihr vorhandenes Betriebssystem. Durch das Schließen der Sandbox werden alle Vorgänge wiederhergestellt. Mit der Sandbox können Sie Programme und Software testen, die riskant sein könnten. Ist das richtig?

Nö, völlig falsch. Der Zweck einer virtualenv besteht darin, dass Sie einen bestimmten Python-Interpreter und eine Reihe von Python-Paketen (anstelle der system- und userdir-installierten Pakete) verwenden können, um Programme in einer ansonsten normalen Umgebung auszuführen.

Die "Sandbox", wie sie ist, sollte standardmäßig keine System- und Benutzerpakete enthalten, sondern nur die in der virtualenv installierten. Aber nichts hält Sie davon ab, zB sys.path zu ändern, um Standardsystem- oder Benutzerpakete wiederherzustellen.

Daran sollte dich auch nichts hindern. Der Python-Interpreter in einer virtuellen Umgebung sollte in der Lage sein, alle Operationen auszuführen, die der System-Python-Interpreter (falls vorhanden) ausführen kann, wenn er von demselben Benutzer ausgeführt wird. Anderenfalls würde viele übliche und erwartete Verwendungen einer virtuellen Umgebung zunichte gemacht.

@BakedPotato999 virtualenv/bin/activate fügt im Grunde nur die ausführbare Python-Datei in die virtuelle Umgebung früher in Ihrem Pfad ein. Es ist nicht für Sicherheit gebaut.

Ich schließe dies als ungültig.

Ich frage mich nur, wie Sie dazu gekommen sind, dass virtualenv ein sandbox @BakedPotato999 ist ?

Ich durchsuchte Dokumente, Github und mit einem git grep und das einzige Vorkommen von sandbox ist dieses:

James Gardner hat ein Tutorial zur Verwendung von virtualenv mit Pylons geschrieben.

welches auf http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox verlinkt (die sandbox in der URL hat).

Die URL ist übrigens tot und sie ist hier https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;).

Die Tatsache, dass es jetzt "exploit" gibt https://www.exploit-db.com/exploits/45528/ und dass Sicherheitstracker großer Distributionen dies als Schwachstelle behandeln, ist ziemlich lustig.

Ich denke, wir können das vielleicht als Privilegeskalation nutzen, ich werde es tatsächlich versuchen

0Tag bestätigt! :D

Sehr amüsant, ha ha und all das, aber da ein CVE erstellt wurde für
dieser und mehrere andere Tracker listen es auch auf, es erreicht jetzt die
Punkt, an dem viel Zeit verschwendet wird, die für echte Sicherheit aufgewendet werden sollte
Probleme, mit anderen Worten, wir haben jetzt eine Art DoS für unsere Sicherheit
Infrastruktur. Also lass uns das jetzt bitte ins Bett legen: diese "Sandkastenflucht"
ist keine Schwachstelle.

@0cjs Ich habe gerade bewiesen, dass es verwendet werden kann, um Root-Zugriff zu erhalten.

1. Ich kann in Ihrem Screenshot keine Beweise dafür sehen, dass Sie etwas im Zusammenhang mit virtualenv verwendet haben, um Root-Zugriff zu erhalten. Es ist ein wenig verdächtig, dass dort auch eine Ruby Version Manager- Installation im Home-Verzeichnis von root wird, obwohl es Erklärungen dafür gibt, die mit einem echten Exploit kompatibel sind.
2. Ich kann mir keinen plausiblen Mechanismus vorstellen, um das zu tun, was Sie getan haben, ohne etwas außerhalb von virtualenv auszunutzen, da virtualenv keine suid oder ähnliche Dateien hat und verwendet und zu keinem Zeitpunkt die Privilegien eines anderen Benutzers als desjenigen übernimmt, der es ausführt. (Ich sage nicht, dass der Mechanismus nicht existiert, aber Sie müssen zumindest einen Hinweis darauf geben, wo dieses Problem liegen könnte. Wenn Sie es verantwortungsbewusst gemeldet haben, müssen Sie dies sagen und wem Sie es mitgeteilt haben hat es gemeldet.)

Eine plausible Erklärung für das obige ist, dass die ausgeblendeten Zeilen in Ihrem Screenshot sudo -s und eine Passwortabfrage enthalten. Das würde zusammen mit einer teilweise entfernten RVM-Installation für den Root-Benutzer genau diese Ausgabe erzeugen, ohne überhaupt etwas auszunutzen.

@0cjs Ich habe es tatsächlich ausgeblendet, weil es funktioniert hat, ich

Nun, Sie sollten die Dinge noch ein wenig bestätigen, bevor Sie Tools melden, die es Ihnen per Design ermöglichen, beliebige Programme und Code als aktueller Benutzer auszuführen. Dies als Virtualenv-Schwachstelle zu melden, ist genauso sinnvoll wie die Meldung als Bash-Schwachstelle, weil Sie oben auch Bash verwendet haben, oder als GCC-Schwachstelle, weil sie verwendet wurde, um Code zu kompilieren, den Sie zu einem bestimmten Zeitpunkt ausgeführt haben.

Ich habe nichts gemeldet...?

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

Wow, das ist nett, aber Sie müssen nicht wirklich $ () verwenden ... Sie könnten einfach ...

root@kali :~/test_env#echo "Das ist Quacksalberei"

um die virtualenv-Sandboxing-Mechanismen zu "umgehen".

@BakedPotato999 Sie haben es geschafft, von der Ausführung von beliebigem Python- (oder anderem) Code als Root ... zur Ausführung von beliebigem Python- (oder anderem) Code als Root zu gelangen. Was schlagen Sie vor, ist ein Sicherheitsproblem, das aus der ersten Situation in die zweite auftaucht?

Woah, was für ein ernstes Problem. Wie kann ich eine Software verwenden, die eine bestimmte Aufgabe erfüllen soll, wenn sie eine andere Aufgabe nicht sicher ausführen kann? Bitte beraten.

@ednix Liveüberlauf?

@ednix Du kannst nicht. Sie dürfen nie wieder eine Unix-Shell verwenden, da sie für _manche_ Zwecke nicht sicher verwendet werden kann.

In der Tat, lassen Sie uns nie wieder Computer benutzen. Gefährliche Dinge sind sie, sie können für viele Zwecke verwendet werden.

Tatsächlich hat mich dieses "Problem" daran erinnert, dass es möglicherweise möglich ist, https://github.com/pypa/virtualenv/issues/1334 zu adressieren - hat jemand einen POC-Code, mit dem wir beginnen können?

Nexus von Sonatype bietet einen Proxy für pypi.org. Der Proxy ermöglicht die Quarantäne jedes Pakets mit einer Schwachstellenbewertung über einem bestimmten Schwellenwert.

Aufgrund dieser fehlgeleiteten CVE wurde virtualenv unter Quarantäne gestellt. Wenn Missverständnisse dazu führen, dass Lebensläufe eingereicht werden, hat dies echte Auswirkungen auf die Benutzer und verschwendet Zeit und Mühe der Mitwirkenden.

Tut mir leid, wenn das das Offensichtliche ist, aber dieses Problem betrifft mich direkt.

MITRE hat den CVE auf umstritten gesetzt. Vielleicht können Sie Sonatype dazu bringen, diese Informationen zu berücksichtigen.

In der Tat, lassen Sie uns nie wieder Computer benutzen. Gefährliche Dinge sind sie, sie können für viele Zwecke verwendet werden.

Wir sollten überhaupt nicht leben, das Leben ist gefährlich