غوغل تشرح كيفية تقليص سطح هجوم وحدات معالجة الرسوميات في أندرويد

توصي غوغل بتقليص سطح هجوم وحدات معالجة الرسوميات في أندرويد عبر تقييد أوامر IOCTL التي لا تحتاج إليها التطبيقات في بيئة الإنتاج، بدلاً من الاعتماد فقط على اكتشاف الثغرات الفردية وإصلاحها. وتأتي هذه الممارسة نتيجة تعاون بين فريق Android Red Team وشركة Arm لتحليل وحدة Mali GPU وبرنامج تشغيلها، مع التركيز على منع الوصول إلى الوظائف غير الضرورية باستخدام SELinux.

تكتسب هذه الخطوة أهمية أمنية لأن وحدة معالجة الرسوميات أصبحت هدفاً جذاباً للمهاجمين نظراً إلى تعقيدها وامتلاكها صلاحيات مرتفعة داخل النظام. ووفقاً للمادة، استهدفت غالبية الاستغلالات المعتمدة على برامج تشغيل نواة أندرويد منذ عام 2021 وحدة معالجة الرسوميات، وتركزت الهجمات بصورة أساسية على الواجهة بين برنامج التشغيل في وضع المستخدم، المعروف باسم UMD، وبرنامج التشغيل ذي الصلاحيات المرتفعة في وضع النواة، أو KMD.

لماذا يمثل تقليص سطح الهجوم أولوية؟

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

شمل التحليل المشترك مع Arm برنامج تشغيل Mali المستخدم في نحو 45% من أجهزة أندرويد، وساعد على تحديد أجزاء من سطح الهجوم تمثل مخاطر أمنية لكنها ليست مطلوبة لتشغيل الأجهزة في الإنتاج. وبناءً على ذلك، ركزت السياسة على أوامر IOCTL، التي تمثل مدخلات ومخرجات برنامج تشغيل وحدة معالجة الرسوميات، وبالتالي جزءاً مهماً من سطح الهجوم.

تقسم أوامر Mali في النهج المقترح إلى ثلاث فئات:

• الأوامر غير المقيّدة: مطلوبة للتشغيل الطبيعي، وتظل متاحة للتطبيقات.
• أوامر القياس والأدوات: تستخدمها أدوات تحليل الأداء والتصحيح لمراقبة أداء وحدة معالجة الرسوميات.
• الأوامر المقيّدة: لا يفترض أن تستخدمها تطبيقات الإنتاج، وتشمل أوامر مخصصة لتطوير وحدة معالجة الرسوميات، إضافة إلى أوامر قديمة لم تعد مستخدمة في إصدار UMD الحالي للجهاز.

تهدف السياسة إلى حجب الأوامر القديمة وأوامر التصحيح في بيئة الإنتاج، مع قصر أوامر القياس على الصدفة أو التطبيقات التي تحمل علامة القابلية للتصحيح. أما أوامر الإنتاج فتبقى متاحة للتطبيقات العادية.

طرح تدريجي لسياسة SELinux

اعتمدت غوغل نهجاً تدريجياً لتقليل احتمال تعطيل التطبيقات المشروعة. بدأت العملية بسياسة اختيارية، وأنشأت سمة SELinux جديدة باسم gpu_harden تمنع أوامر القياس، ثم طبقتها على مجموعة محددة من تطبيقات النظام لاختبار أثرها. وخلال هذه المرحلة، استخدمت قاعدة allowxperm لتسجيل محاولات الوصول بدلاً من منعها مباشرة، ثم راقبت سجلات الرفض للتحقق من عدم حدوث أعطال.

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

• تشغيل التطبيق على جهاز ذي صلاحيات root.
• تعيين الخاصية android:debuggable="true" في ملف بيان التطبيق.
• طلب استثناء دائم في سياسة SELinux الخاصة بالتطبيق.

خطوات تطبيق السياسة على الأجهزة

تقدم غوغل الإرشادات لمساعدة الشركاء والمنظومة الأوسع على تبني آلية مماثلة، مع فصل منطق السياسة العامة عن تفاصيل كل جهاز أو برنامج تشغيل. تبدأ العملية باستخدام وحدة ماكرو عامة على مستوى منصة أندرويد ضمن system/sepolicy. وتوجد هذه الوحدة في ملف /sepolicy/public/te_macros، وتتيح لسياسات الأجهزة تمرير قوائم أوامر IOCTL التي ينبغي تصفيتها.

صممت الوحدة للسماح لجميع التطبيقات، أو appdomain، بالوصول إلى قائمة الأوامر غير المقيّدة، وقصر أوامر القياس الحساسة على أدوات التصحيح مثل shell أو runas_app عندما يكون التطبيق قابلاً للتصحيح. كما تحجب الأوامر ذات الصلاحيات المرتفعة اعتماداً على إصدار SDK المستهدف للتطبيق، مع الحفاظ على التوافق مع التطبيقات الأقدم.

بعد ذلك، ينشئ مطور الجهاز ملف ioctl_macros داخل مجلد سياسة SELinux الخاص بالجهاز، مثل device/your_company/your_device/sepolicy/ioctl_macros، ثم يعرّف قوائم الأوامر الخاصة ببرنامج تشغيل وحدة معالجة الرسوميات. توصي غوغل بوجود قوائم منفصلة على الأقل للأوامر الإنتاجية، وأوامر القياس، وأوامر التصحيح، على أن تتضمن أرقام IOCTL السداسية العشرية الخاصة ببرنامج التشغيل.

قدمت Arm تصنيفاً رسمياً لأوامر IOCTL الخاصة بها في الملف Documentation/ioctl-categories.rst ضمن الإصدار r54p2، مع الإشارة إلى أن القائمة ستستمر في التحديث مع إصدارات برامج التشغيل المستقبلية.

الاختبار قبل الفرض

في الخطوة التالية، تُطبَّق السياسة على عقدة جهاز وحدة معالجة الرسوميات من خلال إنشاء ملف gpu.te في مجلد سياسة الجهاز، ثم استدعاء وحدة الماكرو العامة وتمرير وسم الجهاز وقوائم IOCTL المعرفة مسبقاً.

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

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