<p>ستؤدي وظيفة التحميل غير المتكرر مع البيانات الشريرة إلى تنفيذ الأمر</p>

الإصدار <= 1.16.0 ، يعمل

نعم ، وهذا هو سبب إضافة np.load(allow_pickle=True) ، والآن أعتقد أنه يمكننا الانتقال إلى الإعداد الافتراضي إلى False وإعطاء رسالة يمكن قراءتها جيدًا "استخدم allow_pickle="True" إذا كنت ثق بهذا الملف ".

أوافق على أن هذا سيكون أفضل خيار افتراضي ، لذا فأنا منفتح على دفع هذا الإهمال ، حتى لو كان لسوء الحظ صاخبًا بعض الشيء ، على سبيل المثال بالنسبة لجميع هؤلاء العلماء الذين يشاركون فقط بعض البيانات في المختبر (أو مجرد حفظ / إعادة تحميل أنفسهم).

لذلك تمت إضافة allow_pickle في أبريل 2015 ، لذلك يبدو أنه كان يجب أن يكون موجودًا منذ 1.10. لذلك أعتقد أن هذه الخطوة أصبحت أكثر واقعية الآن ، لأنني أشك في أن العديد ممن يستخدمون / يدعمون 1.17 سيظلون يدعمون أيضًا 1.10 (إزالة ألم دعم kwarg أو عدم دعمه). على الرغم من أنه في الوقت الحالي يبدو خادعًا على الأقل لا يزال يدعم 1.8 في الإصدار 1.

يبدو أنه سيستمر لفترة طويلة

أود أن أقترح تسجيل تحذير الإيقاف وإعطاء تاريخ إذا كنت تريد انتقالًا سلسًا.

Plazmaz بالطبع ، سأذهب مع VisibleDeprecationWarning ، إذا أردنا أن يتوقف المستخدمون العاديون عن فعل ذلك. ثم يتم إيقاف العمل به بعد إصدار واحد أو إصدارين. الشيء هو أنه من المزعج العمل إذا كان عليك ذلك ولا يوجد kwarg في بعض الإصدارات القديمة. لأنه بعد ذلك عليك أن تفعل if np.__version__ > ...: use kwarg else do not use kwarg لتجنب التحذير ودعم كليهما.

على أي حال ، أعتقد أن هناك فرصة جيدة للوصول إلى 1.17. لذلك إذا كنت تشعر بفتح علاقات عامة ، لكننا قد نرغب في اختبار اتصال القائمة البريدية لمعرفة ما إذا كان شخص ما يشتكي.

مرحبًا ، مشرف فيدورا numpy RPM. ما هي الطريقة الجيدة لتخفيف ذلك في توزيعات التغليف؟

أنا لا أعرف طريقة لطيفة. اعتمادًا على مستوى القلق ، سأكون على استعداد لإضافة تحذير قريبًا جدًا ، بحيث يكون هناك بالتأكيد في 1.17. إذا كان شخص ما قلقًا للغاية ، فيمكننا مناقشة نقله إلى الخلف أو التحرك بشكل أسرع ، لكن هذا يعتمد كثيرًا على ما إذا كان المصب يعتمد عليه أم لا.

انا اعمل على هذا

ccjeanqasaur re: خبرة في الأمان / الثغرات الأمنية

مرحبًا ، مشرف فيدورا numpy RPM. ما هي الطريقة الجيدة لتخفيف ذلك في توزيعات التغليف؟

limburgher : ماذا يفعل فيدورا حيال الوظيفة نفسها المضمنة في بايثون؟ ليس من الواضح ما إذا كان هذا شيء يحتاج إلى التخفيف.

على الرغم من أنني لا أعارض تغيير الإعداد الافتراضي ، يبدو من الخطأ إعلان أن هذه ثغرة أمنية. إنه يعمل كما هو موثق ومصمم.

