<p>邪悪なデータを含むnumpyload関数は、コマンドの実行を引き起こします</p>

バージョン<= 1.16.0、動作しました

はい、それがnp.load(allow_pickle=True)が追加された理由です。今では、デフォルトのFalseに切り替えて、「 allow_pickle="True"てください。このファイルを信頼してください」。

これがより適切なデフォルトになることに同意するので、残念ながら少しうるさい場合でも、たとえばラボでデータを共有する（または自分自身を保存/再ロードする）だけの科学者にとっては、その非推奨をプッシュすることを受け入れます。

したがって、 allow_pickleは2015年4月に追加されたので、numpy1.10以降に存在するはずだったようです。 したがって、1.17を使用/サポートする多くの人が1.10もサポートする（クワーグをサポートする、またはサポートしないという苦痛を取り除く）とは思えないので、移動はより現実的になっていると思います。 今のところ、scipyは少なくともバージョン1で1.8をサポートしているようですが。

長く続くようです

スムーズな移行が必要な場合は、非推奨の警告をログに記録し、日付を指定することをお勧めします。

@Plazmazもちろん、カジュアルユーザーにやめさせたい場合は、VisibleDeprecationWarningを使用します。 その後、1つまたは2つのリリース後に非推奨になります。 問題は、必要に応じて回避するのが面倒であり、一部の古いバージョンにはkwargが存在しないことです。 警告を回避し、両方をサポートするには、 if np.__version__ > ...: use kwarg else do not use kwargを実行する必要があるためです。

とにかく、1.17に入る可能性は十分にあると思います。 したがって、PRを開いていると感じても、メーリングリストにpingを送信して、誰かが不満を言っているかどうかを確認することをお勧めします。

こんにちは、Fedora numpyRPMメンテナ。 ディストリビューションパッケージでこれを軽減するための良い方法は何ですか？

いい方法がわかりません。 懸念レベルにもよりますが、すぐに警告を追加する予定なので、1.17で間違いなくそこにあります。 誰かが非常に心配している場合は、バックポートやより迅速な移動について話し合うことができますが、それはダウンストリームがそれに依存しているかどうかに大きく依存します。

私はこれに取り組んでいます。

cc @jeanqasaur re：セキュリティ/脆弱性の専門知識

こんにちは、Fedora numpyRPMメンテナ。 ディストリビューションパッケージでこれを軽減するための良い方法は何ですか？

@limburgher ：Pythonに組み込まれているまったく同じ機能について

デフォルトを変更することに反対しているわけではありませんが、これを脆弱性と宣言するのは間違っているようです。 文書化および設計どおりに機能しています。

残念ながら、CVE番号が割り当てられると、バグがあるかどうかは問題になりません。ディストリビューションは、顧客に価値を提供していることを証明するためにばなりません。 それがここで何になるかはわかりませんが、企業や運用担当者は、進行中の脆弱性の洪水を管理するのに常に苦労しています。これを行うために使用するツールには、ニュアンスを伝える余地があまりないため、それがプレッシャーの方法です。行きます。 しかし、私たちには顧客がいないので、必ずしもそれを自分で考慮に入れる必要はありません。

saveとload 、特定のファイルがピクルスを使用しているかどうかを知ることができますよね？ どちらの場合もallow_pickle=Falseに移行することをお勧めします。中間期間では、 saveまたはload実際に必要な場合に、ある種の非推奨警告を発行します。ピクルスを使用し、 allow_pickleが指定されていませんでした。

@ eric-wieser stdlib pickleとの違いは、 load / saveは、ほとんどの場合（たとえば、プリミティブ型の単純な配列）、実際にはpickleの使用を回避できることです。 pickleは、オブジェクト配列やIIRCの特定の複雑なdtypeなどのよりエキゾチックなケースでのみ使用されます。 これにより、安全なケースを主に使用している人々は、ドキュメントを十分に読んでいない場合、安全でないケースが存在することを見逃す可能性があります。 とにかく、「セーフモード」と「非セーフモード」の両方があることを考えると、「セーフモード」をデフォルトにする方がよいでしょう。 stdlib pickle OTOHの場合、常に100％安全ではないため、デフォルトについて心配する必要はありません。

正直なところ、それが文書化された意図的な機能である場合、特に安全がデフォルトである場合は、良心的にBZを閉じることができます。 Pythonの機能をどのように処理するかわかりません。 私は見てみましょう。

私のスペックの検討から、その点で上流から何も変更しないと思います。

CVEは争われていますか？ これにより、メンテナにとってシナリオがより明確になる可能性があります。

CVEは主に偽物のようです。 numpy.loadが任意のコードを実行できることはよく知られており、文書化されており、シリアル化されたPythonオブジェクト配列をロードするために必要です。 ユーザーは、このライブラリ関数にallow_pickle=Falseを渡すことにより、オブジェクト配列の読み込みを禁止できます。

