<p>Fungsi numpy load dengan data jahat akan menyebabkan eksekusi perintah</p>

versi <= 1.16.0, bekerja

Ya, itulah sebabnya np.load(allow_pickle=True) ditambahkan, sekarang saya kira kita bisa beralih ke default ke False dan memberikan pesan yang mudah dibaca "gunakan allow_pickle="True" jika Anda percaya file ini ".

Saya setuju bahwa ini akan menjadi default yang lebih baik, jadi saya terbuka untuk mendorong penghentian itu, meskipun sayangnya agak berisik misalnya untuk semua ilmuwan yang hanya berbagi beberapa data di lab (atau hanya menyimpan / memuat ulang sendiri).

Jadi allow_pickle ditambahkan pada bulan april 2015, jadi sepertinya itu sudah ada sejak numpy 1.10. Jadi menurut saya langkah itu menjadi lebih realistis sekarang, karena saya ragu banyak yang menggunakan / mendukung 1,17 juga akan tetap mendukung 1,10 (menghilangkan rasa sakit saat mendukung kwarg atau tidak mendukungnya). Meskipun untuk saat ini tampaknya scipy setidaknya masih mendukung 1.8 di versi 1.

sepertinya itu akan bertahan lama

Saya sarankan mencatat peringatan penghentian dan memberikan tanggal jika Anda ingin transisi yang lancar.

@Plazmaz tentu saja, saya akan menggunakan VisibleDeprecationWarning, jika kita ingin pengguna biasa berhenti melakukannya. Kemudian hentikan setelah satu atau dua rilis. Masalahnya adalah menjengkelkan untuk dikerjakan jika Anda harus dan kwarg tidak ada di beberapa versi yang lebih lama. Karena Anda harus melakukan if np.__version__ > ...: use kwarg else do not use kwarg untuk menghindari peringatan dan dukungan keduanya.

Bagaimanapun, saya pikir ada peluang bagus Anda bisa mendapatkannya menjadi 1,17. Jadi jika Anda merasa membuka PR, tetapi kami mungkin ingin melakukan ping ke milis untuk melihat apakah ada yang mengeluh.

Hai, pengelola RPM numpy Fedora. Apa cara yang baik untuk mengurangi hal ini dalam kemasan distro?

Saya tidak tahu cara yang bagus. Bergantung pada tingkat perhatian, saya akan segera menambahkan peringatan, sehingga sudah pasti ada di 1,17. Jika seseorang sangat khawatir, kita bisa mendiskusikan backporting atau bergerak lebih cepat, tapi itu akan sangat bergantung pada apakah hilir bergantung padanya atau tidak.

Saya sedang mengerjakan ini.

cc @jeanqasaur perihal: keahlian keamanan / kerentanan

Hai, pengelola RPM numpy Fedora. Apa cara yang baik untuk mengurangi hal ini dalam kemasan distro?

@limburgher : apa yang dilakukan fedora tentang fungsionalitas yang sama persis yang dibangun ke dalam Python? Tidak jelas apakah ini adalah sesuatu yang perlu dikurangi.

Meskipun saya tidak menentang untuk mengubah default, tampaknya salah untuk menyatakan ini sebagai kerentanan. Ini berfungsi seperti yang didokumentasikan dan dirancang.

Sayangnya aturannya adalah setelah nomor CVE ditetapkan, tidak lagi menjadi masalah apakah ada bug atau tidak, distro harus mencoba melakukan sesuatu untuk membuktikan kepada pelanggan mereka bahwa mereka Memberikan Nilai. Tidak yakin apa yang akan terjadi di sini, tetapi perusahaan dan ops orang selalu berjuang untuk mengelola banjir kerentanan yang sedang berlangsung, dan alat yang mereka gunakan untuk melakukan ini tidak memiliki banyak ruang untuk mengkomunikasikan nuansa, jadi itulah tekanannya. pergi. Kami tidak memiliki pelanggan, jadi kami tidak perlu memperhitungkannya sendiri.

Kita dapat mengetahui selama save dan load apakah file tertentu menggunakan acar atau tidak, bukan? Mungkin baik untuk bermigrasi ke allow_pickle=False dalam kedua kasus, dengan periode perantara di mana kami mengeluarkan semacam peringatan penghentian persis dalam kasus di mana save atau load benar-benar membutuhkan untuk menggunakan acar dan allow_pickle tidak ditentukan.

@ eric-wieser Perbedaan dari stdlib pickle adalah bahwa load / save sebenarnya dapat menghindari penggunaan acar dalam banyak kasus (misalnya, array sederhana dari tipe primitif); acar hanya digunakan dalam kasus yang lebih eksotis seperti array objek atau IIRC dtypes rumit tertentu. Hal ini memungkinkan orang-orang yang kebanyakan menggunakan kotak aman untuk melewatkan bahwa kasing tidak aman ada, jika mereka tidak membaca dokumen dengan cukup cermat. Dan bagaimanapun, mengingat kita memiliki "mode aman" dan "mode tidak aman", lebih baik "mode aman" menjadi default. Untuk stdlib acar OTOH, itu selalu 100% tidak aman 100% setiap saat jadi tidak ada gunanya khawatir tentang default.

