<p>virtualenvサンドボックスエスケープ</p>

CVE-2018-17793がこの問題に割り当てられました（私からのリクエストはありません）。

ここでセキュリティへの影響について説明していただけますか？ 通常のシェルに戻るためにbashを呼び出すことは、私には脆弱性のようには思えません。 virtualenvを使用すると、信頼できないシェルコマンドを安全に実行できるという印象を受けた人はいないと思いますが、それは目的ではありません。

MITERに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）
linux2上の[GCC7.3.0]
詳細については、「help」、「copyright」、「credits」、または「license」と入力してください。

OSのインポート
os.system（ "$（sh 1>＆2）"）
（test_env）r0ot＃
悪意のあるコードを実行した場合：
（test_env）r0ot＃python $（bash>＆2）
r0ot＃
POC：
（test_env）r0ot＃python
Python 2.7.15（デフォルト、2018年5月1日、05：55：50）
linux2上の[GCC7.3.0]
詳細については、「help」、「copyright」、「credits」、または「license」と入力してください。
OSのインポート
os.system（ "$（bash>＆2）"）
r0ot＃

悪意のあるコードを実行した場合

はい。建物から飛び降りると、途中で何かにぶつかる可能性があります。 あなたは最初からジャンプすることからすでに大きな問題を抱えているので、それは本当に問題ではありません。

サンドボックス内のPYTHONは100％安全ではなく、脆弱性によりサンドボックス保護がバイパスされる可能性があります。 サンドボックスを使用する理由は何ですか？
サンドボックスの修正が難しい場合は、コードのリスクを回避し、サンドボックスの説明でプロンプトを表示することをお勧めします。

@ BakeredPotato999 virtualenv "sandbox"のPythonは0％安全です。 悪意のあるコードに対する保護を目的として設計されておらず、提供もしていません。 あなたはvirtualenvの目的について非常に混乱しているようです。

@ BakeredPotato999 virtualenv "sandbox"のPythonは0％安全です。 悪意のあるコードに対する保護を目的として設計されておらず、提供もしていません。 あなたはvirtualenvの目的について非常に混乱しているようです。

このVirtualenvで実行されているアプリケーションは独立しており、既存のオペレーティングシステムに影響を与えることはないと思います。 サンドボックスを閉じると、すべての操作が復元されます。 サンドボックスを使用すると、リスクを伴う可能性のあるプログラムやソフトウェアをテストできます。 そうですか？

いいえ、完全に間違っています。 virtualenvの目的は、特定のPythonインタープリターとPythonパッケージのセット（systemおよびuserdirがインストールされたパッケージの代わりに）を使用して、通常の環境でプログラムを実行できるようにすることです。

このような「サンドボックス」には、デフォルトではシステムパッケージとユーザーパッケージは含まれず、virtualenvにインストールされているものだけが含まれます。 ただし、 sys.pathを変更してデフォルトのシステムまたはユーザーパッケージに戻すなど、何も妨げられません。

また、それを妨げるものは何もありません。 virtualenvのPythonインタープリターは、システムPythonインタープリター（存在する場合）が同じユーザーによって実行されたときに実行できるすべての操作を実行できる必要があります。 そうしないと、virtualenvの多くの一般的で予想される使用法が壊れてしまいます。

@ BakeredPotato999 virtualenv/bin/activate基本的に、Python実行可能ファイルをパスの早い段階で仮想環境に配置するだけです。 セキュリティのために構築されたものではありません。

これを無効として閉じます。

virtualenvがsandbox @ BakerdPotato999になるのはどうしてですか？

私はドキュメント、githubをgit grepで検索しましたが、 sandbox発生するのはこれだけです。

James Gardnerが、Pylonsでvirtualenvを使用するためのチュートリアルを作成しました。

これはhttp://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox（URLにsandboxれています）にリンクしています。

ちなみに、URLは無効で、ここにありますhttps://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;）。

現在https://www.exploit-db.com/exploits/45528/に「エクスプロイト」が存在し、主要なディストリビューションのセキュリティトラッカーがこれを脆弱性として扱うという事実は、かなりおかしいです。

これを特権昇格として使用できる可能性があると思います。実際に試してみます

ゼロデイ確認済み！ ：NS

