ثغرة أمنية خطيرة في تنفيذ وظيفة memcpy لـ ARMv7 من Glibc

باحثو الأمن في سيسكو مكشوفة التفاصيل نقاط الضعف (CVE-2020-6096) في تنفيذ وظيفة memcpy() المقدمة من Glibc لمنصة ARMv32 ذات 7 بت. ترجع المشكلة إلى المعالجة غير الصحيحة للقيم السالبة للمعلمة التي تحدد حجم المساحة المنسوخة، وذلك بسبب استخدام تحسينات التجميع التي تعالج الأعداد الصحيحة 32 بت الموقعة. يؤدي استدعاء memcpy() على أنظمة ARMv7 ذات الحجم السلبي إلى مقارنة غير صحيحة للقيم والكتابة في منطقة خارج حدود المخزن المؤقت المحدد.

يمكن استغلال الثغرة الأمنية لتنفيذ تعليمات برمجية في موقف يستطيع فيه المهاجم تنظيم تكوين قيمة سالبة للمتغير الذي يتم من خلاله نقل حجم البيانات المنسوخة (على سبيل المثال، سيصبح سلبيًا عند نقل أكثر من 2 جيجابايت من البيانات) البيانات، ولكن أثناء الهجوم، لتجاوز حدود المخزن المؤقت، تحتاج إلى نقل ما لا يقل عن 4 جيجابايت). تُستخدم وظيفة memcpy() على نطاق واسع في التطبيقات، كما أن معالجات ARMv7 شائعة في أنظمة السيارات والأجهزة المحمولة والصناعية والاستهلاكية والاتصالات والأجهزة المدمجة، والتي من المحتمل أن تكون عرضة للهجمات باستخدام Bluetooth وHD Radio/DAB وUSB وCAN bus و شبكة Wi-Fi يمكن مهاجمة مصادر البيانات الخارجية الأخرى (على سبيل المثال، الخدمات والتطبيقات التي يمكن الوصول إليها عبر الشبكة والتي تقبل بيانات الإدخال دون قيود الحجم).

ومن الأمثلة على ذلك إنشاء استغلال عملي لمهاجمة خادم HTTP مدمج في أنظمة معلومات السيارات، ويمكن الوصول إليه عبر شبكة Wi-Fi للسيارة. يمكن لمهاجم خارجي استغلال ثغرة memcpy على هذا الخادم عن طريق إرسال طلب GET كبير جدًا والحصول على حق الوصول إلى الجذر للنظام.

ثغرة أمنية خطيرة في تنفيذ وظيفة memcpy لـ ARMv7 من Glibc

في أنظمة 32 بت x86، لا تظهر المشكلة، نظرًا لأن تطبيق memcpy لهذه البنية يفسر بشكل صحيح متغير الحجم كقيمة عددية غير موقعة من النوع size_t (في لغة التجميع تطبيق بالنسبة إلى ARMv7، يتم التعامل معه على أنه عدد صحيح موقّع بدلاً من size_t). الإصلاح متاح حاليا باسم رقعة، والذي سيتم تضمينه في تحديث Glibc 2.32 لشهر أغسطس.
يتلخص الإصلاح في استبدال استخدام تعليمات التجميع التي تعمل على المعاملات الموقعة (bge وblt) بنظيراتها غير الموقعة (blo وbhs).

لم يتم حل المشكلة بعد ديبيان 9 و 10 (غير مرئي في دبيان 8)، فيدورا, أوبونتو، OpenEmbedded، Tizen (يستخدمه glibc). RHEL и SUSE لا تتأثر المشكلة لأنها لا تدعم أنظمة 32 بت ARMv7. لا يتأثر Android بالثغرة الأمنية لأنه يستخدم تطبيق libc (Bionic) الخاص به. في OpenWRT افتراضيًا، تستخدم معظم الإصدارات Musl، لكن glibc متاح أيضًا في المستودع.

المصدر: opennet.ru

إضافة تعليق