robertdfrench/ifuncd-upGNU IFUNC هو الجاني الحقيقي وراء CVE-2024-3094
أراكم أيها المهرجون على [الموقع البرتقالي][hn] تعطونني وقتًا عصيبًا. سأقدّم بعض الردود المختارة أدناه، لكن أولاً أطرح تحديًا: سأرسل 500 دولار من مالي الخاص لأول شخص يستطيع إثبات هذا الهجوم بدون ifunc. أنا مهتم حقًا، ومستعد للدفع مقابل التنوير. اعمل fork لهذا المستودع وقدّم PR مع PoC يعمل، وسأطلب عنوانك البريدي بشكل خاص إذا فزت. الآن للردود:
هذا ينبح على الشجرة الخطأ.
يا صغيري، أنا أعيش في الشجرة الخطأ، أستطيع النباح على من أريد.
لم يكن ضروريًا للاستغلال،
أنت لست ضروريًا للاستغلال!
هناك دائمًا selinux إذا أردنا إضافة حماية ضد تشغيل كود عشوائي كـ root.
بمجرد تحميله، لم يكن هذا الهجوم بحاجة لتجاوز أي حدود syscall أخرى. لذا نعم، كان بإمكاننا تقييد جلسة root "إضافية"، لكن كان لا يزال لدينا ضيوف غير مدعوين على الجهاز!
ما هذا، عيد ميلاد بيلبو؟؟ لا دخول إلا لأعمال الحفلة!!
- IFUNC بالكاد هي الطريقة الوحيدة لتشغيل كود قبل main.
لكنها طريقة غير ضرورية لتشغيل كود قبل إعداد حماية الذاكرة
- البديل الذي يقدمونه أقل أمانًا على الأرجح لأن مؤشر الدالة سيبقى قابلًا للكتابة طوال عمر العملية،
يمكننا التصرف بـ mprotect! انظر الجملة الأخيرة أعلاه في القسم الفرعي Modifying LD_PRELOAD.
أجل، هذه المدونة مضللة.
معذرة، هذه المدونة كانت غير موجهة. لقد قمت بكل هذه المقالب بنفسي! لم يخدعني أحد لأكون بهذا الغباء.
يجب أن يتم تنفيذ IFUNC بواسطة برنامج [العميل] نفسه،
@CountWSS 💯 نعم بالتأكيد
سلسلة من إخفاقات العمليات الصارخة من مشرف Github عبر ...
هذه هي النقطة الوحيدة التي سأرد عليها بجدية:
أعتقد أنه من غير العادل للغاية تجاه مشرف xz-utils ومن الخطير جدًا للمجتمع أن نفكر في هذا على أنه بدأ بخطأ من جانبه. لقد بدأ بعدم اهتمام أي شخص بمساعدة هذا المشروع. اعتمد المهاجم على ifunc كـ ثغرة تقنية وعلى إهمالنا الجماعي لـ xz-utils كـ ثغرة اجتماعية. أعتقد أنه من المخجل رؤية تصرفات السيد Collin على أنها أي شيء آخر غير تفانٍ بطولي استمر لسنوات في خدمة المجتمع.
أيضًا Bruce Schneier يوافقني الرأي لذا... أكره ذلك لك، حجتك انتهت.
ربما كانت اللغة أقسى مما ينبغي
لن تصدق كم جعلني أصدقائي أخفف هذا أولاً.
يجب ألا تظن توزيعات Linux بنفسها كثيرًا لدرجة توقع أن تتوافق OpenBSD وتتكيف مع فوضاهم
@debazel!!! Me gusta.
يا له من هراء كامل.
حسنًا، هذا الجزء دقيق.
لماذا يجب أن تتوقف عن لوم xz-utils على [CVE-2024-3094][nvd]. أيضًا تحقق من محادثتي في ETSA!
CVE-2024-3094، المعروف أكثر باسم "باب خلفي xz-utils"، كان إخفاقًا بفارق ضئيل للأمن السيبراني العالمي. لو لم يُكتشف هذا الهجوم في اللحظة الحرجة بواسطة [Andres Freund][freund]، لكانت معظم خوادم SSH على كوكبنا قد بدأت بمنح وصول root للطرف الذي يقف خلف هذا الهجوم.
للأسف، ركز الكثير من التحليل على كيفية وصول [الكود الخبيث][JiaT75] إلى مستودع xz-utils. بدلاً من ذلك، أود أن أجادل بأن قرارين تصميميين قديمين في البرمجيات مفتوحة المصدر الحرجة هما ما جعلا هذا الهجوم ممكنًا: [ربط OpenSSH بـ SystemD][biebl]، ووجود [GNU IFUNC][sourceware].
قبل أن تبدأ: يتناول الكثير من هذه المناقشة تعقيدات
الربط الديناميكي على Linux. إذا كنت بحاجة إلى مراجعة، تحقق من
dynamic_linking.md.
هناك الكثير من الكتابات الجيدة التي توضح التفاصيل عالية المستوى لباب xz-utils الخلفي، مثل [What we know about the xz Utils backdoor that almost infected the world][goodin1] لـ Dan Goodin و [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam] لـ Sam James. لا نحتاج لإعادة سرد كل ذلك هنا، لذا لأغراض هذا المقال، إليك مراجعة خشنة جدًا:
## لماذا تُعدّل توزيعات لينكس OpenSSH؟
الإجابة المختصرة هي أنه لا بدّ لها من ذلك. يُطوَّر OpenSSH بواسطة
مجتمع OpenBSD، ومن أجل مجتمع OpenBSD، وهم لا يبالون كثيرًا بشأن لينكس. مشروع [Portable OpenSSH][mindrot] هو
مجموعة من الرقع المبذولة بأفضل جهد ممكن والتي تستبدل
المكوّنات الخاصة بـ OpenBSD بمكوّنات POSIX عامة، وبعض
الشيفرة الخاصة بمنصات معينة حيث ينطبق ذلك. سلسلة توريد البرمجيات
الخاصة بـ SSH تنتهي في الممارسة العملية إلى شيء يشبه هذا:```mermaid
flowchart TD
subgraph OpenBSD Folks
A[OpenBSD]
B[OpenSSH]
H[improvements]
end
B-->A
A-->H
H-->B
B-->C
C[Portable OpenSSH]
subgraph Debian Folks
D[Debian SSH]
G[improvements]
end
C-->D
D-->G
G-->C
subgraph Fedora Folks
J[Fedora SSH]
K[improvements]
end
C-->J
J-->K
K-->C
نسخة OpenBSD من OpenSSH هي المصدر الأساسي لكل ما عداها، ومعظم التحسينات عليها تأتي من داخل مجتمع OpenBSD. تتدفق هذه التغييرات إلى مشروع Portable OpenSSH، الذي يحاول إعادة تنفيذ الميزات الجديدة بطرق غير خاصة بـ OpenBSD. هذا ما يسمح لـ SSH بالعمل على منصات مثل Linux وmacOS وFreeBSD وحتى Windows.
لكن الأمر لا يتوقف عند هذا الحد. بعض أنظمة التشغيل تطبق تخصيصات إضافية تتجاوز ما يوفره Portable OpenSSH. على سبيل المثال، تضيف Apple العلامة [--apple-use-keychain][keith] إلى ssh-add لمساعدته على التكامل مع مدير كلمات المرور في macOS.
في حالة CVE-2024-3094، احتفظت Fedora وDebian بـ[تصحيحات SystemD][biebl] الخاصة بهما لنسخهما المتفرعة من OpenSSH من أجل إصلاح [حالة تسابق حول إعادة تشغيل sshd][schmidt]. لذا بدأت سلسلة التوريد الفعلية لـ SSH تبدو هكذا:```mermaid
flowchart TD
A[OpenSSH]
B[Portable OpenSSH]
C[Debian SSH]
D[Fedora SSH]
A-->B
B-->C
B-->D
C<-->|SystemD Patches|D
لم تدخل هذه التصحيحات أبدًا إلى Portable OpenSSH، لأن مسؤولي
Portable OpenSSH كانوا ["غير مهتمين بتحمّل تبعية على
libsystemd"][djmdjm]. ولم تدخل أبدًا إلى OpenSSH الأصلي، لأن
OpenBSD لا تحتاج إلى دعم SystemD.
### مخاوف بشأن "فصل الاهتمامات"
يبدو هذا غير ضار بما يكفي، لكنه مثال على مشكلة أكبر بكثير
في المصادر المفتوحة، وتحديدًا في Linux: المكوّنات الحيوية لنظام
التشغيل يطوّرها أشخاص لا يعرف بعضهم بعضًا، ولا يتحدثون مع بعضهم البعض.
* هل كان الأشخاص الذين قاموا بترقيع OpenSSH من أجل SystemD يعرفون (أو يهتمون) بأن
libsystemd تعتمد على xz-utils؟
* هل كان مسؤولو SystemD يعرفون (أو يهتمون) بأن xz-utils قد بدأت باستخدام
ifunc؟
* هل كان مسؤولو OpenSSH يعرفون (أو يهتمون) بأن ifunc كان شيئًا موجودًا؟ إنه
بالتأكيد ليس شيئًا موجودًا على OpenBSD.
بمعنى ما، يُعدّ هذا الانقطاع في التواصل سمة من سمات المصادر
المفتوحة: يمكنني تكييف عملك وفق احتياجاتي دون الحاجة إلى إزعاجك
بشأن ذلك. لكنه قد يؤدي أيضًا إلى درجة من الإحالة غير المباشرة تمنع
الحفاظ على افتراضات التصميم الحيوية (مثل عملية الربط الديناميكي التقليدية).
النتيجة البديهية لـ[قانون كونواي][conway] هي أنه إذا كنت
تنشر مخططك التنظيمي، فأنت تنشر أيضًا الأخطاء التي تعيش في
شقوق مخططك التنظيمي. لم يرتكب أي شخص أو فريق خطأً حقيقيًا
هنا، لكن مع إدراك لاحق يتضح أن المهاجمين
أدركوا أن اليد اليسرى لـ Debian/Fedora SSH لم تكن تعرف ما كانت
تفعله اليد اليمنى لـ xz-utils.
## ما الذي *يُفترض* أن يفعله GNU IFUNC؟
يتيح لك تحديد، في وقت التشغيل، أي إصدار من دالة ما
تريد استخدامه. ويفعل ذلك بمنحك فرصة لتشغيل **كود عشوائي**
للتأثير على كيفية قيام الرابط بحل الرموز.