لسوء الحظ ، القاعدة هي أنه بمجرد تعيين رقم CVE ، لم يعد يهم ما إذا كان هناك أي خطأ أم لا ، يتعين على التوزيعات محاولة القيام بشيء لإثبات لعملائها أنهم يقدمون قيمة. لست متأكدًا مما سيكون عليه الأمر هنا ، لكن الشركات والأفراد يكافحون دائمًا لإدارة التدفق المستمر لنقاط الضعف ، والأدوات التي يستخدمونها للقيام بذلك لا توفر مجالًا كبيرًا للتواصل مع الفروق الدقيقة ، لذا فهذه هي طريقة الضغط يذهب. ومع ذلك ، ليس لدينا عملاء ، لذلك لا ينبغي لنا بالضرورة أن نأخذ ذلك بعين الاعتبار بأنفسنا.

يمكننا أن نعرف خلال save و load ما إذا كان ملف معين يستخدم مخلل أم لا ، أليس كذلك؟ ربما يكون من الجيد الانتقال إلى allow_pickle=False في كلتا الحالتين ، مع فترة وسيطة حيث نصدر نوعًا من تحذير الإهمال بالضبط في الحالات التي يحتاج فيها save أو load بالفعل لاستخدام المخلل و allow_pickle غير محدد.

@ eric-wieser الاختلاف عن مخلل stdlib هو أن load / save يمكنه في الواقع تجنب استخدام المخلل في معظم الحالات (مثل المصفوفات البسيطة للأنواع البدائية) ؛ يستخدم مخلل فقط في الحالات الأكثر غرابة مثل مصفوفات الكائنات أو أنواع معينة معقدة من IIRC. هذا يجعل من الممكن للأشخاص الذين يستخدمون الحافظة الآمنة في الغالب أن يفوتوا وجود الحالة غير الآمنة ، إذا لم يقرأوا المستندات عن كثب بما فيه الكفاية. وعلى أي حال ، نظرًا لأن لدينا "الوضع الآمن" و "الوضع غير الآمن" ، فمن الأفضل أن يكون "الوضع الآمن" هو الوضع الافتراضي. بالنسبة لمخلل stdlib OTOH ، فهو دائمًا غير آمن بنسبة 100٪ بنسبة 100٪ من الوقت ، لذلك لا داعي للقلق بشأن الافتراضات.

بصراحة ، إذا كانت الوظيفة موثقة ومتعمدة ، يمكنني إغلاق BZ بضمير جيد ، خاصة إذا كان الوضع الآمن هو الوضع الافتراضي. لا أعرف كيف نتعامل مع وظائف بايثون. سأرى.

من خلال فحصي للمواصفات ، لا أعتقد أننا نغير أي شيء من المنبع في هذا الصدد.

هل تم الخلاف حول مكافحة التطرف العنيف؟ قد يجعل هذا السيناريو أكثر وضوحًا للقائمين على الصيانة.

يبدو أن CVE مزيف إلى حد كبير. إن قدرة numpy.load تنفيذ تعليمات برمجية عشوائية معروفة وموثقة جيدًا ، وهي ضرورية لتحميل مصفوفات كائن Python المتسلسلة. يمكن للمستخدم أن يمنع تحميل مصفوفات الكائنات عن طريق تمرير allow_pickle=False إلى وظيفة المكتبة هذه.

كان من الأفضل لو كان الوضع الافتراضي هو تحميل مصفوفات الكائن فقط عند طلب ذلك صراحة ، ولكن الأمر كذلك لأسباب تاريخية. تم اقتراح الانتقال من قبل أيضًا ، والمناقشة أعلاه تدور حول كيفية إجراؤه بطريقة لا تؤدي إلى كسر التوافق مع الإصدارات السابقة بشكل لا يمكن السيطرة عليه.

يمكن أن يؤدي الاستخدام المهمل لـ numpy.load ، على غرار ما يحدث في Python pickling ، إلى نقاط ضعف في التطبيقات النهائية.

إن قدرة numpy.load تنفيذ تعليمات برمجية عشوائية معروفة وموثقة جيدًا ، وهي ضرورية لتحميل مصفوفات كائن Python المتسلسلة.