非常に面白いです、ハハとそのすべてですが、CVEが作成されていることを考えると
これと他のいくつかのトラッカーもそれをリストしています、それは今到達しています
実際のセキュリティに費やすべきかなりの時間を無駄にするポイント
問題、言い換えれば、私たちは今、私たちのセキュリティに関して一種のDoSを持っています
インフラストラクチャー。 それでは、これを今すぐ寝かせましょう：この「サンドボックスエスケープ」
脆弱性ではありません。

@ 0cjs rootアクセスを取得するために使用できることを証明しましたが、脆弱性ではないのはなぜですか？

1. あなたがrootアクセスを得るためにvirtualenvに関連する何かを使用したというあなたのスクリーンショットの証拠を見ることができません。 実際のエクスプロイトと互換性があることについての説明はありますが、そこのrootのホームディレクトリにRubyバージョンマネージャーがインストールされているように見えることについても言及しているのではないかと少し疑わしいです。
2. virtualenvにはsuidまたは同様のファイルがなく、使用されていないため、virtualenvの外部で何かを悪用する以外に行ったことを実行するためのもっともらしいメカニズムは考えられません。また、それを実行しているユーザー以外のユーザーの特権を引き受けることもありません。 （メカニズムが存在しないと言っているわけではありませんが、この問題がどこにあるのかを少なくともある程度示す必要があります。責任を持って報告した場合は、そのように、そして誰に報告したかを伝える必要があります。報告しました。）

上記のもっともらしい説明の1つは、スクリーンショットの空白行にsudo -sとパスワードプロンプトが含​​まれていることです。 これは、rootユーザー用に部分的に削除されたRVMインストールとともに、何も悪用することなく、まさにその出力を生成します。

@ 0cjs動作したため、実際に空白にしました。古いシステムが原因ではないことを確認するためにテストを行っています。これは、virtualenv内で発生した別のカーネルエクスプロイトであることに同意しています。再びテストします。

設計上、現在のユーザーとして任意のプログラムとコードを実行できるツールを報告する前に、もう少し確認する必要があります。 これをvirtualenvの脆弱性として報告することは、上記のBashも使用したためにBashの脆弱性として報告したり、ある時点で実行したコードのコンパイルに使用されたためにGCCの脆弱性として報告したりするのと同じくらい意味があります。

何も報告しなかった…？

root @kali ：〜/ test_env＃python $（bash>＆2）

うわー、それはいいです、しかしあなたは本当に$（）を使う必要はありません...あなたはただ...

root @ kali：〜/ test_env＃echo「これはいんちきです」

virtualenvサンドボックスメカニズムを「バイパス」します。

@ BakerdPotato999は、任意のpython（またはその他の）コードをrootとして実行することから任意のpython（またはその他の）コードをrootとして実行することまで何とか取得できました。 前者から後者に浮かび上がるセキュリティ問題とは何だと思いますか？

うわー、なんて深刻な問題だ。 他のことを安全に実行できない場合、1つのことを実行することを目的としたソフトウェアをどのように使用できますか？ お知らせ下さい。

@ednix liveoverflow？

@ednixできません。 Unixシェルは_some_目的で安全に使用できないため、二度と使用しないでください。

実際、二度とコンピューターを使わないようにしましょう。 それらは危険なものであり、多くの目的に使用できます。

実際、この「問題」は、 https：//github.com/pypa/virtualenv/issues/1334のアドレス指定に使用できる可能性があることを私に思い出させました-誰かが私たちが始めることができるいくつかのPOCコードを持っていますか？

Nexus by Sonatypeは、pypi.orgのプロキシを提供します。 プロキシを使用すると、脆弱性スコアが特定のしきい値を超えるパッケージを検疫できます。

この誤ったCVEにより、virtualenvは隔離されました。 誤解によってCVEが提出されると、ユーザーに実際の影響が及ぶだけでなく、寄稿者の時間と労力が無駄になります。

それが明白であると述べている場合は申し訳ありませんが、この問題は私に直接影響を与えています。

MITERはCVEを係争に設定しました。 たぶんあなたはSonatypeにこの情報を尊重させることができます。

実際、二度とコンピューターを使わないようにしましょう。 それらは危険なものであり、多くの目的に使用できます。

私たちはまったく生きてはいけません、人生は危険です