يتولّى فريق أمان Android إدارة الثغرات الأمنية التي يتم اكتشافها في نظام التشغيل Android والعديد من تطبيقات Android الأساسية المضمّنة في أجهزة Android.
يعثر فريق أمان Android على الثغرات الأمنية من خلال الأبحاث الداخلية، كما يردّ على الأخطاء التي تُبلغ عنها جهات خارجية. تشمل مصادر الأخطاء الخارجية المشاكل التي تم الإبلاغ عنها من خلال نموذج الثغرات الأمنية والأبحاث الأكاديمية المنشورة والمُعلَن عنها مسبقًا، ومشرفي المشاريع المفتوحة المصدر، والإشعارات الواردة من شركائنا من المصنّعين للأجهزة، والمشاكل التي تم الإفصاح عنها علنًا والتي يتم نشرها على المدونات أو وسائل التواصل الاجتماعي.
الإبلاغ عن مشاكل الأمان
يمكن لأي مطوّر أو مستخدم Android أو باحث أمان إبلاغ فريق أمان Android بأحد المشاكل الأمنية المحتمَلة من خلال نموذج الإبلاغ عن الثغرات الأمنية.
لا تظهر الأخطاء التي تم تصنيفها على أنّها مشاكل أمنية للمستخدمين الخارجيين، ولكن قد يتم إظهارها في نهاية المطاف بعد تقييم المشكلة أو حلّها. إذا كنت تخطّط لإرسال تصحيح أو اختبار ملف اختبار التوافق (CTS) لحلّ مشكلة أمنية، يُرجى إرفاقه بتقرير الخطأ والانتظار إلى أن يصلك ردّ قبل تحميل الرمز إلى AOSP.
تصنيف الأخطاء ومعالجتها حسب الأولوية
تتمثل المهمة الأولى في التعامل مع ثغرة أمنية في تحديد شدة الخطأ و المكوّن المتأثّر في نظام Android. تحدّد الخطورة كيفية تحديد أولوية المشكلة، ويحدّد المكوّن مَن يحلّ الخطأ، ومَن يتم إعلامه، وكيفية نشر الإصلاح للمستخدمين.
أنواع السياق
يتناول هذا الجدول تعريفات سياقات أمان الأجهزة والبرامج. يمكن تحديد السياق حسب حساسية البيانات التي يعالجها عادةً أو المنطقة التي يتم تشغيله فيها. لا تنطبق بعض سياقات الأمان على جميع الأنظمة. يتم ترتيب هذا الجدول من الأقل إلى الأكثر امتيازًا.
نوع السياق | تعريف النوع |
---|---|
السياق المحدود |
بيئة تنفيذ مفروض عليها قيود حيث لا يتم منح سوى الحد الأدنى من الأذونات
على سبيل المثال، التطبيقات الموثوق بها التي تعالج بيانات غير موثوق بها ضمن بيئة وضع الحماية |
سياق غير مفوَّض |
بيئة تنفيذ نموذجية متوقّعة من خلال الرمز البرمجي غير المفوَّض على سبيل المثال، تطبيق Android الذي يعمل في نطاق SELinux باستخدام سمة untrusted_app_all .
|
السياق المميّز |
بيئة تنفيذ مميّزة قد يكون لها إذن الوصول إلى أذونات مميّزة، و/أو تعالج
معلومات تحديد الهوية الشخصية لعدة مستخدمين، و/أو تحافظ على سلامة النظام على سبيل المثال، تطبيق Android يتضمّن إمكانات يحظرها نطاق untrusted_app في SELinux أو يتضمّن إذن الوصول إلى
privileged|signature .
|
نواة نظام التشغيل |
الوظائف التي:
|
Trusted Hardware Base (THB) | مكونات الأجهزة المنفصلة، والتي تكون بشكل عام في شريحة المعالجة المُدمجة (SoC)، والتي توفّر وظائف مهمة لحالات الاستخدام الأساسية للجهاز (مثل نطاقات الأساس الخلوية ووحدات معالجة الإشارات الرقمية ووحدات معالجة الرسومات ومعالجات الذكاء الاصطناعي) |
سلسلة برنامج الإقلاع | عنصر يضبط الجهاز عند التشغيل ثم ينقل التحكّم إلى نظام التشغيل Android |
بيئة التنفيذ الموثوقة (TEE) | عنصر مصمّم ليتم حمايته حتى من نواة نظام التشغيل المعادية (على سبيل المثال، TrustZone وبرامج إدارة الأجهزة الافتراضية، مثل pKVM، التي تحمي الأجهزة الافتراضية من نواة نظام التشغيل). |
عنصر آمن (SE) / منطقة آمنة |
عنصر أجهزة اختياري مصمّم ليتم حمايته من جميع المكونات الأخرى في
الجهاز ومن الهجمات المادية، كما هو محدّد في
مقدّمة عن العناصر الآمنة. ويشمل ذلك شريحة Titan-M المتوفّرة في بعض أجهزة Android. |
درجة الخطورة
تعكس شدة الخطأ بشكل عام الضرر المحتمل الذي يمكن أن يحدث في حال تم استغلال الخطأ بنجاح. استخدِم المعايير التالية لتحديد مدى الخطورة.
التقييم | نتيجة الاستغلال الناجح |
---|---|
مهمة |
|
مرتفعة |
|
معتدِلة |
|
منخفضة |
|
تأثير بسيط على الأمان (NSI) |
|
مُعدِّلات الأسعار
على الرغم من أنّه غالبًا ما يكون من السهل تحديد خطورة الثغرات الأمنية، قد تتغيّر التقييمات استنادًا إلى الظروف.
السبب | التأثير |
---|---|
تتطلّب تنفيذ الهجوم التشغيل بصفتك سياقًا مفوَّضًا (لا ينطبق ذلك على TEE وSE وبرامج التشغيل الافتراضية مثل pKVM) | -1 مستوى الخطورة |
التفاصيل المتعلّقة بالثغرة الأمنية تحدّ من تأثير المشكلة | -1 مستوى الخطورة |
تجاوز المصادقة بالمقاييس الحيوية التي تتطلّب الحصول على معلومات المقاييس الحيوية مباشرةً من صاحب الجهاز | -1 مستوى الخطورة |
إعدادات المُجمِّع أو النظام الأساسي تقلّل من خطورة ثغرة في رمز المصدر | خطورة متوسطة إذا كانت الثغرة الأساسية متوسطة الخطورة أو أعلى |
يتطلّب الوصول المادي إلى الأجزاء الداخلية للجهاز، ولا يزال ذلك ممكنًا إذا كان الجهاز غير مفعَّل أو لم يتم فتح قفله منذ تشغيله | -1 مستوى الخطورة |
يتطلب الوصول إلى الأجزاء الداخلية للجهاز عندما يكون الجهاز مفعَّلاً وسبق أن تم فتح قفله | درجة الخطورة: -2 |
هجوم محلي يتطلب فتح قفل سلسلة برنامج الإقلاع | لا يزيد عن "منخفض" |
هجوم على الجهاز يتطلّب تفعيل "وضع المطوّر" أو أي إعدادات دائمة في "وضع المطوّر" (وليس خطأ في "وضع المطوّر" نفسه) | لا يزيد عن "منخفض" |
إذا لم يكن بإمكان أي نطاق SELinux تنفيذ العملية بموجب سياسة SEPolicy التي تقدّمها Google | تأثير بسيط في الأمان |
المحتوى المحلي مقابل المحتوى القريب مقابل المحتوى البعيد
يشير متجه الهجوم عن بُعد إلى أنّه يمكن استغلال الخلل بدون تثبيت تطبيق أو بدون الوصول المادي إلى الجهاز. ويشمل ذلك الأخطاء التي يمكن أن يتم تشغيلها من خلال الانتقال إلى صفحة ويب أو قراءة رسالة إلكترونية أو تلقّي رسالة قصيرة أو الاتصال بشبكة معادية.
تُعدّ متجهات الهجوم القريبة عن الجهاز عن بُعد. وتشمل هذه الأخطاء ما لا يمكن استغلاله إلا من قِبل مهاجم قريب جسديًا من الجهاز المستهدَف، مثل خطأ يتطلّب إرسال حزم 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
و"الاختراق من خلال النقر"،
يُرجى الاطّلاع على قسم "الاختراق من خلال النقر/الاختراق من خلال التراكب SYSTEM_ALERT_WINDOW على شاشة غير حاسمة من حيث الأمان" في صفحة
الأخطاء التي لا تؤثّر في الأمان
في BugHunter University.
أمان المستخدمين المتعدّدين في نظام التشغيل Android Automotive
يتّبع نظام التشغيل Android Automotive نموذج أمان متعدّد المستخدمين يختلف عن أشكال الأجهزة الأخرى. يُفترض أن يستخدم كل مستخدم لنظام التشغيل Android حسابًا مختلفًا خاصًا بشخص مختلف. على سبيل المثال، يمكن منح إذن وصول مؤقت لمستخدم ضيف لصديق يستعير المركبة من مالك السيارة. لاستيعاب حالات الاستخدام هذه، يمكن للمستخدمين تلقائيًا الوصول إلى المكوّنات اللازمة لاستخدام المركبة، مثل إعدادات Wi-Fi وشبكة الجوّال.
المكوِّن المتأثّر
يعتمد فريق التطوير المسؤول عن إصلاح الخطأ على المكوّن الذي يتضمّن الخطأ. وقد يكون عنصرًا أساسيًا في نظام Android الأساسي أو برنامج تشغيل نظام التشغيل الذي يوفّره أحد المصنّعين الأصليين للأجهزة (OEM) أو أحد التطبيقات المُحمَّلة مسبقًا على أجهزة Pixel.
يعالج فريق مهندسي Android الأخطاء في رمز AOSP. يمكن إصلاح الأخطاء ذات الخطورة المنخفضة أو الأخطاء في مكوّنات معيّنة أو الأخطاء المعروفة للجميع مباشرةً في الفرع الرئيسي لمشروع AOSP المتاح للجميع، وإلا يتم إصلاحها في مستودعاتنا الداخلية أولاً.
ويشكّل المكوّن أيضًا عاملاً في كيفية حصول المستخدمين على التحديثات. خطأ في إطار العمل أو النواة يتطلّب تحديثًا للبرامج الثابتة عبر شبكة غير سلكية (OTA) على كلّ مُصنّع أصلي إجراؤه إذا كان هناك خطأ في تطبيق أو مكتبة تم نشرهما على Google Play (مثل Gmail أو "خدمات Google Play" أو WebView)، يمكن إرسال هذا الخطأ إلى مستخدمي Android كتحديث من Google Play.
إشعار الشركاء
عند إصلاح ثغرة أمنية في AOSP في نشرة أمان Android، سنُعلم شركاء Android بتفاصيل المشكلة ونوفّر لهم الرموز البرمجية الإصلاحية. تتغيّر قائمة الإصدارات المتوافقة مع ميزة "الإصدار المتوافق مع الإصدارات القديمة" مع كل إصدار جديد من Android. يمكنك التواصل مع الشركة المصنّعة لجهازك للحصول على قائمة بالأجهزة المتوافقة.
طرح الرمز البرمجي في AOSP
إذا كان الخلل في الأمان موجودًا في أحد مكوّنات AOSP، يتم طرح الإصلاح في AOSP بعد طرح التحديث OTA للمستخدمين. يمكن إرسال إصلاحات المشاكل ذات الخطورة المنخفضة مباشرةً إلى الفرع الرئيسي في AOSP قبل توفّر الإصلاح على الأجهزة من خلال تحديث OTA.
تلقّي تحديثات Android
يتم عادةً طرح تحديثات نظام Android على الأجهزة من خلال حِزم التحديث عبر شبكة غير سلكيّة. قد تأتي هذه التحديثات من الشركة المصنّعة الأصلية للجهاز أو مشغّل شبكة الجوّال الذي يقدّم الخدمة للجهاز. تأتي تحديثات أجهزة Google Pixel من فريق Google Pixel بعد اجتياز إجراءات اختبار القبول الفني لمشغّل شبكة الجوّال (TA). تنشر Google أيضًا صور Pixel الأصلية التي يمكن تثبيتها على الأجهزة من مصدر غير معروف.
تحديث خدمات Google
بالإضافة إلى توفير تصحيحات لأخطاء الأمان، يراجع فريق أمان Android أخطاء الأمان لتحديد ما إذا كانت هناك طرق أخرى لحماية المستخدمين. على سبيل المثال، يفحص Google Play جميع التطبيقات ويزيل أي تطبيق يحاول استغلال خطأ أمني. بالنسبة إلى التطبيقات المثبَّتة من خارج Google Play، قد تستخدم الأجهزة التي تم تثبيت "خدمات Google Play" عليها أيضًا ميزة التحقّق من التطبيقات لتحذير المستخدمين من التطبيقات التي قد تتسبّب بضرر.
مراجع أخرى
معلومات لمطوّري تطبيقات Android: https://developer.android.com
تتوفّر معلومات الأمان في جميع المواقع الإلكترونية التي تخصّ Android Open Source ومطوّري تطبيقات Android. إليك بعض الخطوات الجيدة للبدء:
التقارير
ينشر فريق أمان Android في بعض الأحيان تقارير أو أوراق بيضاء. يمكنك الاطّلاع على تقارير الأمان للحصول على مزيد من التفاصيل.