デフォルトでは、明示的に要求された場合にのみオブジェクト配列をロードする方がよいでしょうが、歴史的な理由からそのままです。 移行は以前にも提案されており、上記の説明は、下位互換性を制御不能に壊さない方法で移行する方法についてです。

ただし、Pythonのpickle化と同様に、 numpy.load不注意に使用すると、ダウンストリームアプリケーションに脆弱性が生じる可能性があります。

numpy.loadが任意のコードを実行できることはよく知られており、文書化されており、シリアル化されたPythonオブジェクト配列をロードするために必要です。

私はむしろそれが文書化されているとだけ言いたいです。 私は数年間numpyを使用していて、 numpy.save / numpy.load頻繁に使用することはありませんが、 numpy.loadはまったくわかりませんpickleと同じ脆弱性に苦しんでいます。 もちろん、 numpy.loadが内部でpickle使用する可能性があることを知りませんでした（私はnumpyネイティブの配列のみを使用し、考えたことはありません。まさに@njsmithが述べたシナリオです）。

pickleが脆弱であるという事実はよく知られており、そのドキュメントには上部に大きな赤い警告があります。

警告： pickleモジュールは、誤ったデータや悪意を持って作成されたデータに対して安全ではありません。 信頼できない、または認証されていないソースから受信したデータを盗み取らないでください。

比較すると、 numpy.loadのドキュメントでは、 allow_pickleキーワードの説明の脇に、セキュリティの側面全体が記載

allow_pickle：_bool、optional_
npyファイルに保存されているpickle化されたオブジェクト配列のロードを許可します。 ピクルス化されたデータをロードすると任意のコードが実行される可能性があるため、ピクルス化を禁止する理由にはセキュリティが含まれます。 ピクルスが許可されていない場合、オブジェクト配列のロードは失敗します。 デフォルト：True

少なくともallow_pickle=Falseがデフォルトになるまで、 numpy.loadのドキュメントに大きな赤い警告を入れることができれば、私はそれを嫌いではありません。 その変化が見行われるまで、 numpy.load自分の心という点で、同じ赤い旗を上げる必要がありますpickle.load昇給。

numpy.loadドキュメントPRを歓迎します

ドキュメントにピクルスに関する警告が表示されるようになりました

残念ながら、CVE番号が割り当てられると、バグがあるかどうかは問題になりません。ディストリビューションは、顧客に価値を提供していることを証明するために_何か_を試みる必要があります。 それがここで何になるかはわかりませんが、企業や運用担当者は、進行中の脆弱性の洪水を管理するのに常に苦労しています。これを行うために使用するツールには、ニュアンスを伝える余地があまりないため、それがプレッシャーの方法です。行きます。

@njsmithそれほど悪くはありません： numpy.loadデフォルトでallow_pickleからFalseにしますが、これは実際には完全に愚かな考えではありません。

それで私が見る唯一のリスクは、allow_pickleを明示的に設定していないプロジェクトが壊れることです。

それはちょうどエンドユーザーではないのプロジェクト私たちは、心配する必要は-私は提供下流ライブラリ心配mylib.loadラップするnp.load 。 これらはオブジェクト配列のロードに失敗し始めます。 次の3つのうちの1つが発生します。

• それらは放棄されたままであり、以前のようにオブジェクト配列で機能することはありません。 ユーザーは自分のデータが人質にされていることに気づき、それを回復するためにnumpyをダウングレードする必要があります。
• 彼らは設定allow_pickle=Trueを再リリースして、古い動作を再開します。これは、これが関心のある攻撃ベクトルではないと考えていることを示すダウンストリームライブラリです。 これはまだ互換性のないリリースの費用がかかります
• 彼らは独自のAPIでallow_pickle=Falseを公​​開し、問題をダウンストリームにプッシュします。

私の好みは次のとおりです。

• np.saveは何もしません。 オブジェクト配列を保存しているときに、実行時間の長いスクリプトが最後にクラッシュするのは、ひどい経験です。
• np.loadのデフォルトをNone変更します。 TrueまたはFalse明示的に渡していないユーザーを検出し、危険性を説明するUserWarningを発行して、セキュリティ（ False ）とオブジェクトのどちらかを選択するように求めます。配列のサポート（ True ）。 この警告を発した後のデフォルトは現状のままです。 ここでの問題は意識の欠如であると私は理解しています。 どちらの選択もすべての場合に正しいわけではないので、警告なしにデフォルトについて突然考えを変えるべきではないと思います。

@ eric-スクリプトがクラッシュすることの苦痛についてのwieserの良い点。 私はデフォルトでUserWarningを与えるつもりです。

