فريق أمان Android مسؤول عن إدارة الثغرات الأمنية التي تم رصدها في نظام Android الأساسي والعديد من تطبيقات Android الأساسية المضمّنة في أجهزة Android.
يعثر فريق أمان Android على الثغرات الأمنية من خلال الأبحاث الداخلية، كما يستجيب للأخطاء التي تبلّغ عنها جهات خارجية. تشمل مصادر الأخطاء الخارجية المشاكل التي تم الإبلاغ عنها من خلال نموذج الثغرات الأمنية، والأبحاث الأكاديمية المنشورة والمسبقة النشر، والقائمين على صيانة المشاريع المفتوحة المصدر، والإشعارات الواردة من شركائنا من مصنّعي الأجهزة، والمشاكل التي تم الإفصاح عنها علنًا ونشرها على المدونات أو وسائل التواصل الاجتماعي.
الإبلاغ عن مشاكل تتعلّق بالأمان
يمكن لأي مطوّر أو مستخدم Android أو باحث أمني إبلاغ فريق أمان Android عن المشاكل الأمنية المحتملة من خلال نموذج الثغرات الأمنية.
لا تظهر الأخطاء المصنّفة كمشاكل أمنية للمستخدمين الخارجيين، ولكن قد يتم إتاحتها لاحقًا بعد تقييم المشكلة أو حلّها. إذا كنت تخطّط لإرسال رمز تصحيح أو اختبار من مجموعة أدوات اختبار التوافق (CTS) لحلّ مشكلة أمنية، يُرجى إرفاقه بتقرير خطأ وانتظار الردّ قبل تحميل الرمز إلى مشروع Android المفتوح المصدر (AOSP).
تصنيف الأخطاء حسب الأولوية
تتمثّل المهمة الأولى في معالجة ثغرة أمنية في تحديد مدى خطورة الخطأ وتحديد مكون Android المتأثر به. تحدّد درجة الخطورة أولوية المشكلة، ويحدّد المكوّن الجهة المسؤولة عن إصلاح الخطأ، والجهة التي سيتم إعلامها، وطريقة نشر الإصلاح للمستخدمين.
أنواع السياق
يتناول هذا الجدول تعريفات سياقات أمان الأجهزة والبرامج. ويمكن تحديد السياق حسب حساسية البيانات التي تتم معالجتها عادةً أو المنطقة التي يتم تشغيلها فيها. لا تنطبق بعض سياقات الأمان على جميع الأنظمة. يتم ترتيب هذا الجدول من الأقل إلى الأكثر امتيازًا.
| نوع السياق | تعريف النوع |
|---|---|
| السياق المحدود |
بيئة تنفيذ مقيّدة لا يتم فيها توفير سوى الحد الأدنى من الأذونات. على سبيل المثال، التطبيقات الموثوق بها التي تعالج بيانات غير موثوق بها في بيئة معزولة. |
| سياق غير مميّز |
بيئة تنفيذ نموذجية يتوقّعها الرمز البرمجي غير المميز على سبيل المثال، تطبيق Android يعمل في نطاق SELinux مع السمة untrusted_app_all.
|
| السياق المميز |
بيئة تنفيذ ذات امتيازات قد يكون لديها إذن بالوصول إلى أذونات أعلى، وتتعامل مع معلومات التعريف الشخصية الخاصة بتعدُّد المستخدمين، و/أو تحافظ على سلامة النظام. على سبيل المثال، تطبيق Android يتضمّن إمكانات يحظرها نطاق SELinux untrusted_app أو لديه إذن بالوصول إلى
privileged|signature الأذونات.
|
| نواة نظام التشغيل |
الوظائف التي:
|
| Trusted Hardware Base (THB) | مكوّنات الأجهزة المنفصلة، التي تكون عادةً على نظام على شريحة واحدة (SoC)، والتي توفّر وظائف مهمة لحالات الاستخدام الأساسية للجهاز (مثل نطاقات قاعدة الاتصالات الخلوية، ومعالجات الإشارات الرقمية (DSP)، ووحدات معالجة الرسومات (GPU)، ومعالجات تعلُّم الآلة (ML)). |
| سلسلة برامج الإقلاع | أحد المكوّنات التي تضبط إعدادات الجهاز عند بدء التشغيل ثم تنقل التحكّم إلى نظام التشغيل Android |
| بيئة التنفيذ الموثوقة (TEE) | أحد المكوّنات المصمَّمة للحماية من حتى نواة نظام التشغيل المعادي (على سبيل المثال، TrustZone وبرامج الإشراف، مثل pKVM، التي تحمي الأجهزة الافتراضية من نواة نظام التشغيل). |
| Secure Enclave / Secure Element (SE) |
أحد مكونات الأجهزة الاختيارية المصمَّمة لتكون محمية من جميع المكونات الأخرى على الجهاز ومن الهجمات المادية، كما هو موضّح في مقدمة حول العناصر الآمنة. ويشمل ذلك شريحة Titan-M المتوفرة في بعض أجهزة Android. |
درجة الخطورة
تعكس خطورة الخطأ بشكل عام الضرر المحتمل الذي قد يحدث إذا تم استغلال الخطأ بنجاح. استخدِم المعايير التالية لتحديد مدى خطورة المشكلة.
| التقييم | عواقب الاستغلال الناجح |
|---|---|
| مهم |
|
| مرتفعة |
|
| معتدِلة |
|
| منخفضة |
|
| تأثير الأمان غير المهم (NSI) |
|
معدِّلات درجة الخطورة
على الرغم من سهولة تحديد درجة خطورة الثغرات الأمنية في كثير من الأحيان، قد تتغيّر التقييمات حسب الظروف.
| السبب | التأثير |
|---|---|
| يتطلّب التشغيل في سياق مميّز لتنفيذ الهجوم (لا ينطبق على بيئة التنفيذ الموثوقة (TEE) وبيئة التنفيذ الآمنة (SE) وبرامج الإشراف، مثل pKVM) | -1 درجة الخطورة |
| تحدّ التفاصيل الخاصة بالثغرة الأمنية من تأثير المشكلة | -1 درجة الخطورة |
| تجاوز المصادقة بالمقاييس الحيوية الذي يتطلّب الحصول على معلومات المقاييس الحيوية مباشرةً من مالك الجهاز | -1 درجة الخطورة |
| تخفّف إعدادات المترجم أو النظام الأساسي من الثغرة الأمنية في رمز المصدر | درجة الخطورة المتوسطة إذا كانت الثغرة الأساسية متوسطة أو أعلى |
| يتطلّب الوصول إلى الأجزاء الداخلية للجهاز، ويمكن تنفيذه حتى إذا كان الجهاز مطفأً أو لم يتم فتح قفله منذ تشغيله | -1 درجة الخطورة |
| يتطلّب هذا الإجراء الوصول الفعلي إلى الأجزاء الداخلية للجهاز أثناء تشغيله وفتح قفله مسبقًا | -2 درجة الخطورة |
| هجوم محلي يتطلّب فتح سلسلة برنامج الإقلاع | لا أعلى من "منخفض" |
| هجوم محلي يتطلّب تفعيل "وضع مطور البرامج" أو أي إعدادات دائمة لهذا الوضع على الجهاز (ولا يكون ذلك نتيجة خطأ في "وضع مطور البرامج" نفسه). | لا أعلى من "منخفض" |
| إذا لم يتمكّن أي نطاق SELinux من تنفيذ العملية بموجب SEPolicy المقدَّمة من Google | تأثير بسيط في الأمان |
الموقع المحلي مقابل الموقع القريب مقابل الموقع البعيد
يشير متجه الهجوم عن بُعد إلى أنّه يمكن استغلال الخطأ بدون تثبيت تطبيق أو بدون الوصول الفعلي إلى الجهاز. ويشمل ذلك الأخطاء التي يمكن أن تحدث عند تصفّح صفحة ويب أو قراءة رسالة إلكترونية أو تلقّي رسالة SMS أو الاتصال بشبكة معادية.
تُعدّ متجهات الهجوم القريبة عن بُعد. وتشمل هذه الأخطاء تلك التي يمكن استغلالها فقط من قِبل مهاجم قريب جغرافيًا من الجهاز المستهدف، مثل خطأ يتطلب إرسال حِزم Wi-Fi أو بلوتوث غير صالحة. نعتبر الهجمات المستندة إلى النطاق الفائق العرض (UWB) والهجمات المستندة إلى تقنية الاتصال قريب المدى (NFC) هجمات قريبة وبالتالي بعيدة.
تتطلّب الهجمات المحلية أن يكون لدى المهاجم إذن وصول مسبق إلى الضحية. في مثال افتراضي يعتمد على البرامج فقط، يمكن أن يتم ذلك من خلال تطبيق ضارّ ثبّته الضحية، أو تطبيق فوري وافق على تشغيله.
يتم اعتبار الأجهزة التي تم إقرانها بنجاح (مثل الأجهزة المساعدة التي تتضمّن بلوتوث) أجهزة محلية. نفرّق بين جهاز مقترن وجهاز يشارك في عملية إقران.
- يتم تصنيف الأخطاء التي تقلّل من قدرة المستخدم على تحديد الجهاز الآخر الذي يتم إقرانه به (أي المصادقة) على أنّها أخطاء قريبة وبالتالي بعيدة.
- يتم تصنيف الأخطاء التي تحدث أثناء عملية الإقران ولكن قبل الحصول على موافقة المستخدم (أي التفويض) على أنّها أخطاء قريبة وبالتالي بعيدة.
- يتم اعتبار الأخطاء التي تحدث بعد الحصول على موافقة المستخدم أخطاء محلية، حتى إذا تعذّر الاقتران في النهاية.
تُعدّ أساليب الهجوم المادي محلية. وتشمل هذه الأخطاء تلك التي يمكن استغلالها فقط من خلال مهاجم لديه إمكانية الوصول الفعلي إلى الجهاز، مثل خطأ في شاشة القفل أو خطأ يتطلب توصيل كابل USB. بما أنّه من الشائع أن تكون الأجهزة غير مقفلة أثناء توصيلها بمنفذ الناقل التسلسلي العالمي (USB)، فإنّ الهجمات التي تتطلّب اتصالاً عبر الناقل التسلسلي العالمي (USB) تكون بنفس درجة الخطورة بغض النظر عمّا إذا كان الجهاز يحتاج إلى فتح القفل أم لا.
أمان الشبكة
يفترض نظام التشغيل Android أنّ جميع الشبكات معادية ويمكن أن تنفّذ هجمات أو تتجسّس على حركة البيانات. في حين أنّ أمان طبقة الربط (مثل تشفير Wi-Fi) يضمن أمان الاتصال بين الجهاز ونقطة الوصول التي يتصل بها، لا يفعل ذلك شيئًا لتأمين الروابط المتبقية في السلسلة بين الجهاز والخوادم التي يتواصل معها.
في المقابل، يحمي بروتوكول HTTPS عادةً عملية التواصل بأكملها من البداية إلى النهاية، إذ يشفّر البيانات عند مصدرها، ثم يفك تشفيرها ويتأكّد من صحتها عند وصولها إلى وجهتها النهائية فقط. لهذا السبب، تُصنّف الثغرات الأمنية التي تعرّض أمان شبكة طبقة الربط للخطر على أنّها أقل خطورة من الثغرات الأمنية في HTTPS/TLS، لأنّ تشفير شبكة Wi-Fi وحده لا يكفي لمعظم عمليات التواصل على الإنترنت.
المصادقة بالمقاييس الحيوية
تُعد المصادقة باستخدام المقاييس الحيوية مجالًا صعبًا، وحتى أفضل الأنظمة يمكن خداعها باستخدام تطابق قريب (راجِع مدوّنة مطوّري تطبيقات Android: تحسينات على شاشة القفل والمصادقة في Android 11). تفرّق تقييمات الخطورة هذه بين فئتَين من الهجمات، وهي تهدف إلى توضيح المخاطر الفعلية التي قد يتعرّض لها المستخدم النهائي.
يتيح النوع الأول من الهجمات تجاوز المصادقة بالمقاييس الحيوية بطريقة قابلة للتطبيق بشكل عام، بدون الحاجة إلى بيانات مقاييس حيوية عالية الجودة من المالك. على سبيل المثال، إذا تمكّن أحد المهاجمين من وضع قطعة من العلكة على أداة استشعار بصمة الإصبع، وتمكّن من الوصول إلى الجهاز استنادًا إلى البقايا التي تركها على أداة الاستشعار، يكون ذلك هجومًا بسيطًا يمكن تنفيذه على أي جهاز معرَّض للخطر. ولا تتطلب هذه العملية أي معرفة بمالك الجهاز. وبما أنّ هذا النوع من الهجمات يمكن تعميمه ويحتمل أن يؤثر في عدد أكبر من المستخدمين، فإنّه يحصل على تقييم الخطورة الكامل (على سبيل المثال، "عالية" في حال تجاوز شاشة القفل).
يتضمّن النوع الآخر من الهجمات بشكل عام أداة هجومية (انتحال هوية) تستند إلى مالك الجهاز. في بعض الأحيان، يكون من السهل نسبيًا الحصول على معلومات المقاييس الحيوية (على سبيل المثال، إذا كانت صورة الملف الشخصي على وسائل التواصل الاجتماعي كافية لخداع نظام المصادقة باستخدام المقاييس الحيوية، سيحصل تجاوز المقاييس الحيوية على تقييم الخطورة الكامل). أما إذا كان على المهاجم الحصول على بيانات المقاييس الحيوية مباشرةً من صاحب الجهاز (على سبيل المثال، إجراء مسح بالأشعة تحت الحمراء لوجهه)، فإنّ ذلك يشكّل عائقًا كبيرًا بما يكفي للحدّ من عدد الأشخاص المتأثرين بالهجوم، وبالتالي يتم تطبيق المعدِّل -1.
SYSTEM_ALERT_WINDOW وtapjacking
للحصول على معلومات حول سياساتنا المتعلّقة SYSTEM_ALERT_WINDOW وtapjacking، يُرجى الاطّلاع على قسم "ثغرة tapjacking/overlay SYSTEM_ALERT_WINDOW على شاشة غير مهمة من الناحية الأمنية" في صفحة
الأخطاء التي لا تؤثر في الأمان
في BugHunter University.
أمان تعدد المستخدمين في نظام التشغيل Android Automotive
يستخدم نظام التشغيل Android Automotive نموذج أمان متعدد المستخدمين يختلف عن نماذج الأجهزة الأخرى. يجب أن يكون كل مستخدم Android شخصًا طبيعيًا مختلفًا. على سبيل المثال، يمكن تعيين مستخدم ضيف مؤقت لصديق يستعير السيارة من مالكها. لتلبية حالات الاستخدام هذه، يمكن للمستخدمين بشكل تلقائي الوصول إلى المكوّنات اللازمة لاستخدام السيارة، مثل إعدادات شبكة Wi-Fi وشبكة الجوّال.
المكوِّن المتأثر
يعتمد فريق التطوير المسؤول عن إصلاح الخطأ على المكوّن الذي يظهر فيه الخطأ. وقد يكون أحد المكوّنات الأساسية لنظام Android الأساسي أو برنامج تشغيل النواة الذي يوفّره أحد المصنّعين الأصليين للأجهزة أو أحد التطبيقات المحمَّلة مسبقًا على أجهزة Pixel.
يصلح فريق هندسة Android الأخطاء في رمز AOSP في مستودعاتنا الداخلية.
ويُعدّ المكوّن أيضًا عاملاً في كيفية حصول المستخدمين على التحديثات. يتطلّب إصلاح خطأ في إطار العمل أو النواة تحديثًا للبرامج الثابتة عبر شبكة غير سلكية (OTA) يجب أن يوفّره كل مصنّع أصلي للجهاز. يمكن إرسال خطأ في تطبيق أو مكتبة تم نشرهما على Google Play (مثل Gmail أو "خدمات Google Play" أو WebView) إلى مستخدمي Android كتحديث من Google Play.
إشعار الشركاء
عند إصلاح ثغرة أمنية في مشروع AOSP ضمن "نشرة أمان Android"، سنُرسل إشعارًا إلى شركاء Android يتضمّن تفاصيل المشكلة ونوفّر رموز تصحيح. تتغيّر قائمة الإصدارات المتوافقة مع النقل إلى إصدار أقدم مع كل إصدار جديد من Android. يمكنك التواصل مع الشركة المصنّعة لجهازك للحصول على قائمة بالأجهزة المتوافقة.
إصدار الرمز البرمجي إلى AOSP
إذا كان الخلل الأمني في أحد مكونات AOSP، يتم طرح الإصلاح في AOSP بعد طرح التحديث عبر الهواء للمستخدمين.
تلقّي تحديثات Android
يتم عادةً إرسال تحديثات نظام التشغيل Android إلى الأجهزة من خلال حِزم التحديثات عبر شبكة غير سلكيّة (OTA). وقد تأتي هذه التحديثات من الشركة المصنّعة للجهاز أو مشغّل شبكة الجوّال الذي يقدّم الخدمة للجهاز. تتلقّى أجهزة Google Pixel تحديثات من فريق Google Pixel بعد اجتياز إجراء اختبار القبول الفني (TA) لدى مشغّل شبكة الجوّال. تنشر Google أيضًا صور المصنع لأجهزة Pixel التي يمكن تحميلها بشكل جانبي على الأجهزة.
تحديث خدمات Google
بالإضافة إلى توفير تصحيحات لأخطاء الأمان، يراجع فريق أمان Android أخطاء الأمان لتحديد ما إذا كانت هناك طرق أخرى لحماية المستخدمين. على سبيل المثال، يفحص Google Play جميع التطبيقات ويزيل أي تطبيق يحاول استغلال خطأ أمني. بالنسبة إلى التطبيقات التي يتم تثبيتها من خارج Google Play، يمكن للأجهزة التي تتضمّن "خدمات Google Play" أيضًا استخدام ميزة التحقّق من التطبيقات لتحذير المستخدمين بشأن التطبيقات التي قد تكون ضارة.
مراجع أخرى
معلومات لمطوّري تطبيقات Android: https://developer.android.com
تتوفّر معلومات الأمان في جميع أنحاء المواقع الإلكترونية الخاصة بمطوّري تطبيقات Android ومشاريع Android مفتوحة المصدر. في ما يلي بعض الأماكن التي يمكنك البدء بها:
التقارير
في بعض الأحيان، ينشر فريق أمان Android تقارير أو مستندات توضيحية. يمكنك الاطّلاع على تقارير الأمان لمزيد من التفاصيل.