Jujur saja, jika didokumentasikan, fungsionalitas yang disengaja, saya bisa menutup BZ dengan hati nurani yang baik, terutama jika aman adalah defaultnya. Saya tidak tahu bagaimana kami menangani fungsionalitas Python. Saya akan melihat.

Dari pemeriksaan saya terhadap spesifikasi, saya rasa kami tidak mengubah apa pun dari hulu dalam hal itu.

Apakah CVE telah disengketakan? Itu mungkin membuat skenario lebih jelas bagi pengelola.

CVE sebagian besar tampak palsu. numpy.load dapat mengeksekusi kode arbitrer sudah dikenal dan didokumentasikan, dan itu diperlukan untuk memuat array objek Python serial. Pengguna dapat melarang memuat array objek dengan meneruskan allow_pickle=False ke fungsi perpustakaan ini.

Akan lebih baik jika defaultnya adalah memuat array objek hanya ketika ditanya secara eksplisit, tetapi itu karena alasan historis. Transisi juga telah disarankan sebelumnya, dan pembahasan di atas adalah tentang bagaimana membuatnya dengan cara yang tidak merusak kompatibilitas ke belakang secara tak terkendali.

Penggunaan numpy.load sembarangan, sama seperti pengawetan Python, dapat menyebabkan kerentanan dalam aplikasi hilir.

numpy.load dapat mengeksekusi kode arbitrer sudah dikenal dan didokumentasikan, dan itu diperlukan untuk memuat array objek Python serial.

Saya lebih suka hanya mengatakan bahwa itu didokumentasikan. Saya telah menggunakan numpy selama beberapa tahun, dan meskipun saya bukan pengguna tetap numpy.save / numpy.load , sama sekali tidak jelas bagi saya bahwa numpy.load menderita kerentanan yang sama seperti pickle . Tentu saja saya tidak tahu bahwa numpy.load mungkin menggunakan pickle (Saya hanya menggunakan array numpy-native dan tidak pernah memikirkannya, persis seperti skenario yang disebutkan @njsmith ).

Fakta bahwa pickle rentan sudah diketahui umum, dan dokumentasinya memiliki peringatan merah besar di atas mengatakan

Peringatan : Modul pickle tidak aman dari data yang dibuat secara salah atau berbahaya. Jangan pernah membongkar data yang diterima dari sumber yang tidak tepercaya atau tidak diautentikasi.

Sebagai perbandingan, dokumen numpy.load tampaknya menyebutkan seluruh aspek keamanan sebagai tambahan dalam deskripsi kata kunci allow_pickle :

allow_pickle: _bool, opsional_
Izinkan pemuatan array objek acar yang disimpan dalam file npy. Alasan untuk tidak mengizinkan acar termasuk keamanan, karena memuat data acar dapat mengeksekusi kode arbitrer. Jika acar tidak diizinkan, memuat array objek akan gagal. Default: Benar

Saya tidak akan membencinya jika kita bisa meletakkan Peringatan Merah Besar ke dalam dokumentasi numpy.load , setidaknya sampai allow_pickle=False menjadi default. Sampai perubahan itu dibuat, melihat numpy.load harus menaikkan bendera merah yang sama dalam pikiran seseorang yang menaikkan pickle.load .

Dokumentasi PR dipersilakan untuk numpy.load

Dokumentasi sekarang memiliki peringatan tentang acar

Sayangnya aturannya adalah setelah nomor CVE diberikan, tidak masalah apakah ada bug atau tidak, distro harus mencoba melakukan _something_ untuk membuktikan kepada pelanggan mereka bahwa mereka Memberikan Nilai. Tidak yakin apa yang akan terjadi di sini, tetapi perusahaan dan ops orang selalu berjuang untuk mengelola banjir kerentanan yang sedang berlangsung, dan alat yang mereka gunakan untuk melakukan ini tidak memiliki banyak ruang untuk mengkomunikasikan nuansa, jadi itulah tekanannya. pergi.

@njsmith tidak terlalu buruk : kita akan membuat numpy.load default menjadi allow_pickle menjadi False , yang sebenarnya bukan ide yang sepenuhnya bodoh.

Satu-satunya risiko yang saya lihat adalah proyek apa pun yang tidak secara eksplisit mengatur allow_pickle akan rusak.

Bukan hanya proyek pengguna akhir yang harus kita khawatirkan - saya khawatir tentang perpustakaan hilir yang menyediakan mylib.load yang membungkus np.load . Ini akan mulai gagal memuat array objek. Salah satu dari tiga hal yang akan terjadi dengan mereka:

• Mereka tetap ditinggalkan, dan tidak akan pernah bekerja pada array objek seperti dulu. Pengguna akan menemukan data mereka disandera, dan harus menurunkan versi numpy untuk memulihkannya.
• Mereka merilis ulang pengaturan allow_pickle=True untuk melanjutkan perilaku lama - yang merupakan pustaka hilir yang menunjukkan bahwa mereka pikir ini bukan vektor serangan yang mereka pedulikan. Ini masih membuat mereka kehilangan rilis yang tidak kompatibel
• Mereka akan mengekspos allow_pickle=False di API mereka sendiri, mendorong masalah ke hilir.

