تحديثات وموارد الأمان

فريق أمان 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)	مكون اختياري مصمم للحماية من جميع المكونات الأخرى على الجهاز ومن الهجوم المادي ، كما هو محدد في مقدمة إلى العناصر الآمنة .

خطورة

تعكس شدة الخطأ عمومًا الضرر المحتمل الذي يمكن أن يحدث إذا تم استغلال الخطأ بنجاح. استخدم المعايير التالية لتحديد مدى الخطورة.

تقييم	نتيجة الاستغلال الناجح
حرج	الوصول غير المصرح به إلى البيانات المؤمنة من قبل SE تنفيذ التعليمات البرمجية التعسفية في TEE أو SE تنفيذ التعليمات البرمجية التعسفية عن بعد في عملية ذات امتياز ، أو أداة تحميل التشغيل ، أو TCB رفض الخدمة الدائم عن بُعد (عدم قابلية تشغيل الجهاز: دائم تمامًا أو يتطلب إعادة تحميل نظام التشغيل بالكامل أو إعادة ضبط المصنع) تجاوز عن بعد لمتطلبات تفاعل المستخدم عند تثبيت الحزمة أو السلوك المكافئ تجاوز عن بُعد لمتطلبات تفاعل المستخدم لأي مطور أو إعدادات أمان أو خصوصية تجاوز التمهيد الآمن عن بعد تجاوز آليات الأمان المصممة لمنع تعطل مكونات الأجهزة المهمة (على سبيل المثال ، الحماية الحرارية)
عالي	تجاوز التمهيد الآمن المحلي تجاوز كامل لميزة الأمان الأساسية (مثل SELinux أو FDE أو seccomp) تنفيذ التعليمات البرمجية التعسفية عن بعد في عملية غير مميزة تنفيذ التعليمات البرمجية التعسفية المحلية في عملية ذات امتياز أو أداة تحميل التشغيل أو TCB الوصول غير المصرح به إلى البيانات المحمية بواسطة TEE الهجمات ضد SE التي تؤدي إلى خفض التصنيف إلى تطبيق أقل أمانًا تجاوز محلي لمتطلبات تفاعل المستخدم عند تثبيت الحزمة أو السلوك المكافئ الوصول عن بعد إلى البيانات المحمية (البيانات التي تقتصر على عملية مميزة) رفض محلي دائم للخدمة (عدم قابلية تشغيل الجهاز: دائم أو يتطلب إعادة تحميل نظام التشغيل بالكامل أو إعادة ضبط المصنع) تجاوز متطلبات تفاعل المستخدم عن بُعد (الوصول إلى الوظائف أو البيانات التي تتطلب عادةً إما بدء المستخدم أو إذن المستخدم) نقل معلومات حساسة عبر بروتوكول شبكة غير آمن (على سبيل المثال ، HTTP وبلوتوث غير مشفر) عندما يتوقع مقدم الطلب إرسالًا آمنًا (لاحظ أن هذا لا ينطبق على تشفير Wi-Fi ، مثل WEP) تجاوز عام للدفاع في العمق أو استغلال تقنية التخفيف في أداة تحميل التشغيل أو TEE أو SE تجاوز عام لعمليات حماية نظام التشغيل التي تعزل بيانات التطبيق أو ملفات تعريف المستخدمين عن بعضها البعض تجاوز محلي لمتطلبات تفاعل المستخدم لأي مطور أو إعدادات أمان أو خصوصية ثغرة أمنية في التشفير في أمان طبقة النقل القياسية (TLS) التي تسمح بهجمات على المسار تجاوز Lockscreen تجاوز حماية الجهاز / حماية إعادة ضبط المصنع / قيود الناقل المنع المستهدف للوصول إلى خدمات الطوارئ تجاوز متطلبات تفاعل المستخدم التي يتم تأمينها بواسطة TEE
معتدل	تنفيذ التعليمات البرمجية التعسفي عن بعد في عملية مقيدة رفض خدمة الجهاز المؤقت عن بُعد (تعليق أو إعادة تشغيل عن بُعد) تنفيذ كود تعسفي محلي في عملية غير مميزة تجاوز عام للدفاع في العمق أو استغلال تكنولوجيا التخفيف في عملية مميزة أو TCB تجاوز القيود على عملية مقيدة الوصول عن بُعد إلى البيانات غير المحمية (يمكن الوصول إلى البيانات عادةً من أي تطبيق مثبت محليًا) الوصول المحلي إلى البيانات المحمية (البيانات التي تقتصر على عملية مميزة) تجاوز محلي لمتطلبات تفاعل المستخدم (الوصول إلى الوظائف أو البيانات التي تتطلب عادةً إما بدء المستخدم أو إذن المستخدم) ثغرة تشفير في أساسيات التشفير القياسية تسمح بتسريب نص عادي (وليس الأساسيات المستخدمة في TLS) تجاوز تشفير أو مصادقة Wi-Fi
منخفض	تنفيذ كود تعسفي محلي في عملية مقيدة ضعف التشفير في الاستخدام غير القياسي تجاوز عام للدفاع على مستوى المستخدم في العمق أو استغلال تقنية التخفيف في عملية غير مميزة
تأثير أمني ضئيل (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. أماكن جيدة للبدء:

التقارير

ينشر فريق أمان Android أحيانًا تقارير أو مستندات تقنية. انظر تقارير الأمان لمزيد من التفاصيل.