قبل أيام قليلة صدرت النبأ في مكتبات C القياسية uClibc و uClibc-ng، المستخدمة في العديد من الأجهزة المدمجة والمحمولة ، تم تحديد ثغرة أمنية (مع عدم تعيين CVE بعد) ، مما يسمح باستبدال البيانات الوهمية في ذاكرة التخزين المؤقت لنظام أسماء النطاقات ، والتي يمكن استخدامها لانتحال عنوان IP لمجال عشوائي في ذاكرة التخزين المؤقت وإعادة توجيه الطلبات إلى المجال إلى خادم المهاجم.
حول المشكلة ذكر أن هذا يؤثر على برامج Linux المختلفة لأجهزة التوجيه ونقاط الوصول وأجهزة إنترنت الأشياء ، بالإضافة إلى توزيعات Linux المضمنة مثل OpenWRT و Embedded Gentoo.
حول الضعف
عالي التأثر يرجع ذلك إلى استخدام معرفات المعاملات التي يمكن التنبؤ بها في الكود لإرسال الاستعلامات من DNS. تم اختيار معرّف استعلام DNS ببساطة عن طريق زيادة العداد دون مزيد من التوزيع العشوائي لأرقام المنافذ ، والتي جعل من الممكن إفساد ذاكرة التخزين المؤقت لنظام أسماء النطاقات عن طريق إرسال حزم UDP بشكل استباقي مع استجابات وهمية (سيتم قبول الاستجابة إذا وصلت قبل الاستجابة من الخادم الحقيقي وتتضمن التعريف الصحيح).
على عكس طريقة Kaminsky المقترحة في عام 2008 ، ليس من الضروري حتى تخمين معرّف المعاملة ، لأنه يمكن التنبؤ به في البداية (في البداية ، يتم ضبطه على 1 ، والذي يزيد مع كل طلب ، ولا يتم اختياره عشوائيًا).
لحماية نفسك ضد تخمين الهوية ، المواصفات توصي كذلك باستخدام التوزيع العشوائي لأرقام منافذ الشبكة المصدر الذي يتم من خلاله إرسال استعلامات DNS ، مما يعوض عن الحجم غير الكافي للمعرف.
عند تمكين التوزيع العشوائي للمنافذ ، لتشكيل استجابة وهمية ، بالإضافة إلى تحديد معرف 16 بت ، من الضروري أيضًا تحديد رقم منفذ الشبكة. في uClibc و uClibc-ng ، لم يتم تمكين هذا التوزيع العشوائي بشكل صريح (عندما تم استدعاء الربط ، لم يتم تحديد منفذ UDP المصدر العشوائي) وكان تنفيذه يعتمد على تكوين نظام التشغيل.
عندما يتم تعطيل المنفذ العشوائي ، تحديد معرّف الطلب المراد زيادة قيمته كمهمة تافهة. ولكن حتى في حالة التوزيع العشوائي ، يحتاج المهاجم فقط إلى تخمين منفذ الشبكة من النطاق 32768-60999 ، والذي يمكنه من أجله استخدام إرسال استجابات وهمية ضخمة ومتزامنة على منافذ شبكة مختلفة.
المشكلة تم تأكيده في جميع الإصدارات الحالية من uClibc و uClibc-ng، بما في ذلك أحدث إصدارات uClibc 0.9.33.2 و uClibc-ng 1.0.40.
كتب الفريق في مدونة هذا الأسبوع: "من المهم ملاحظة أن الثغرة الأمنية التي تؤثر على مكتبة C القياسية يمكن أن تكون معقدة للغاية".
"لن يكون هناك فقط مئات أو آلاف المكالمات للوظيفة المعرضة للخطر في نقاط متعددة في برنامج واحد ، ولكن الثغرة الأمنية ستؤثر على عدد غير محدد من البرامج الأخرى متعددة البائعين المهيأة لاستخدام تلك المكتبة."
في سبتمبر 2021 ، تم إرسال معلومات حول الثغرة الأمنية إلى CERT / CC لإعداد مجموعة منسقة. في يناير 2022 ، تمت مشاركة المشكلة مع أكثر من 200 مصنع المرتبطة بـ CERT / CC.
في آذار (مارس) ، كانت هناك محاولة للاتصال بشكل منفصل بمشرف مشروع uClibc-ng ، لكنه رد بأنه لا يمكنه إصلاح الثغرة الأمنية بنفسه وأوصى بالكشف العام عن المعلومات حول المشكلة ، على أمل الحصول على مساعدة في تطوير إصلاح. المجتمع. أعلنت NETGEAR عن إصدار تحديث مع إزالة الثغرة الأمنية من الشركات المصنعة.
من المهم ملاحظة أن الثغرة الأمنية التي تؤثر على مكتبة C القياسية يمكن أن تكون معقدة للغاية. لن يكون هناك فقط مئات أو آلاف المكالمات للوظيفة المعرضة للخطر في نقاط متعددة في برنامج واحد ، ولكن الثغرة الأمنية ستؤثر على عدد غير محدد من البرامج الأخرى من بائعين متعددين تم تكوينهم لاستخدام تلك المكتبة.
وتجدر الإشارة إلى أن الثغرة الأمنية تتجلى في الأجهزة من العديد من الشركات المصنعة (على سبيل المثال ، يتم استخدام uClibc في البرامج الثابتة من Linksys و Netgear و Axis) ، ولكن نظرًا لأن الثغرة الأمنية لا تزال غير مصححة في uClibc و uClibc-ng ، فإن المعلومات التفصيلية حول الأجهزة ومحددة الشركات المصنعة التي توجد مشكلة في منتجاتها ، حتى يتم الكشف عنها.
أخيرا إذا كنت مهتمًا بمعرفة المزيد عنها، يمكنك التحقق من التفاصيل في الرابط التالي.