問題は、長期的にはload何をしたいのかということです。 アレイが安全なときに、（警告を消すために）すべての人にkwargを使用するように強制するのが好きかどうかはわかりません。 誰かをデータから締め出す危険性がないというメリットはありますが... OTOH、警告が「安全でない」ロードでのみ表示される場合は、手遅れになる可能性があります。 今のところ、移行期間をもう少し長くすることを少し好みます。

OTOH、警告が「安全でない」ロードでのみ表示される場合は、手遅れである可能性があります。

どちらか：

• ライブラリ/スクリプトはすでに存在し、公開されています-私たちが行うことはすでに手遅れです
• ライブラリ/スクリプトはまだ開発中です。 開発者は、安全なファイルのローカルテスト中に警告を確認し、必要な動作について十分な情報に基づいて決定できる必要があります。 このため、配列が安全であっても（おそらく、 -Werror相当するPythonが設定されている場合に備えて、配列をロードする前に）警告を発する必要があります。

はい、私は間違いなくライブラリに同意しますが、膨大な数の短いスクリプトにとっては少し面倒かもしれないと思います。

デフォルトの変更np.loadにNone 。 TrueまたはFalse明示的に渡していないユーザーを検出し、危険性を説明するUserWarningを発行して、セキュリティ（ False ）とオブジェクトのどちらかを選択するように求めます。配列のサポート（ True ）。 この警告を発した後のデフォルトは現状のままです。 ここでの問題は意識の欠如であると私は理解しています。 どちらの選択もすべての場合に正しいわけではないので、警告なしにデフォルトについて突然考えを変えるべきではないと思います。

しかし、これは非常に迷惑に聞こえます。 ほとんどの人（私は信じています）はオブジェクト配列を保存/ロードしません。 そして、誰かが警告を見逃した場合の最悪のケースは、（最終的には）ロード時にスクリプトがクラッシュし、データはディスク上で安全であり、 allow_pickleフラグを使用して再試行することです。

最初に安全にロードを試み、オブジェクト配列が原因で失敗した場合にのみ叫ぶことは、numpyの責任を超えていますか？ これにより、ほとんどの（オブジェクトではない）ユースケースの余分な作業が削除されますが、セキュリティの問題全体の可視性も低下すると思います。 それからまた、「ユーザーに非常に気づかせるべき」と「ユーザーに不便をかけるべきではない」というのは、ここでは少し矛盾した取り組みだと思います。

* Change the default in `np.load` to `None`. Detect the user not passing in `True` or `False` explicitly, and emit a `UserWarning` explaining the dangers, asking them to choose between security (`False`) and object array support (`True`). Default to the status quo after emitting this warning. It's my understanding that the problem here is lack of awareness. Neither choice is correct in all cases, so I don't think we should suddenly change our minds about the default without warning.

このパッチはどうですか？

* Change the default in `np.load` to `None`. Detect the user not passing in `True` or `False` explicitly, and emit a `UserWarning` explaining the dangers, asking them to choose between security (`False`) and object array support (`True`). Default to the status quo after emitting this warning. It's my understanding that the problem here is lack of awareness. Neither choice is correct in all cases, so I don't think we should suddenly change our minds about the default without warning.

このパッチはどうですか：

--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -265,7 +265,7 @@ class NpzFile(object):
         return self.files.__contains__(key)


-def load(file, mmap_mode=None, allow_pickle=True, fix_imports=True,
+def load(file, mmap_mode=None, allow_pickle=None, fix_imports=True,
          encoding='ASCII'):
     """
     Load arrays or pickled objects from ``.npy``, ``.npz`` or pickled files.
@@ -367,6 +367,16 @@ def load(file, mmap_mode=None, allow_pic
     memmap([4, 5, 6])

     """
+
+    if allow_pickle is None:
+        UserWarning("""
+        numpy.load() run without explicit setting allow_pickle option.
+        If you are not completely certain about security of the pickled
+        data, you are strongly encouraged to set allow_pickle to False,
+        otherwise you can set it to True.
+        """)
+        allow_pickle = False
+
     own_fid = False
     if isinstance(file, basestring):
         fid = open(file, "rb")

オブジェクトデータをロードするときの警告にはまだ賛成です。少し「遅すぎる」可能性がありますが、遷移のノイズははるかに少なくなります。 保存時に警告を追加できます（永続的な警告のみ）。 オープンPRがあり、もっとそういうものに変えてほしいと思います。 あなたがそれに時間を費やしたいのであれば、私たちは一般的にPRに満足しています。
いずれにせよ、すぐに非推奨サイクルを開始する方向への転換であるように私には思えます、そして私はそれが起こると思います（しかし誰かがそれを拾うならばそれはより早くなるでしょう;））。 リクエストが遅れる可能性はわずかにあるかもしれませんが、私はそれを疑っており、試さずに知ることは困難です。

https://nvd.nist.gov/vuln/detail/CVE-2019-6446で参照されているため、この問題を閉じてください

ありがとう@ Manjunath07