<p>Virtualenv Sandbox الهروب</p>

تم تعيين CVE-2018-17793 لهذه المشكلة (لم

هل يمكنك شرح التأثير الأمني ​​هنا من فضلك؟ لا يبدو لي أن استدعاء bash للعودة إلى الغلاف الطبيعي يمثل نقطة ضعف بالنسبة لي. لا أعتقد أن أي شخص كان لديه انطباع بأن Virtualenv يسمح لك بتشغيل أوامر shell غير موثوق بها بأمان ، وهذا ليس الغرض منه.

طلبت من MITER رفض CVE

عادي كالتالي:
(test_env) r0ot # python $ (sh 1> & 2)
(test_env) r0ot #
(test_env) r0ot # python
Python 2.7.15 (افتراضي ، 1 مايو 2018 ، 05:55:50)
[GCC 7.3.0] على linux2
اكتب "مساعدة" أو "حقوق طبع ونشر" أو "ائتمانات" أو "ترخيص" لمزيد من المعلومات.

استيراد نظام التشغيل
os.system ("$ (sh 1> & 2)")
(test_env) r0ot #
إذا قمت بتنفيذ تعليمات برمجية ضارة:
(test_env) r0ot # python $ (bash> & 2)
r0ot #
POC:
(test_env) r0ot # python
Python 2.7.15 (افتراضي ، 1 مايو 2018 ، 05:55:50)
[GCC 7.3.0] على linux2
اكتب "مساعدة" أو "حقوق طبع ونشر" أو "ائتمانات" أو "ترخيص" لمزيد من المعلومات.
استيراد نظام التشغيل
os.system ("$ (bash> & 2)")
r0ot #

إذا قمت بتنفيذ تعليمات برمجية ضارة

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

PYTHON في وضع الحماية ليس آمنًا بنسبة 100٪ ، ويمكن أن تؤدي الثغرات الأمنية إلى تجاوز حماية وضع الحماية. ما هي أسباب استخدام الصندوق الرمل؟
إذا كان من الصعب إصلاح وضع الحماية ، فمن المستحسن تجنب المخاطر في الكود والمطالبة في وصف وضع الحماية.

@ BakedPotato999 Python في Virtualenv "sandbox" آمنة بنسبة 0٪ ؛ إنه ليس مصممًا ولا يوفر أي حماية ضد التعليمات البرمجية الضارة. يبدو أنك مرتبك للغاية بشأن الغرض من virtualenv.

@ BakedPotato999 Python في Virtualenv "sandbox" آمنة بنسبة 0٪ ؛ إنه ليس مصممًا ولا يوفر أي حماية ضد التعليمات البرمجية الضارة. يبدو أنك مرتبك للغاية بشأن الغرض من virtualenv.

أعتقد أن التطبيقات التي تعمل في برنامج Virtualenv هذا مستقلة ولن تؤثر على نظام التشغيل الحالي لديك. سيؤدي إغلاق صندوق الحماية إلى استعادة جميع العمليات. باستخدام Sandbox ، يمكنك اختبار البرامج والبرامج التي قد تكون محفوفة بالمخاطر. هل هذا صحيح؟

كلا ، خاطئ تمامًا. الغرض من virtualenv هو السماح لك باستخدام مترجم Python ومجموعة من حزم Python (بدلاً من الحزم المثبتة على النظام و userdir) لتشغيل البرامج في بيئة عادية.

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

ولا يجب أن يمنعك أي شيء من القيام بذلك. يجب أن يكون مترجم Python في virtualenv قادرًا على القيام بجميع العمليات التي يمكن لمترجم Python للنظام (إن وجد) القيام به عند تشغيله بواسطة نفس المستخدم. القيام بخلاف ذلك من شأنه كسر العديد من الاستخدامات الشائعة والمتوقعة لـ virtualenv.

@ BakedPotato999 virtualenv/bin/activate يضع ملف Python القابل للتنفيذ في البيئة الافتراضية في وقت مبكر من مسارك . إنها ليست مصممة للأمن.

سأغلق هذا على أنه غير صالح.

أنا فقط أتساءل ، كيف أتيت بكون Virtualenv sandbox @ BakedPotato999 ؟

لقد بحثت من خلال مستندات، جيثب ومع git grep وفقط sandbox قوع هذا هو واحد:

كتب جيمس جاردنر درسًا تعليميًا حول استخدام virtualenv مع Pylons.

الذي يربط بـ http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox (الذي يحتوي على sandbox في عنوان url).

بالمناسبة ، عنوان url ميت وهو هنا https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

؛).

