فريق أمان Android مسؤول عن إدارة الثغرات الأمنية المكتشفة في نظام Android الأساسي والعديد من تطبيقات Android الأساسية المجمعة مع أجهزة Android.
يكتشف فريق أمان Android ثغرات أمنية من خلال البحث الداخلي ويستجيب أيضًا للأخطاء التي أبلغت عنها جهات خارجية. تتضمن مصادر الأخطاء الخارجية المشكلات التي تم الإبلاغ عنها من خلال نموذج Android Security Issue ، والبحث الأكاديمي المنشور والمنشور مسبقًا ، ومسؤولو صيانة المشروعات الأولية ، والإشعارات من شركائنا في تصنيع الأجهزة ، والمشكلات التي تم الكشف عنها علنًا على المدونات أو وسائل التواصل الاجتماعي.
الإبلاغ عن مشكلات الأمان
يمكن لأي مطور أو مستخدم Android أو باحث أمني إخطار فريق أمان Android بمشكلات الأمان المحتملة من خلال نموذج الإبلاغ عن الثغرات الأمنية .
الأخطاء التي تم تمييزها على أنها مشكلات أمنية ليست مرئية خارجيًا ، ولكن قد تظهر في النهاية بعد تقييم المشكلة أو حلها. إذا كنت تخطط لإرسال اختبار تصحيح أو اختبار مجموعة اختبار التوافق (CTS) لحل مشكلة أمنية ، فيرجى إرفاقه بتقرير الخطأ وانتظر الرد قبل تحميل الرمز إلى AOSP.
فرز البق
تتمثل المهمة الأولى في التعامل مع الثغرة الأمنية في تحديد مدى خطورة الخطأ والمكوّن المتأثر في Android. تحدد درجة الخطورة كيفية تحديد أولوية المشكلة ، ويحدد المكون من يصلح الخطأ ومن يتم إخطاره وكيف يتم نشر الإصلاح للمستخدمين.
أنواع العمليات
يغطي هذا الجدول تعريفات أنواع العمليات. يمكن تحديد نوع العملية حسب نوع التطبيق أو العملية أو المنطقة التي يتم تشغيلها فيها. تم ترتيب هذا الجدول من الأقل إلى الأكثر امتيازًا.
نوع العملية | تعريف النوع |
---|---|
عملية مقيدة | عملية تعمل في مجال SELinux محدود للغاية. أو عملية محدودة بشكل ملحوظ أكثر من التطبيق العادي. |
عملية غير مميزة | تطبيق أو العملية التي يعمل في مجال سيلينو مع untrusted_app_all السمة، أو يقتصر مكافئ. |
عملية مميزة | تطبيق أو عملية بإمكانيات يحظرها مجال SELinux untrusted_app .أو تطبيق أو عملية بامتيازات مهمة لا يمكن لتطبيق جهة خارجية الحصول عليها. أو مكون جهاز مدمج بالجهاز ليس جزءًا من قاعدة الحوسبة الموثوقة (TCB). |
قاعدة الحوسبة الموثوقة (TCB) | الوظيفة التي هي جزء من kernel ، تعمل في نفس سياق وحدة المعالجة المركزية مثل kernel (مثل برامج تشغيل الأجهزة) ، ولها وصول مباشر إلى ذاكرة kernel (مثل مكونات الأجهزة على الجهاز) ، ولديها القدرة على تحميل البرامج النصية في مكون kernel ( على سبيل المثال ، eBPF) ، أو معالج النطاق الأساسي ، أو إحدى خدمات المستخدم التي تعتبر مكافئة لـ kernel: apexd و bpfloader و init و ueventd و vold . |
الإقلاع | مكون يقوم بتكوين الجهاز عند بدء التشغيل ثم يقوم بتمرير التحكم إلى نظام تشغيل Android. |
بيئة تنفيذ موثوقة (TEE) | مكون مصمم للحماية حتى من نواة معادية (على سبيل المثال ، TrustZone و Hypervisor). |
عنصر آمن (SE) | مكون اختياري مصمم للحماية من جميع المكونات الأخرى على الجهاز ومن الهجوم المادي ، كما هو محدد في مقدمة إلى العناصر الآمنة . |
خطورة
تعكس شدة الخطأ عمومًا الضرر المحتمل الذي يمكن أن يحدث إذا تم استغلال الخطأ بنجاح. استخدم المعايير التالية لتحديد مدى الخطورة.
تقييم | نتيجة الاستغلال الناجح |
---|---|
حرج |
|
عالي |
|
معتدل |
|
منخفض |
|
تأثير أمني ضئيل (NSI) |
|
معدلات التصنيف
على الرغم من سهولة التعرف على شدة الثغرات الأمنية ، فقد تتغير التصنيفات بناءً على الظروف.
السبب | تأثير |
---|---|
يتطلب التشغيل كعملية ذات امتياز لتنفيذ الهجوم | -1 الشدة |
التفاصيل الخاصة بالثغرات الأمنية تحد من تأثير المشكلة | -1 الشدة |
تجاوز المصادقة البيومترية التي تتطلب معلومات بيومترية مباشرة من مالك الجهاز | -1 الشدة |
تخفف تكوينات برنامج التحويل البرمجي أو النظام الأساسي من ثغرة أمنية في التعليمات البرمجية المصدر | شدة معتدلة إذا كانت الثغرة الأمنية الأساسية متوسطة أو أعلى |
يتطلب وصولاً فعليًا إلى الأجزاء الداخلية للجهاز ولا يزال ممكنًا إذا كان الهاتف مغلقًا أو لم يتم إلغاء قفله منذ تشغيله | -1 الشدة |
يتطلب الوصول المادي إلى الأجزاء الداخلية للجهاز أثناء تشغيل الهاتف وتم إلغاء قفله مسبقًا | -2 شدة |
هجوم محلي يتطلب فتح محمل الإقلاع | ليس أعلى من منخفض |
هجوم محلي يتطلب وضع المطور أو أي إعدادات وضع مطور ثابتة ليتم تمكينها حاليًا على الجهاز (وليس خطأ في وضع المطور نفسه). | ليس أعلى من منخفض |
إذا لم يكن هناك مجال SELinux يمكنه إجراء العملية بموجب سياسة SEPolicy المقدمة من Google | تأثير أمني ضئيل |
محلي مقابل قريب مقابل بعيد
يشير ناقل الهجوم عن بُعد إلى أنه يمكن استغلال الخطأ بدون تثبيت تطبيق أو بدون وصول فعلي إلى الجهاز. يتضمن ذلك الأخطاء التي يمكن تشغيلها من خلال التصفح إلى صفحة ويب أو قراءة بريد إلكتروني أو تلقي رسالة SMS أو الاتصال بشبكة معادية. لأغراض تقييمات الخطورة ، يعتبر فريق أمان Android أيضًا متجهات الهجوم "القريبة" على أنها بعيدة. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل المهاجم الذي يكون فعليًا بالقرب من الجهاز المستهدف ، على سبيل المثال ، خطأ يتطلب إرسال حزم Wi-Fi أو Bluetooth مشوهة. يعتبر فريق أمان Android أن الهجمات المستندة إلى NFC قريبة وبالتالي بعيدة.
تتطلب الهجمات المحلية من الضحية تشغيل تطبيق ، إما عن طريق تثبيت تطبيق وتشغيله أو بالموافقة على تشغيل تطبيق فوري . لغرض تصنيفات الخطورة ، يعتبر فريق أمان Android أيضًا متجهات الهجوم الجسدي على أنها محلية. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل المهاجم الذي لديه وصول فعلي إلى الجهاز ، على سبيل المثال خطأ في شاشة القفل أو خطأ يتطلب توصيل كابل USB. لاحظ أن الهجمات التي تتطلب اتصال USB هي نفس درجة الخطورة بغض النظر عما إذا كان الجهاز مطلوبًا لفتحه أم لا ؛ من الشائع أن يتم إلغاء قفل الأجهزة أثناء توصيلها بمنفذ USB.
أمان Wi-Fi
يفترض Android أن جميع الشبكات معادية ويمكنها شن هجمات أو التجسس على حركة المرور. بينما يؤمن أمان طبقة الارتباط (على سبيل المثال ، تشفير Wi-Fi) الاتصال بين الجهاز ونقطة وصول Wi-Fi المتصلة به ، فإنه لا يفعل شيئًا لتأمين الروابط المتبقية في السلسلة بين الجهاز والخوادم التي يتصل بها .
على النقيض من ذلك ، يحمي HTTPS عادةً الاتصال بالكامل من طرف إلى طرف ، ويقوم بتشفير البيانات عند مصدرها ، ثم يقوم بفك تشفيرها والتحقق منها فقط بمجرد وصولها إلى وجهتها النهائية. لهذا السبب ، تم تصنيف الثغرات الأمنية التي تهدد أمان Wi-Fi بأنها أقل خطورة من الثغرات الأمنية في HTTPS / TLS: تشفير Wi-Fi وحده غير كافٍ لمعظم الاتصالات على الإنترنت.
المصادقة البيومترية
تعد المصادقة البيومترية مساحة صعبة ، وحتى أفضل الأنظمة يمكن خداعها من خلال شبه مطابقة (راجع مدونة مطوري Android: Lockscreen وتحسينات المصادقة في Android 11 ). تميز تصنيفات الخطورة هذه بين فئتين من الهجمات وتهدف إلى عكس المخاطر الفعلية على المستخدم النهائي.
تسمح الفئة الأولى من الهجمات بتجاوز المصادقة البيومترية بطريقة قابلة للتعميم ، بدون بيانات بيومترية عالية الجودة من المالك. على سبيل المثال ، إذا تمكن المهاجم من وضع قطعة من العلكة على مستشعر بصمات الأصابع ، ومنح الوصول إلى الجهاز بناءً على البقايا المتبقية على المستشعر ، فهذه هجوم بسيط يمكن تنفيذه على أي جهاز حساس. لا يتطلب أي معرفة بمالك الجهاز. نظرًا لأنه قابل للتعميم ويحتمل أن يؤثر على عدد أكبر من المستخدمين ، فإن هذا الهجوم يتلقى تصنيف الخطورة الكامل (على سبيل المثال ، مرتفع ، لتجاوز Lockscreen).
تتضمن فئة الهجمات الأخرى عمومًا أداة هجوم عرض تقديمي (محاكاة ساخرة) استنادًا إلى مالك الجهاز. في بعض الأحيان يكون من السهل نسبيًا الحصول على هذه المعلومات الحيوية (على سبيل المثال ، إذا كانت صورة الملف الشخصي لشخص ما على وسائل التواصل الاجتماعي كافية لخداع المصادقة البيومترية ، فسيحصل تجاوز القياسات الحيوية على تصنيف الخطورة الكامل). ولكن إذا احتاج المهاجم إلى الحصول على بيانات المقاييس الحيوية مباشرةً من مالك الجهاز (على سبيل المثال ، فحص الأشعة تحت الحمراء لوجهه) ، فهذا يمثل حاجزًا كبيرًا بما يكفي للحد من عدد الأشخاص المتأثرين بالهجوم ، لذلك هناك معدل -1 .
المكون المتأثر
يعتمد فريق التطوير المسؤول عن إصلاح الخطأ على المكون الموجود فيه الخطأ. يمكن أن يكون مكونًا أساسيًا لمنصة Android ، أو برنامج تشغيل kernel مقدمًا من قبل الشركة المصنعة للمعدات الأصلية (OEM) ، أو أحد التطبيقات المحملة مسبقًا على أجهزة Pixel .
يتم إصلاح الأخطاء في كود AOSP بواسطة فريق هندسة Android. قد يتم إصلاح الأخطاء منخفضة الخطورة ، أو الأخطاء الموجودة في مكونات معينة ، أو الأخطاء المعروفة بالفعل للجمهور مباشرةً في الفرع الرئيسي لـ AOSP المتاح للجمهور ؛ وإلا سيتم إصلاحها في مستودعاتنا الداخلية أولاً.
يعد المكون أيضًا عاملاً في كيفية حصول المستخدمين على التحديثات. يتطلب الخلل في إطار العمل أو kernel تحديثًا للبرامج الثابتة عبر الهواء (OTA) يحتاج كل مُصنِّع أصلي إلى دفعه. يمكن إرسال خطأ في تطبيق أو مكتبة منشورة في Google Play (على سبيل المثال ، Gmail أو خدمات Google Play أو WebView) إلى مستخدمي Android كتحديث من Google Play.
إخطار الشركاء
عندما يتم إصلاح ثغرة أمنية في AOSP في نشرة أمان Android ، سنقوم بإخطار شركاء Android بتفاصيل المشكلة وتقديم التصحيحات. تتغير قائمة الإصدارات المدعومة من backport مع كل إصدار جديد من Android. اتصل بالشركة المصنعة لجهازك للحصول على قائمة بالأجهزة المدعومة.
تحرير الكود إلى AOSP
إذا كان الخطأ الأمني موجودًا في أحد مكونات AOSP ، فسيتم دفع الإصلاح إلى AOSP بعد إصدار OTA للمستخدمين. يمكن إرسال إصلاحات المشكلات منخفضة الخطورة مباشرة إلى الفرع الرئيسي لـ AOSP قبل أن يتوفر الإصلاح للأجهزة من خلال OTA.
تلقي تحديثات Android
يتم تسليم تحديثات نظام Android بشكل عام إلى الأجهزة من خلال حزم تحديث OTA. قد تأتي هذه التحديثات من الشركة المصنّعة للمعدات الأصلية (OEM) التي أنتجت الجهاز أو شركة الاتصالات التي تقدم الخدمة للجهاز. تأتي تحديثات جهاز Google Pixel من فريق Google Pixel بعد اجتياز إجراء اختبار القبول الفني (TA). تنشر Google أيضًا صور مصنع Pixel التي يمكن تحميلها على الأجهزة.
تحديث خدمات جوجل
بالإضافة إلى توفير تصحيحات للأخطاء الأمنية ، يقوم فريق أمان Android بمراجعة الأخطاء الأمنية لتحديد ما إذا كانت هناك طرق أخرى لحماية المستخدمين. على سبيل المثال ، يفحص Google Play جميع التطبيقات ويزيل أي تطبيق يحاول استغلال خطأ أمني. بالنسبة للتطبيقات المثبتة من خارج Google Play ، قد تستخدم الأجهزة المزودة بخدمات Google Play أيضًا ميزة Verify Apps لتحذير المستخدمين بشأن التطبيقات التي قد تكون ضارة.
مصادر أخرى
معلومات لمطوري تطبيقات Android: https://developer.android.com
توجد معلومات الأمان عبر مواقع Android Open Source ومواقع Developer. أماكن جيدة للبدء:
- https://source.android.com/security/index
- https://developer.android.com/training/articles/security-tips
التقارير
ينشر فريق أمان Android أحيانًا تقارير أو مستندات تقنية. انظر تقارير الأمان لمزيد من التفاصيل.