أفضل أن أقول فقط أنه موثق. لقد كنت أستخدم numpy منذ بضع سنوات ، وعلى الرغم من أنني لست مستخدمًا متكررًا لـ numpy.save / numpy.load ، لم يكن واضحًا لي على الإطلاق أن numpy.load يعاني من نفس الثغرة الأمنية التي يعاني منها pickle . بالطبع لم أكن أعلم أن numpy.load قد يستخدم pickle تحت غطاء المحرك (أنا فقط أستخدم المصفوفات الأصلية المكدسة ولم أفكر بها أبدًا ، وهو بالضبط السيناريو الذي ذكره njsmith ).

حقيقة أن pickle معرضة للخطر معروفة جيدًا ، ووثائقها بها تحذير أحمر كبير في الأعلى.

تحذير : الوحدة pickle ليست آمنة ضد البيانات الخاطئة أو التي تم إنشاؤها بشكل ضار. لا تقم مطلقًا بإلغاء انتقاء البيانات الواردة من مصدر غير موثوق به أو غير مصدق عليه.

بالمقارنة ، يبدو أن مستندات numpy.load تشير إلى الجانب الأمني ​​بالكامل كجزء من وصف الكلمة الرئيسية الخاصة بها allow_pickle :

allow_pickle: _ منطقي ، اختياري_
السماح بتحميل صفائف الكائنات المخللة المخزنة في ملفات npy. تشمل أسباب عدم السماح بالمخللات الأمان ، حيث يمكن أن يؤدي تحميل البيانات المخللة إلى تنفيذ تعليمات برمجية عشوائية. إذا تم رفض المخللات ، فسيفشل تحميل صفائف الكائن. الافتراضي: صحيح

لن أكره ذلك إذا تمكنا من وضع تحذير أحمر كبير في وثائق numpy.load ، على الأقل حتى يصبح allow_pickle=False الخيار الافتراضي. حتى يتم إجراء هذا التغيير ، يجب أن يرفع numpy.load نفس العلامات الحمراء في ذهن المرء التي يزيدها pickle.load .

الترحيب بالوثائق العامة مقابل numpy.load

الوثائق لديها الآن تحذير بشأن مخلل

لسوء الحظ ، القاعدة هي أنه بمجرد تعيين رقم CVE ، لم يعد يهم ما إذا كان هناك أي خطأ أم لا ، يتعين على التوزيعات محاولة القيام بشيء ما لإثبات لعملائها أنهم يقدمون القيمة. لست متأكدًا مما سيكون عليه الأمر هنا ، لكن الشركات والأفراد يكافحون دائمًا لإدارة التدفق المستمر لنقاط الضعف ، والأدوات التي يستخدمونها للقيام بذلك لا توفر مجالًا كبيرًا للتواصل مع الفروق الدقيقة ، لذا فهذه هي طريقة الضغط يذهب.

njsmith ليس سيئًا للغاية : سنجعل numpy.load افتراضيًا إلى allow_pickle إلى False ، وهي في الواقع ليست فكرة غبية تمامًا.

الخطر الوحيد الذي أراه مع ذلك هو أن أي مشروع لا يحدد allow_pickle صراحة سوف ينكسر.

ليست مجرد مشروعات المستخدم النهائي التي يجب أن نقلق بشأنها - فأنا قلق من أن تقدم مكتبات المصب mylib.load التي تلتف حول np.load . ستبدأ هذه في الفشل في تحميل صفائف الكائن. سيحدث معهم أحد الأمور الثلاثة:

• تظل مهجورة ، ولن تعمل أبدًا على مصفوفات الكائنات بالطريقة التي اعتادوا عليها. سيجد المستخدمون أن بياناتهم محتجزة كرهينة ، وسيتعين عليهم الرجوع إلى إصدار أقدم لاستعادتها.
• لقد أعادوا إصدار إعداد allow_pickle=True لاستئناف السلوك القديم - وهو المكتبات النهائية التي تشير إلى أنهم يعتقدون أن هذا ليس موجه هجوم يهتمون به. هذا لا يزال يكلفهم إصدار غير متوافق
• سوف يكشفون عن allow_pickle=False في واجهة برمجة التطبيقات الخاصة بهم ، مما يدفع بالمشكلة إلى مجرى النهر.