إن حقيقة وجود "استغلال" الآن https://www.exploit-db.com/exploits/45528/ وأن متتبعات الأمان الخاصة بالتوزيعات الرئيسية تتعامل مع هذا الأمر على أنه قابلية للتضخم أمر مضحك إلى حد ما.

أعتقد أننا قد نكون قادرين على استخدام هذا كتصعيد امتياز ، سأحاول ذلك بالفعل

0 يوم مؤكد! :د

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

@ 0cjs لقد أثبتت للتو أنه يمكن استخدامه للوصول إلى الجذر ، كيف لا يعد ذلك ثغرة أمنية؟

1. لا يمكنني رؤية دليل في لقطة الشاشة الخاصة بك على أنك استخدمت أي شيء متعلق بـ virtualenv للوصول إلى الجذر. من المثير للريبة أنه يذكر ما يبدو أنه تثبيت Ruby Version Manager في root منزل هناك أيضًا ، على الرغم من وجود تفسيرات لذلك يتوافق مع استغلال حقيقي.
2. لا يمكنني التفكير في آلية معقولة لفعل ما فعلته خارج نطاق استغلال شيء ما خارج Virtualenv ، نظرًا لأن Virtualenv ليس لديه ولا يستخدم ملفات suid أو ملفات مماثلة ، ولا يفترض في أي وقت امتيازات أي مستخدم آخر غير المستخدم الذي يقوم بتشغيله. (أنا لا أقول أن الآلية غير موجودة ، لكنك تحتاج إلى تقديم بعض المؤشرات على الأقل عن مكان وجود هذه المشكلة. إذا أبلغت عنها بطريقة مسؤولة ، فعليك أن تقول ذلك ، ولمن ذكرت ذلك.)

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

@ 0cjs لقد قمت بالفعل نجح ، ما زلت أختبر للتأكد من أنه لم يكن بسبب نظام قديم ، أنا في الواقع أوافق على أنه كان استغلالًا مختلفًا للنواة والذي حدث لإظهار نفسه داخل Virtualenv ، مرة واحدة مرة أخرى الاختبار لا يزال.

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

لم أبلغ عن أي شيء ...؟

الجذر kali : ~ / test_env # python $ (bash> & 2)

رائع ، هذا رائع ، لكن لا تحتاج حقًا إلى استخدام $ () ... يمكنك فقط ...

الجذر @ كالي : ~ / test_env # echo "هذا دجل"

"لتجاوز" آليات وضع الحماية لـ virtualenv.

@ BakedPotato999 لقد تمكنت من الانتقال من تنفيذ كود Python التعسفي (أو غيره) كجذر. ما الذي تقترحه هو مشكلة أمنية تنبثق من الحالة السابقة إلى الحالة الأخيرة؟

واو ، يا لها من قضية خطيرة. كيف يمكنني استخدام برنامج يُقصد به القيام بشيء واحد إذا كان لا يمكنه القيام بشيء آخر بشكل آمن؟ يرجى تقديم النصيحة.

ednix liveoverflow؟

ednix لا يمكنك. يجب عليك عدم استخدام غلاف Unix مرة أخرى لأنه لا يمكن استخدامه بأمان لبعض الأغراض.

في الواقع ، دعونا لا نستخدم أجهزة الكمبيوتر مرة أخرى. إنها أشياء خطيرة ، ويمكن استخدامها لأغراض عديدة.

في الواقع ، ذكرتني هذه "المشكلة" أنه قد يكون من الممكن استخدامها لمعالجة https://github.com/pypa/virtualenv/issues/1334 - هل لدى أي شخص رمز POC يمكننا البدء به؟

يوفر Nexus by Sonatype وكيلاً لـ pypi.org. يسمح الوكيل بعزل أي حزمة ذات نقاط ضعف تتجاوز حدًا معينًا.

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

آسف إذا كان هذا يوضح ما هو واضح ولكن هذه المشكلة تؤثر علي بشكل مباشر.

قام MITER بتعيين CVE على متنازع عليه. ربما يمكنك الحصول على Sonatype لتكريم هذه المعلومات.

في الواقع ، دعونا لا نستخدم أجهزة الكمبيوتر مرة أخرى. إنها أشياء خطيرة ، ويمكن استخدامها لأغراض عديدة.

لا يجب أن نعيش على الإطلاق ، فالحياة خطرة