Preferensi saya adalah:

• Jangan lakukan apa pun untuk np.save . Memiliki crash skrip yang berjalan lama di bagian akhir saat menyimpan larik objek adalah pengalaman yang mengerikan.
• Ubah default di np.load menjadi None . Mendeteksi pengguna yang tidak mengirimkan True atau False secara eksplisit, dan mengeluarkan UserWarning menjelaskan bahayanya, meminta mereka untuk memilih antara keamanan ( False ) dan objek dukungan array ( True ). Default ke status quo setelah mengeluarkan peringatan ini. Pemahaman saya bahwa masalah di sini adalah kurangnya kesadaran. Tidak ada pilihan yang benar dalam semua kasus, jadi saya rasa kita tidak harus tiba-tiba berubah pikiran tentang default tanpa peringatan.

@eric-wieser poin bagus tentang sakitnya skrip yang rusak. Saya akan siap untuk memberikan UserWarning secara default.

Pertanyaannya adalah apa yang ingin kita lakukan dalam jangka panjang di load . Saya tidak yakin saya suka memaksa semua orang untuk menggunakan kwarg (untuk membungkam peringatan), saat array aman. Meskipun memiliki manfaat tidak berbahaya untuk mengunci seseorang dari datanya ... OTOH, jika peringatan hanya muncul pada pemuatan "tidak aman", mungkin sudah terlambat. Saat ini saya pikir saya memiliki sedikit preferensi untuk membuat periode transisi agak lebih lama.

OTOH, jika peringatan hanya muncul pada beban "tidak aman", mungkin sudah terlambat.

Antara:

• Pustaka / skrip sudah ada dan diterbitkan - apapun yang kita lakukan sudah terlambat
• Perpustakaan / skrip masih dalam pengembangan. Pengembang harus melihat peringatan selama pengujian lokal pada file yang aman, dan harus dapat membuat keputusan yang tepat tentang perilaku yang mereka inginkan. Untuk alasan ini, kita harus mengeluarkan peringatan bahkan jika arraynya aman (dan mungkin sebelum memuatnya, kalau-kalau mereka memiliki python yang setara dengan -Werror set).

Ya, saya pasti setuju untuk perpustakaan, tapi saya pikir ini mungkin agak mengganggu untuk sejumlah besar skrip yang lebih pendek.

Ubah default di np.load menjadi None . Deteksi pengguna tidak mengirimkan True atau False secara eksplisit, dan keluarkan UserWarning menjelaskan bahayanya, minta mereka untuk memilih antara keamanan ( False ) dan objek dukungan array ( True ). Default ke status quo setelah mengeluarkan peringatan ini. Pemahaman saya bahwa masalah di sini adalah kurangnya kesadaran. Tidak ada pilihan yang benar dalam semua kasus, jadi saya rasa kita tidak harus tiba-tiba berubah pikiran tentang default tanpa peringatan.

Ini terdengar sangat menjengkelkan. Kebanyakan orang (saya percaya) tidak menyimpan / memuat array objek. Dan kasus terburuk jika seseorang melewatkan peringatan itu (pada akhirnya) skrip mereka mogok saat memuat, datanya masih aman di disk, dan mereka mencoba lagi dengan bendera allow_pickle .

Apakah di luar tanggung jawab numpy untuk mencoba memuat dengan aman terlebih dahulu dan hanya berteriak jika gagal karena array objek? Itu akan menghapus pekerjaan ekstra untuk sebagian besar kasus penggunaan (non-objektif), tetapi saya rasa itu juga akan mengurangi visibilitas keseluruhan masalah keamanan. Kemudian lagi saya pikir "pengguna harus dibuat sangat sadar" dan "pengguna tidak boleh direpotkan" adalah upaya yang agak kontradiktif di sini.

* 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.

Bagaimana dengan tambalan ini?

* 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.

Bagaimana dengan tambalan ini:

--- 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")

Saya masih mendukung peringatan saat memuat data objek, ini bisa menjadi sedikit "terlambat", tetapi membuat transisi yang jauh lebih tidak berisik. Kita bisa menambahkan peringatan saat menyimpan (hanya peringatan permanen). Ada PR terbuka yang saya harap bisa berubah menjadi seperti itu. Jika Anda ingin menghabiskan waktu untuk itu, kami umumnya senang dengan PR.
Tampak bagi saya bahwa ini adalah konversi untuk memulai siklus penghentian segera dalam hal apa pun, dan saya pikir itu akan terjadi (tetapi akan lebih cepat jika seseorang mengambilnya;)). Mungkin ada kemungkinan kecil permintaan untuk ditunda, tetapi saya meragukannya, dan sulit untuk mengetahui tanpa berusaha.

Bisakah Anda menutup masalah ini karena dirujuk di https://nvd.nist.gov/vuln/detail/CVE-2019-6446 karena nexus iq masih menganggapnya Rentan

terima kasih @ Manjunath07