فريق أمان Android مسؤول عن إدارة الثغرات الأمنية المكتشفة في نظام Android الأساسي والعديد من تطبيقات Android الأساسية المجمعة مع أجهزة Android.
يكتشف فريق أمان Android ثغرات أمنية من خلال البحث الداخلي ويستجيب أيضًا للأخطاء التي أبلغت عنها جهات خارجية. تتضمن مصادر الأخطاء الخارجية المشكلات التي تم الإبلاغ عنها من خلال نموذج الثغرات الأمنية ، والبحوث الأكاديمية المنشورة والمنشورة مسبقًا ، والمشرفين على إدارة المشروع مفتوح المصدر ، والإشعارات من شركائنا في تصنيع الأجهزة ، والمشكلات التي تم الكشف عنها علنًا على المدونات أو وسائل التواصل الاجتماعي.
الإبلاغ عن مشكلات الأمان
يمكن لأي مطور أو مستخدم Android أو باحث أمني إخطار فريق أمان Android بمشكلات الأمان المحتملة من خلال نموذج الثغرة الأمنية .
الأخطاء التي تم تمييزها على أنها مشكلات أمنية ليست مرئية من الخارج ، ولكن قد تظهر في النهاية بعد تقييم المشكلة أو حلها. إذا كنت تخطط لإرسال اختبار تصحيح أو اختبار مجموعة اختبار التوافق (CTS) لحل مشكلة أمنية ، فيرجى إرفاقه بتقرير الخطأ وانتظر الرد قبل تحميل الرمز إلى AOSP.
فرز البق
تتمثل المهمة الأولى في معالجة الثغرة الأمنية في تحديد مدى خطورة الخطأ والمكوّن المتأثر في Android. تحدد درجة الخطورة كيفية ترتيب المشكلة حسب الأولوية ، ويحدد المكون من يصلح الخطأ ، ومن يتم إخطاره ، وكيف يتم نشر الإصلاح للمستخدمين.
أنواع السياق
يغطي هذا الجدول تعريفات سياقات أمان الأجهزة والبرامج. يمكن تعريف السياق من خلال حساسية البيانات التي يعالجها عادةً أو المنطقة التي يتم تشغيله فيها. ليست كل سياقات الأمان قابلة للتطبيق على جميع الأنظمة. تم ترتيب هذا الجدول من الأقل إلى الأكثر امتيازًا.
| نوع السياق | تعريف النوع |
|---|---|
| سياق مقيد | بيئة تنفيذ مقيدة حيث يتم توفير الحد الأدنى فقط من الأذونات. على سبيل المثال ، تقوم التطبيقات الموثوقة بمعالجة البيانات غير الموثوق بها داخل بيئة وضع الحماية. |
| سياق غير مميز | بيئة تنفيذ نموذجية متوقعة بواسطة كود غير مميز. على سبيل المثال ، تطبيق Android يتم تشغيله في مجال SELinux بسمة untrusted_app_all . |
| سياق متميز | بيئة تنفيذ متميزة قد تتمتع بإمكانية الوصول إلى أذونات مرتفعة ، وتتعامل مع العديد من معلومات تحديد الهوية الشخصية للمستخدمين ، و / أو تحافظ على تكامل النظام. على سبيل المثال ، تطبيق Android به إمكانيات يحظرها نطاق SELinux untrusted_app أو الوصول إلى أذونات privileged|signature . |
| OS Kernel | الوظيفة التي:
|
| قاعدة الأجهزة الموثوقة (THB) | مكونات الأجهزة المنفصلة ، بشكل عام على SoC ، والتي توفر وظائف مهمة لحالات الاستخدام الأساسية للجهاز (مثل ، النطاقات الأساسية الخلوية ، DSPs ، GPU ، ومعالجات ML). |
| سلسلة محمل الإقلاع | مكون يقوم بتكوين الجهاز عند بدء التشغيل ثم يقوم بتمرير التحكم إلى نظام التشغيل Android OS. |
| بيئة تنفيذ موثوقة (TEE) | مكون تم تصميمه للحماية حتى من OS Kernel معادية (على سبيل المثال ، TrustZone و Hypervisors ، مثل pKVM ، التي تحمي الأجهزة الظاهرية من OS Kernel). |
| Secure Enclave / Secure Element (SE) | مكون جهاز اختياري مصمم للحماية من جميع المكونات الأخرى على الجهاز ومن الهجوم المادي ، كما هو محدد في مقدمة إلى العناصر الآمنة . يتضمن ذلك شريحة Titan-M الموجودة في بعض أجهزة Android. |
خطورة
تعكس شدة الخطأ عمومًا الضرر المحتمل الذي يمكن أن يحدث إذا تم استغلال الخطأ بنجاح. استخدم المعايير التالية لتحديد مدى الخطورة.
| تقييم | نتيجة الاستغلال الناجح |
|---|---|
| شديد الأهمية |
|
| عالي |
|
| معتدل |
|
| قليل |
|
| تأثير أمني ضئيل (NSI) |
|
معدلات التصنيف
في حين أنه من السهل تحديد شدة الثغرات الأمنية ، فقد تتغير التصنيفات بناءً على الظروف.
| سبب | تأثير |
|---|---|
| يتطلب التشغيل كسياق ذي امتياز لتنفيذ الهجوم (لا ينطبق على TEE و SE و Hypervisor مثل pKVM) | -1 الشدة |
| التفاصيل الخاصة بالثغرات الأمنية تحد من تأثير المشكلة | -1 الشدة |
| تجاوز المصادقة البيومترية التي تتطلب معلومات بيومترية مباشرة من مالك الجهاز | -1 الشدة |
| تخفف تكوينات برنامج التحويل البرمجي أو النظام الأساسي من ثغرة أمنية في التعليمات البرمجية المصدر | شدة معتدلة إذا كانت الثغرة الأمنية الأساسية متوسطة أو أعلى |
| يتطلب وصولاً ماديًا إلى الأجزاء الداخلية للجهاز ولا يزال ممكنًا إذا كان الجهاز مغلقًا أو لم يتم إلغاء قفله منذ تشغيله | -1 الشدة |
| يتطلب الوصول المادي إلى الأجزاء الداخلية للجهاز أثناء تشغيل الجهاز وتم إلغاء قفله مسبقًا | -2 شدة |
| هجوم محلي يتطلب إلغاء قفل سلسلة أداة تحميل التشغيل | ليس أعلى من منخفض |
| هجوم محلي يتطلب وضع المطور أو أي إعدادات وضع مطور ثابتة ليتم تمكينها حاليًا على الجهاز (وليس خطأ في وضع المطور نفسه). | ليس أعلى من منخفض |
| إذا لم يكن هناك مجال SELinux يمكنه إجراء العملية بموجب سياسة SEPolicy المقدمة من Google | تأثير أمني ضئيل |
محلي مقابل قريب مقابل بعيد
يشير ناقل الهجوم عن بُعد إلى أنه يمكن استغلال الخطأ دون تثبيت تطبيق أو بدون وصول فعلي إلى الجهاز. يتضمن ذلك الأخطاء التي يمكن تشغيلها من خلال التصفح إلى صفحة ويب ، أو قراءة بريد إلكتروني ، أو تلقي رسالة SMS ، أو الاتصال بشبكة معادية. لغرض تقييمات الخطورة لدينا ، نعتبر أيضًا ناقلات الهجوم "القريبة" بعيدة. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل المهاجم الذي يكون فعليًا بالقرب من الجهاز المستهدف ، على سبيل المثال ، خطأ يتطلب إرسال حزم Wi-Fi أو Bluetooth مشوهة. نحن نعتبر الهجمات ذات النطاق العريض (UWB) والهجمات التي تعتمد على تقنية NFC بمثابة هجمات قريبة وبالتالي بعيدة.
تتطلب الهجمات المحلية من الضحية تشغيل تطبيق ، إما عن طريق تثبيت تطبيق وتشغيله أو بالموافقة على تشغيل تطبيق فوري . سيتم اعتبار الأجهزة المصاحبة المقترنة على أنها أجهزة محلية. لغرض تقييمات الخطورة ، يعتبر فريق أمان Android أيضًا متجهات الهجوم المادي محلية. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل مهاجم لديه وصول فعلي إلى الجهاز ، على سبيل المثال خطأ في شاشة القفل أو خطأ يتطلب توصيل كبل USB.
أمن الشبكة
يفترض Android أن جميع الشبكات معادية ويمكنها شن هجمات أو التجسس على حركة المرور. بينما يؤمن أمان طبقة الارتباط (على سبيل المثال ، تشفير Wi-Fi) الاتصال بين الجهاز ونقطة الوصول المتصلة به ، فإنه لا يفعل شيئًا لتأمين الروابط المتبقية في السلسلة بين الجهاز والخوادم التي يتصل بها.
على النقيض من ذلك ، يحمي HTTPS عادةً الاتصال بالكامل من طرف إلى طرف ، ويقوم بتشفير البيانات عند مصدرها ، ثم يقوم بفك تشفيرها والتحقق منها فقط بمجرد وصولها إلى وجهتها النهائية. لهذا السبب ، تم تصنيف الثغرات الأمنية التي تهدد أمان شبكة طبقة الارتباط بأنها أقل خطورة من الثغرات الأمنية في HTTPS / TLS: تشفير Wi-Fi وحده غير كافٍ لمعظم الاتصالات على الإنترنت.
المصادقة البيومترية
تعد المصادقة البيومترية مساحة صعبة ، وحتى أفضل الأنظمة يمكن خداعها من خلال شبه مطابقة (راجع مدونة مطوري Android: Lockscreen وتحسينات المصادقة في Android 11 ). تميز تصنيفات الخطورة هذه بين فئتين من الهجمات وتهدف إلى عكس المخاطر الفعلية التي يتعرض لها المستخدم النهائي.
تسمح الفئة الأولى من الهجمات بتجاوز المصادقة البيومترية بطريقة قابلة للتعميم ، بدون بيانات بيومترية عالية الجودة من المالك. على سبيل المثال ، إذا تمكن المهاجم من وضع قطعة من اللثة على مستشعر بصمات الأصابع ، ومنح الوصول إلى الجهاز بناءً على البقايا المتبقية على المستشعر ، فهذه هجوم بسيط يمكن تنفيذه على أي جهاز حساس. لا يتطلب أي معرفة بمالك الجهاز. نظرًا لأنه قابل للتعميم ويحتمل أن يؤثر على عدد أكبر من المستخدمين ، فإن هذا الهجوم يتلقى تصنيف الخطورة الكامل (على سبيل المثال ، مرتفع ، لتجاوز Lockscreen).
تتضمن فئة الهجمات الأخرى عمومًا أداة هجوم عرض تقديمي (محاكاة ساخرة) استنادًا إلى مالك الجهاز. في بعض الأحيان يكون من السهل نسبيًا الحصول على هذه المعلومات البيومترية (على سبيل المثال ، إذا كانت صورة الملف الشخصي لشخص ما على وسائل التواصل الاجتماعي كافية لخداع المصادقة البيومترية ، فإن تجاوز القياسات الحيوية سيحصل على تصنيف الخطورة الكامل). ولكن إذا احتاج المهاجم إلى الحصول على بيانات المقاييس الحيوية مباشرة من مالك الجهاز (على سبيل المثال ، مسح الأشعة تحت الحمراء لوجهه) ، فهذا يمثل حاجزًا كبيرًا بما يكفي للحد من عدد الأشخاص المتأثرين بالهجوم ، لذلك هناك معدل -1 .
SYSTEM_ALERT_WINDOW و Tapjacking
للحصول على معلومات حول سياساتنا المتعلقة بـ SYSTEM_ALERT_WINDOW و Tapjacking ، راجع قسم " Tapjacking / Overlay SYSTEM_ALERT_WINDOW ثغرة أمنية على شاشة غير حساسة للأمان " في BugHunter University's Bugs مع عدم وجود صفحة تأثير أمني .
أمان متعدد المستخدمين في نظام التشغيل Android Automotive OS
يعتمد نظام التشغيل Android Automotive OS نموذج أمان متعدد المستخدمين يختلف عن عوامل الشكل الأخرى. كل مستخدم Android مخصص للاستخدام من قبل شخص مادي مختلف. على سبيل المثال ، يمكن تعيين مستخدم ضيف مؤقت لصديق يقترض السيارة من مالك السيارة. لاستيعاب حالات الاستخدام مثل هذه ، يمكن للمستخدمين افتراضيًا الوصول إلى المكونات الضرورية اللازمة لاستخدام السيارة ، مثل إعدادات شبكة Wi-Fi والشبكة الخلوية.
المكون المتأثر
يعتمد فريق التطوير المسؤول عن إصلاح الخطأ على المكون الموجود فيه الخطأ. يمكن أن يكون مكونًا أساسيًا لمنصة Android ، أو برنامج تشغيل kernel مقدمًا من قبل الشركة المصنعة للمعدات الأصلية (OEM) ، أو أحد التطبيقات المحملة مسبقًا على أجهزة Pixel .
يتم إصلاح الأخطاء في كود AOSP بواسطة فريق هندسة Android. قد يتم إصلاح الأخطاء منخفضة الخطورة ، أو الأخطاء الموجودة في مكونات معينة ، أو الأخطاء المعروفة بالفعل للجمهور مباشرةً في الفرع الرئيسي لـ AOSP المتاح للجمهور ؛ وإلا سيتم إصلاحها في مستودعاتنا الداخلية أولاً.
يعد المكون أيضًا عاملاً في كيفية حصول المستخدمين على التحديثات. يتطلب الخلل في الإطار أو النواة تحديثًا للبرامج الثابتة عبر الهواء (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/docs/security
- https://developer.android.com/training/articles/security-tips
التقارير
ينشر فريق أمان Android أحيانًا تقارير أو مستندات تقنية. انظر تقارير الأمان لمزيد من التفاصيل.
وفريق أمان Android مسؤول عن إدارة الثغرات الأمنية المكتشفة في نظام Android الأساسي والعديد من تطبيقات Android الأساسية المجمعة مع أجهزة Android.
يكتشف فريق أمان Android ثغرات أمنية من خلال البحث الداخلي ويستجيب أيضًا للأخطاء التي أبلغت عنها جهات خارجية. تتضمن مصادر الأخطاء الخارجية المشكلات التي تم الإبلاغ عنها من خلال نموذج الثغرات الأمنية ، والبحوث الأكاديمية المنشورة والمنشورة مسبقًا ، والمشرفين على إدارة المشروع مفتوح المصدر ، والإشعارات من شركائنا في تصنيع الأجهزة ، والمشكلات التي تم الكشف عنها علنًا على المدونات أو وسائل التواصل الاجتماعي.
الإبلاغ عن مشكلات الأمان
يمكن لأي مطور أو مستخدم Android أو باحث أمني إخطار فريق أمان Android بمشكلات الأمان المحتملة من خلال نموذج الثغرة الأمنية .
الأخطاء التي تم تمييزها على أنها مشكلات أمنية ليست مرئية من الخارج ، ولكن قد تظهر في النهاية بعد تقييم المشكلة أو حلها. إذا كنت تخطط لإرسال اختبار تصحيح أو اختبار مجموعة اختبار التوافق (CTS) لحل مشكلة أمنية ، فيرجى إرفاقه بتقرير الخطأ وانتظر الرد قبل تحميل الرمز إلى AOSP.
فرز البق
تتمثل المهمة الأولى في معالجة الثغرة الأمنية في تحديد مدى خطورة الخطأ والمكوّن المتأثر في Android. تحدد درجة الخطورة كيفية ترتيب المشكلة حسب الأولوية ، ويحدد المكون من يصلح الخطأ ، ومن يتم إخطاره ، وكيف يتم نشر الإصلاح للمستخدمين.
أنواع السياق
يغطي هذا الجدول تعريفات سياقات أمان الأجهزة والبرامج. يمكن تعريف السياق من خلال حساسية البيانات التي يعالجها عادةً أو المنطقة التي يتم تشغيله فيها. ليست كل سياقات الأمان قابلة للتطبيق على جميع الأنظمة. تم ترتيب هذا الجدول من الأقل إلى الأكثر امتيازًا.
| نوع السياق | تعريف النوع |
|---|---|
| سياق مقيد | بيئة تنفيذ مقيدة حيث يتم توفير الحد الأدنى فقط من الأذونات. على سبيل المثال ، تقوم التطبيقات الموثوقة بمعالجة البيانات غير الموثوق بها داخل بيئة وضع الحماية. |
| سياق غير مميز | بيئة تنفيذ نموذجية متوقعة بواسطة كود غير مميز. على سبيل المثال ، تطبيق Android يتم تشغيله في مجال SELinux بسمة untrusted_app_all . |
| سياق متميز | بيئة تنفيذ متميزة قد تتمتع بإمكانية الوصول إلى أذونات مرتفعة ، وتتعامل مع العديد من معلومات تحديد الهوية الشخصية للمستخدمين ، و / أو تحافظ على تكامل النظام. على سبيل المثال ، تطبيق Android به إمكانيات يحظرها نطاق SELinux untrusted_app أو الوصول إلى أذونات privileged|signature . |
| OS Kernel | الوظيفة التي:
|
| قاعدة الأجهزة الموثوقة (THB) | مكونات الأجهزة المنفصلة ، بشكل عام على SoC ، والتي توفر وظائف مهمة لحالات الاستخدام الأساسية للجهاز (مثل ، النطاقات الأساسية الخلوية ، DSPs ، GPU ، ومعالجات ML). |
| سلسلة Bootloader | مكون يقوم بتكوين الجهاز عند بدء التشغيل ثم يقوم بتمرير التحكم إلى نظام التشغيل Android OS. |
| بيئة تنفيذ موثوقة (TEE) | مكون تم تصميمه للحماية حتى من OS Kernel معادية (على سبيل المثال ، TrustZone و Hypervisors ، مثل pKVM ، التي تحمي الأجهزة الظاهرية من OS Kernel). |
| Secure Enclave / Secure Element (SE) | مكون جهاز اختياري مصمم للحماية من جميع المكونات الأخرى على الجهاز ومن الهجوم المادي ، كما هو محدد في مقدمة إلى العناصر الآمنة . يتضمن ذلك شريحة Titan-M الموجودة في بعض أجهزة Android. |
خطورة
تعكس شدة الخطأ عمومًا الضرر المحتمل الذي يمكن أن يحدث إذا تم استغلال الخطأ بنجاح. استخدم المعايير التالية لتحديد مدى الخطورة.
| تقييم | نتيجة الاستغلال الناجح |
|---|---|
| شديد الأهمية |
|
| عالي |
|
| معتدل |
|
| قليل |
|
| تأثير أمني ضئيل (NSI) |
|
معدلات التصنيف
في حين أنه من السهل تحديد شدة الثغرات الأمنية ، فقد تتغير التصنيفات بناءً على الظروف.
| سبب | تأثير |
|---|---|
| يتطلب التشغيل كسياق ذي امتياز لتنفيذ الهجوم (لا ينطبق على TEE و SE و Hypervisor مثل pKVM) | -1 الشدة |
| التفاصيل الخاصة بالثغرات الأمنية تحد من تأثير المشكلة | -1 الشدة |
| تجاوز المصادقة البيومترية التي تتطلب معلومات بيومترية مباشرة من مالك الجهاز | -1 الشدة |
| تخفف تكوينات برنامج التحويل البرمجي أو النظام الأساسي من ثغرة أمنية في التعليمات البرمجية المصدر | شدة معتدلة إذا كانت الثغرة الأمنية الأساسية متوسطة أو أعلى |
| يتطلب وصولاً ماديًا إلى الأجزاء الداخلية للجهاز ولا يزال ممكنًا إذا كان الجهاز مغلقًا أو لم يتم إلغاء قفله منذ تشغيله | -1 الشدة |
| يتطلب الوصول المادي إلى الأجزاء الداخلية للجهاز أثناء تشغيل الجهاز وتم إلغاء قفله مسبقًا | -2 شدة |
| هجوم محلي يتطلب إلغاء قفل سلسلة أداة تحميل التشغيل | ليس أعلى من منخفض |
| هجوم محلي يتطلب وضع المطور أو أي إعدادات وضع مطور ثابتة ليتم تمكينها حاليًا على الجهاز (وليس خطأ في وضع المطور نفسه). | ليس أعلى من منخفض |
| إذا لم يكن هناك مجال SELinux يمكنه إجراء العملية بموجب سياسة SEPolicy المقدمة من Google | تأثير أمني ضئيل |
محلي مقابل قريب مقابل بعيد
يشير ناقل الهجوم عن بُعد إلى أنه يمكن استغلال الخطأ دون تثبيت تطبيق أو بدون وصول فعلي إلى الجهاز. يتضمن ذلك الأخطاء التي يمكن تشغيلها من خلال التصفح إلى صفحة ويب ، أو قراءة بريد إلكتروني ، أو تلقي رسالة SMS ، أو الاتصال بشبكة معادية. لغرض تقييمات الخطورة لدينا ، نعتبر أيضًا ناقلات الهجوم "القريبة" بعيدة. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل المهاجم الذي يكون فعليًا بالقرب من الجهاز المستهدف ، على سبيل المثال ، خطأ يتطلب إرسال حزم Wi-Fi أو Bluetooth مشوهة. نحن نعتبر الهجمات ذات النطاق العريض (UWB) والهجمات التي تعتمد على تقنية NFC بمثابة هجمات قريبة وبالتالي بعيدة.
تتطلب الهجمات المحلية من الضحية تشغيل تطبيق ، إما عن طريق تثبيت تطبيق وتشغيله أو بالموافقة على تشغيل تطبيق فوري . سيتم اعتبار الأجهزة المصاحبة المقترنة على أنها أجهزة محلية. لغرض تقييمات الخطورة ، يعتبر فريق أمان Android أيضًا متجهات الهجوم المادي محلية. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل مهاجم لديه وصول فعلي إلى الجهاز ، على سبيل المثال خطأ في شاشة القفل أو خطأ يتطلب توصيل كبل USB.
أمن الشبكة
يفترض Android أن جميع الشبكات معادية ويمكنها شن هجمات أو التجسس على حركة المرور. بينما يؤمن أمان طبقة الارتباط (على سبيل المثال ، تشفير Wi-Fi) الاتصال بين الجهاز ونقطة الوصول المتصلة به ، فإنه لا يفعل شيئًا لتأمين الروابط المتبقية في السلسلة بين الجهاز والخوادم التي يتصل بها.
على النقيض من ذلك ، يحمي HTTPS عادةً الاتصال بالكامل من طرف إلى طرف ، ويقوم بتشفير البيانات عند مصدرها ، ثم يقوم بفك تشفيرها والتحقق منها فقط بمجرد وصولها إلى وجهتها النهائية. لهذا السبب ، تم تصنيف الثغرات الأمنية التي تهدد أمان شبكة طبقة الارتباط بأنها أقل خطورة من الثغرات الأمنية في HTTPS / TLS: تشفير Wi-Fi وحده غير كافٍ لمعظم الاتصالات على الإنترنت.
المصادقة البيومترية
تعد المصادقة البيومترية مساحة صعبة ، وحتى أفضل الأنظمة يمكن خداعها من خلال شبه مطابقة (راجع مدونة مطوري Android: Lockscreen وتحسينات المصادقة في Android 11 ). تميز تصنيفات الخطورة هذه بين فئتين من الهجمات وتهدف إلى عكس المخاطر الفعلية التي يتعرض لها المستخدم النهائي.
تسمح الفئة الأولى من الهجمات بتجاوز المصادقة البيومترية بطريقة قابلة للتعميم ، بدون بيانات بيومترية عالية الجودة من المالك. على سبيل المثال ، إذا تمكن المهاجم من وضع قطعة من اللثة على مستشعر بصمات الأصابع ، ومنح الوصول إلى الجهاز بناءً على البقايا المتبقية على المستشعر ، فهذه هجوم بسيط يمكن تنفيذه على أي جهاز حساس. لا يتطلب أي معرفة بمالك الجهاز. نظرًا لأنه قابل للتعميم ويحتمل أن يؤثر على عدد أكبر من المستخدمين ، فإن هذا الهجوم يتلقى تصنيف الخطورة الكامل (على سبيل المثال ، مرتفع ، لتجاوز Lockscreen).
تتضمن فئة الهجمات الأخرى عمومًا أداة هجوم عرض تقديمي (محاكاة ساخرة) استنادًا إلى مالك الجهاز. في بعض الأحيان يكون من السهل نسبيًا الحصول على هذه المعلومات البيومترية (على سبيل المثال ، إذا كانت صورة الملف الشخصي لشخص ما على وسائل التواصل الاجتماعي كافية لخداع المصادقة البيومترية ، فإن تجاوز القياسات الحيوية سيحصل على تصنيف الخطورة الكامل). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.
SYSTEM_ALERT_WINDOW and Tapjacking
For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.
Multi-user security in Android Automotive OS
Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.
Affected component
The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.
Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.
The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.
Notifying partners
When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.
Releasing code to AOSP
If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.
Receiving Android updates
Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.
Updating Google services
In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.
Other resources
Information for Android app developers: https://developer.android.com
Security information exists throughout the Android Open Source and Developer sites. Good places to start:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Reports
Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2023-08-15 (حسب التوقيت العالمي المتفَّق عليه)