أفضّل:

• لا تفعل شيئًا مقابل np.save . يعد حدوث تعطل البرنامج النصي طويل المدى في النهاية أثناء حفظ مصفوفة كائنات تجربة مروعة.
• قم بتغيير القيمة الافتراضية في np.load إلى None . اكتشف عدم مرور المستخدم في True أو False صراحة ، وأصدر UserWarning موضحًا المخاطر ، واطلب منهم الاختيار بين الأمان ( False ) والعنصر دعم المصفوفة ( True ). افتراضيا إلى الوضع الراهن بعد إصدار هذا التحذير. أفهم أن المشكلة هنا هي نقص الوعي. ليس أي من الخيارين صحيحًا في جميع الحالات ، لذلك لا أعتقد أننا يجب أن نغير رأينا فجأة بشأن الافتراضي دون سابق إنذار.

@ eric-wieser نقطة جيدة حول ألم تحطم البرنامج النصي. سأكون على استعداد لإعطاء UserWarning بشكل افتراضي.

السؤال هو ماذا نريد أن نفعل على المدى الطويل في load . لست متأكدًا من أنني أحب إجبار الجميع على استخدام kwarg (لإسكات التحذير) ، عندما تكون المصفوفة آمنة. على الرغم من أنه لا يتمتع بميزة عدم وجود خطر منع شخص ما من بياناته ... OTOH ، إذا ظهر التحذير فقط عند التحميل "غير الآمن" ، فقد يكون الأوان قد فات. في الوقت الحالي ، أعتقد أن لدي تفضيلًا طفيفًا لجعل الفترة الانتقالية أطول قليلاً.

OTOH ، إذا لم يظهر التحذير إلا عند التحميل "غير الآمن" ، فقد يكون الوقت قد فات.

إما:

• المكتبة / البرنامج النصي موجود بالفعل وتم نشره - أي شيء نقوم به متأخر جدًا
• المكتبة / البرنامج النصي لا يزال قيد التطوير. يجب أن يرى المطور التحذير أثناء الاختبار المحلي على ملف آمن ، ويجب أن يكون قادرًا على اتخاذ قرار مستنير بشأن السلوك الذي يريده. لهذا السبب ، يجب أن نرسل التحذير حتى لو كانت المصفوفة آمنة (وربما قبل تحميلها ، فقط في حالة وجود مكافئ في Python -Werror set).

نعم ، أنا أوافق بالتأكيد على المكتبات ، لكنني أعتقد أنه قد يكون مزعجًا بعض الشيء للعدد الهائل من البرامج النصية القصيرة.

قم بتغيير الإعداد الافتراضي في 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")

ما زلت أؤيد التحذير عند تحميل بيانات الكائن ، فقد يكون "متأخرًا جدًا" بعض الشيء ، ولكنه يؤدي إلى انتقال أقل ضوضاء. يمكننا إضافة تحذير عند الحفظ (مجرد تحذير دائم). هناك علاقات عامة مفتوحة آمل أن تتحول إلى شيء من هذا القبيل. إذا كنت ترغب في قضاء بعض الوقت في ذلك ، فنحن بشكل عام سعداء بشأن العلاقات العامة.
يبدو لي أنه تحويل نحو بدء دورة الإيقاف قريبًا على أي حال ، وأعتقد أن هذا سيحدث (ولكن سيكون أقرب إذا اختارها شخص ما ؛)). قد تكون هناك فرصة ضئيلة لطلب التأجيل ، لكنني أشك في ذلك ، ومن الصعب معرفة ذلك دون محاولة.

هل يمكنك إغلاق هذه المشكلة كما هو مشار إليه في https://nvd.nist.gov/vuln/detail/CVE-2019-6446 بسبب ذلك لا يزال nexus iq يعتبره عرضة

شكرا @ Manjunath07