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

يتولى فريق أمان Android مسؤولية إدارة الثغرات الأمنية المكتشفة في نظام Android الأساسي والعديد من تطبيقات Android الأساسية المجمعة مع أجهزة Android.

يعثر فريق أمان Android على الثغرات الأمنية من خلال البحث الداخلي ويستجيب أيضًا للأخطاء التي أبلغت عنها الجهات الخارجية. تتضمن مصادر الأخطاء الخارجية المشكلات التي تم الإبلاغ عنها من خلال نموذج الثغرات الأمنية ، والأبحاث الأكاديمية المنشورة والمسبقة النشر، ومشرفي المشروعات مفتوحة المصدر، والإشعارات الواردة من شركائنا في مصنعي الأجهزة، والمشكلات التي تم الكشف عنها علنًا والمنشورة على المدونات أو وسائل التواصل الاجتماعي.

الإبلاغ عن المشكلات الأمنية

يمكن لأي مطور أو مستخدم Android أو باحث أمني إخطار فريق أمان Android بالمشكلات الأمنية المحتملة من خلال نموذج الثغرات الأمنية .

الأخطاء التي تم وضع علامة عليها كمشكلات أمنية لا تكون مرئية خارجيًا، ولكن قد تصبح مرئية في النهاية بعد تقييم المشكلة أو حلها. إذا كنت تخطط لإرسال تصحيح أو اختبار مجموعة اختبار التوافق (CTS) لحل مشكلة أمنية، فيرجى إرفاقه بتقرير الأخطاء وانتظار الرد قبل تحميل الكود إلى AOSP.

فرز الأخطاء

تتمثل المهمة الأولى في التعامل مع الثغرة الأمنية في تحديد مدى خطورة الخطأ ومكون Android المتأثر. تحدد مدى الخطورة كيفية تحديد أولوية المشكلة، ويحدد المكون من يقوم بإصلاح الخطأ، ومن يتم إعلامه، وكيفية نشر الإصلاح للمستخدمين.

أنواع السياق

يغطي هذا الجدول تعريفات سياقات أمان الأجهزة والبرامج. يمكن تحديد السياق من خلال حساسية البيانات التي يعالجها عادة أو المنطقة التي يعمل فيها. لا تنطبق كافة سياقات الأمان على كافة الأنظمة. هذا الجدول مرتب من الأقل إلى الأكثر امتيازا.

نوع السياق تعريف النوع
سياق مقيد بيئة تنفيذ مقيدة حيث يتم توفير الحد الأدنى من الأذونات فقط.

على سبيل المثال، تقوم التطبيقات الموثوقة بمعالجة البيانات غير الموثوق بها داخل بيئة معزولة.
سياق غير مميز بيئة تنفيذ نموذجية تتوقعها تعليمات برمجية لا تتمتع بأي امتيازات.

على سبيل المثال، تطبيق Android يعمل في مجال SELinux باستخدام السمة untrusted_app_all .
السياق المميز بيئة تنفيذ مميزة قد تتمتع بإمكانية الوصول إلى أذونات مرتفعة، وتتعامل مع معلومات تحديد الهوية الشخصية (PII) المتعددة للمستخدمين، و/أو تحافظ على سلامة النظام.

على سبيل المثال، تطبيق Android يتمتع بإمكانيات محظورة بواسطة مجال SELinux untrusted_app أو يتمتع بإمكانية الوصول إلى أذونات privileged|signature .
نواة نظام التشغيل الوظيفة التي:
  • هو جزء من النواة
  • يعمل في نفس سياق وحدة المعالجة المركزية مثل النواة (على سبيل المثال، برامج تشغيل الأجهزة)
  • لديه وصول مباشر إلى ذاكرة kernel (على سبيل المثال، مكونات الأجهزة الموجودة على الجهاز)
  • لديه القدرة على تحميل البرامج النصية في مكون kernel (على سبيل المثال، eBPF)
  • هي إحدى خدمات المستخدم القليلة التي تعتبر مكافئة لـ kernel (مثل apexd و bpfloader و init و ueventd و vold ).
قاعدة الأجهزة الموثوقة (THB) مكونات الأجهزة المنفصلة، ​​الموجودة بشكل عام على SoC، والتي توفر وظائف مهمة لحالات الاستخدام الأساسية للجهاز (مثل النطاقات الأساسية الخلوية، ومزودي الخدمات الرقمية، ووحدات معالجة الرسومات، ومعالجات تعلم الآلة).
سلسلة محمل الإقلاع مكون يقوم بتكوين الجهاز عند التشغيل ثم يمرر التحكم إلى نظام التشغيل Android.
بيئة التنفيذ الموثوقة (TEE) مكون تم تصميمه ليكون محميًا حتى من نظام التشغيل Kernel المعادي (على سبيل المثال، TrustZone وبرامج Hypervisor، مثل pKVM، التي تحمي الأجهزة الافتراضية من OS Kernel).
المنطقة الآمنة / العنصر الآمن (SE) مكون جهاز اختياري مصمم ليكون محميًا من جميع المكونات الأخرى الموجودة على الجهاز ومن الهجمات المادية، كما هو محدد في مقدمة إلى العناصر الآمنة .

يتضمن ذلك شريحة Titan-M الموجودة في بعض أجهزة Android.

خطورة

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

تقييم نتيجة الاستغلال الناجح
شديد الأهمية
  • تنفيذ التعليمات البرمجية التعسفية في TEE أو SE
  • تجاوز آليات البرامج المصممة لمنع تعطل البرامج أو مكونات الأجهزة المتعلقة بالسلامة (على سبيل المثال، الحماية الحرارية)
  • الوصول عن بعد إلى بيانات الاعتماد الحساسة المستخدمة لمصادقة الخدمة عن بعد (على سبيل المثال، كلمات مرور الحساب أو الرموز المميزة لحاملها)
  • تنفيذ التعليمات البرمجية التعسفية عن بعد ضمن سياق النطاق الأساسي الخلوي دون أي تفاعل من المستخدم (على سبيل المثال، استغلال خطأ في خدمة الراديو الخلوية)
  • تنفيذ التعليمات البرمجية التعسفية عن بعد في سياق مميز، أو سلسلة أداة تحميل التشغيل، أو THB، أو OS Kernel
  • التجاوز عن بعد لمتطلبات تفاعل المستخدم عند تثبيت الحزمة أو السلوك المماثل
  • تجاوز عن بعد لمتطلبات تفاعل المستخدم للمطور الأساسي أو الأمان أو إعدادات الخصوصية
  • رفض الخدمة المستمر عن بعد (دائم، يتطلب إعادة تحميل نظام التشغيل بالكامل، أو إعادة ضبط المصنع)
  • تجاوز التمهيد الآمن عن بعد
  • الوصول غير المصرح به إلى البيانات المؤمنة بواسطة SE بما في ذلك الوصول الممكّن بواسطة مفاتيح ضعيفة في SE.
عالي
  • تجاوز كامل لميزة الأمان الأساسية (على سبيل المثال، SELinux، أو FBE، أو seccomp )
  • تجاوز عام للدفاع المتعمق أو استغلال تقنية التخفيف في سلسلة أداة تحميل التشغيل أو TEE أو SE
  • تجاوز عام لعمليات حماية نظام التشغيل التي تكشف عن الذاكرة أو محتويات الملف عبر حدود التطبيق أو المستخدم أو ملف التعريف
  • الهجمات ضد SE التي تؤدي إلى الرجوع إلى تنفيذ أقل أمانًا
  • تجاوز حماية الجهاز/حماية إعادة ضبط المصنع/قيود الناقل
  • تجاوز متطلبات تفاعل المستخدم التي يتم تأمينها بواسطة TEE
  • ثغرة أمنية في التشفير تسمح بشن هجمات ضد البروتوكولات الشاملة، بما في ذلك الهجمات ضد أمان طبقة النقل (TLS) والبلوتوث (BT).
  • الوصول المحلي إلى بيانات الاعتماد الحساسة المستخدمة لمصادقة الخدمة عن بعد (على سبيل المثال، كلمات مرور الحساب أو الرموز المميزة لحاملها)
  • تنفيذ التعليمات البرمجية التعسفية المحلية في سياق مميز، أو سلسلة أداة تحميل التشغيل، أو THB، أو OS Kernel
  • تجاوز التمهيد الآمن المحلي
  • تجاوز قفل الشاشة
  • التجاوز المحلي لمتطلبات تفاعل المستخدم للمطور الأساسي أو الأمان أو إعدادات الخصوصية
  • التجاوز المحلي لمتطلبات تفاعل المستخدم عند تثبيت الحزمة أو السلوك المعادل
  • الحرمان المحلي المستمر من الخدمة (دائم، يتطلب إعادة تحميل نظام التشغيل بالكامل، أو إعادة ضبط المصنع)
  • الوصول عن بعد إلى البيانات المحمية (أي البيانات التي تقتصر على سياق مميز)
  • تنفيذ التعليمات البرمجية التعسفية عن بعد في سياق غير مميز
  • منع الوصول عن بعد إلى الخدمة الخلوية أو خدمة Wi-Fi دون تدخل المستخدم (على سبيل المثال، تعطل خدمة الراديو الخلوية بحزمة مشوهة)
  • التجاوز عن بعد لمتطلبات تفاعل المستخدم (الوصول إلى الوظائف أو البيانات التي يجب أن تتطلب بدء المستخدم أو إذن المستخدم)
  • الوقاية المستهدفة من الوصول إلى خدمات الطوارئ
  • نقل معلومات حساسة عبر بروتوكول شبكة غير آمن (على سبيل المثال، HTTP وBluetooth غير المشفر) عندما يتوقع الطالب إرسالًا آمنًا. لاحظ أن هذا لا ينطبق على تشفير Wi-Fi (مثل WEP)
  • الوصول غير المصرح به إلى البيانات المؤمنة بواسطة TEE، بما في ذلك الوصول الممكّن بواسطة مفاتيح ضعيفة في TEE
معتدل
  • تجاوز عام للدفاع المتعمق أو استغلال تقنية التخفيف في سياق مميز، أو THB، أو OS Kernel
  • تجاوز عام لعمليات حماية نظام التشغيل التي تكشف عن حالة العملية أو بيانات التعريف عبر حدود التطبيق أو المستخدم أو ملف التعريف
  • تجاوز تشفير Wi-Fi أو المصادقة
  • ثغرة أمنية في التشفير في أساسيات التشفير القياسية التي تسمح بتسريب النص العادي (وليست الأوليات المستخدمة في TLS)
  • الوصول المحلي إلى البيانات المحمية (أي البيانات التي تقتصر على سياق مميز)
  • تنفيذ التعليمات البرمجية التعسفية المحلية في سياق غير مميز
  • التجاوز المحلي لمتطلبات تفاعل المستخدم (الوصول إلى الوظائف أو البيانات التي تتطلب عادةً بدء المستخدم أو إذن المستخدم)
  • الوصول عن بعد إلى البيانات غير المحمية (أي البيانات التي يمكن الوصول إليها عادةً بواسطة أي تطبيق مثبت محليًا)
  • تنفيذ التعليمات البرمجية التعسفية عن بعد في سياق مقيد
  • رفض خدمة الجهاز المؤقت عن بعد (التعليق عن بعد أو إعادة التشغيل)
قليل
  • تجاوز عام للدفاع على مستوى المستخدم بعمق أو استغلال تقنية التخفيف في سياق غير مميز
  • تجاوز إذن مستوى الحماية العادي
  • ثغرة تشفيرية في الاستخدام غير القياسي
  • تجاوز عام لميزات التخصيص الموجودة على الجهاز مثل Voice Match أو Face Match
  • وثائق غير صحيحة قد تؤدي إلى ثغرة أمنية
  • تنفيذ التعليمات البرمجية التعسفية المحلية في سياق مقيد
  • نص محدد من قبل النظام يتضمن وصفًا مضللًا يؤدي إلى إنشاء توقعات أمنية زائفة
تأثير أمني ضئيل (NSI)
  • الثغرة الأمنية التي تم التخفيف من تأثيرها بواسطة واحد أو أكثر من معدِّلات التصنيف أو تغييرات البنية الخاصة بالإصدار بحيث تكون الخطورة الفعالة أقل من منخفضة، على الرغم من أن مشكلة التعليمات البرمجية الأساسية قد تظل قائمة
  • أي ثغرة أمنية تتطلب نظام ملفات تالفًا، إذا كان نظام الملفات هذا معتمدًا/مشفرًا دائمًا قبل الاستخدام.

معدّلات التصنيف

في حين أنه من السهل في كثير من الأحيان تحديد مدى خطورة الثغرات الأمنية، إلا أن التصنيفات قد تتغير بناءً على الظروف.

سبب تأثير
يتطلب التشغيل كسياق مميز لتنفيذ الهجوم (لا ينطبق على TEE وSE وبرامج Hypervisor مثل pKVM) -1 الشدة
التفاصيل الخاصة بالثغرات الأمنية تحد من تأثير المشكلة -1 الشدة
تجاوز المصادقة البيومترية الذي يتطلب معلومات بيومترية مباشرة من مالك الجهاز -1 الشدة
تعمل تكوينات المترجم أو النظام الأساسي على تخفيف الثغرة الأمنية في التعليمات البرمجية المصدر درجة خطورة متوسطة إذا كانت الثغرة الأمنية الأساسية متوسطة أو أعلى
يتطلب الوصول الفعلي إلى الأجزاء الداخلية للجهاز ولا يزال ذلك ممكنًا إذا كان الجهاز متوقفًا عن التشغيل أو لم يتم إلغاء قفله منذ تشغيله -1 الشدة
يتطلب الوصول الفعلي إلى الأجزاء الداخلية للجهاز أثناء تشغيل الجهاز وتم إلغاء قفله مسبقًا -2 الشدة
هجوم محلي يتطلب فتح سلسلة أداة تحميل التشغيل ليس أعلى من منخفض
هجوم محلي يتطلب تمكين وضع المطور أو أي إعدادات دائمة لوضع المطور حاليًا على الجهاز (ولا يعد خطأً في وضع المطور نفسه). ليس أعلى من منخفض
إذا لم يتمكن نطاق SELinux من إجراء العملية بموجب سياسة SEP المقدمة من Google تأثير أمني ضئيل

المحلية مقابل القريبة مقابل البعيدة

يشير متجه الهجوم عن بعد إلى أنه يمكن استغلال الخطأ دون تثبيت تطبيق أو دون الوصول الفعلي إلى الجهاز. يتضمن ذلك الأخطاء التي يمكن أن تحدث عن طريق تصفح صفحة ويب، أو قراءة بريد إلكتروني، أو تلقي رسالة نصية قصيرة، أو الاتصال بشبكة معادية. ولأغراض تقييمات الخطورة لدينا، فإننا نعتبر أيضًا نواقل الهجوم "القريبة" بعيدة. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل مهاجم موجود فعليًا بالقرب من الجهاز المستهدف، على سبيل المثال، خطأ يتطلب إرسال حزم Wi-Fi أو Bluetooth مشوهة. نحن نعتبر الهجمات ذات النطاق العريض للغاية (UWB) والهجمات المستندة إلى NFC بمثابة هجمات قريبة وبالتالي بعيدة.

تتطلب الهجمات المحلية من الضحية تشغيل تطبيق ما، إما عن طريق تثبيت التطبيق وتشغيله أو عن طريق الموافقة على تشغيل تطبيق فوري . سيتم اعتبار الأجهزة المصاحبة المقترنة محلية. ولأغراض تصنيفات الخطورة، يعتبر فريق أمان Android أيضًا أن نواقل الهجوم الجسدي محلية. وتشمل هذه الأخطاء التي لا يمكن استغلالها إلا من قبل مهاجم لديه حق الوصول الفعلي إلى الجهاز، على سبيل المثال خطأ في شاشة القفل أو خطأ يتطلب توصيل كابل USB.

أمن الشبكة

يفترض Android أن جميع الشبكات معادية ويمكن أن تقوم بشن هجمات أو التجسس على حركة المرور. بينما يعمل أمان طبقة الارتباط (على سبيل المثال، تشفير Wi-Fi) على تأمين الاتصال بين الجهاز ونقطة الوصول التي يتصل بها، فإنه لا يفعل شيئًا لتأمين الروابط المتبقية في السلسلة بين الجهاز والخوادم التي يتصل بها.

على النقيض من ذلك، يحمي HTTPS عادةً الاتصال بالكامل من طرف إلى طرف، حيث يقوم بتشفير البيانات في مصدرها، ثم فك تشفيرها والتحقق منها فقط بمجرد وصولها إلى وجهتها النهائية. ولهذا السبب، تم تصنيف الثغرات الأمنية التي تهدد أمان شبكة طبقة الارتباط بأنها أقل خطورة من الثغرات الأمنية في HTTPS/TLS: تشفير Wi-Fi وحده غير كافٍ لمعظم الاتصالات على الإنترنت.

المصادقة البيومترية

تعد المصادقة البيومترية مجالًا صعبًا، وحتى أفضل الأنظمة يمكن خداعها من خلال التطابق القريب (راجع مدونة مطوري Android: تحسينات شاشة القفل والمصادقة في Android 11 ). تميز تصنيفات الخطورة هذه بين فئتين من الهجمات وتهدف إلى عكس المخاطر الفعلية على المستخدم النهائي.

تسمح الفئة الأولى من الهجمات بتجاوز المصادقة البيومترية بطريقة قابلة للتعميم، دون الحصول على بيانات بيومترية عالية الجودة من المالك. على سبيل المثال، إذا تمكن أحد المهاجمين من وضع قطعة من العلكة على مستشعر بصمات الأصابع، ومنح الوصول إلى الجهاز بناءً على البقايا المتبقية على المستشعر، فهذا هجوم بسيط يمكن تنفيذه على أي جهاز عرضة للخطر. ولا يتطلب أي معرفة بصاحب الجهاز. نظرًا لأنه قابل للتعميم ومن المحتمل أن يؤثر على عدد أكبر من المستخدمين، فإن هذا الهجوم يحصل على تصنيف الخطورة الكامل (على سبيل المثال، عالي، لتجاوز Lockscreen).

تتضمن الفئة الأخرى من الهجمات عمومًا أداة هجوم العرض التقديمي (محاكاة ساخرة) استنادًا إلى مالك الجهاز. في بعض الأحيان يكون من السهل نسبيًا الحصول على هذه المعلومات البيومترية (على سبيل المثال، إذا كانت صورة الملف الشخصي لشخص ما على وسائل التواصل الاجتماعي كافية لخداع المصادقة البيومترية، فإن تجاوز القياسات الحيوية سيحصل على تصنيف الخطورة الكامل). ولكن إذا كان المهاجم بحاجة إلى الحصول على بيانات القياسات الحيوية مباشرة من مالك الجهاز (على سبيل المثال، مسح بالأشعة تحت الحمراء لوجهه)، فهذا يمثل عائقًا كبيرًا بما يكفي للحد من عدد الأشخاص المتأثرين بالهجوم، لذلك هناك معدل -1 .

SYSTEM_ALERT_WINDOW وTapjacking

للحصول على معلومات حول سياساتنا المتعلقة بـ SYSTEM_ALERT_WINDOW و Tapjacking، راجع قسم " Tapjacking/overlay SYSTEM_ALERT_WINDOW على شاشة غير حساسة للأمان " في صفحة الأخطاء التي ليس لها تأثير أمني في جامعة BugHunter.

أمان متعدد المستخدمين في نظام التشغيل Android Automotive

يعتمد نظام التشغيل Android Automotive نموذج أمان متعدد المستخدمين يختلف عن عوامل الشكل الأخرى. تم تصميم كل مستخدم Android ليتم استخدامه من قبل شخص مادي مختلف. على سبيل المثال، يمكن تعيين مستخدم ضيف مؤقت لصديق يستعير السيارة من مالك السيارة. لاستيعاب حالات الاستخدام مثل هذه، يتمتع المستخدمون افتراضيًا بإمكانية الوصول إلى المكونات الضرورية اللازمة لاستخدام السيارة، مثل Wi-Fi وإعدادات الشبكة الخلوية.

المكون المتأثر

يعتمد فريق التطوير المسؤول عن إصلاح الخلل على المكون الذي يوجد به الخلل. ويمكن أن يكون مكونًا أساسيًا في نظام Android الأساسي، أو برنامج تشغيل kernel توفره الشركة المصنعة للمعدات الأصلية (OEM)، أو أحد التطبيقات المحملة مسبقًا على أجهزة Pixel. .

تم إصلاح الأخطاء في كود AOSP بواسطة فريق هندسة Android. قد يتم إصلاح الأخطاء منخفضة الخطورة، أو الأخطاء في مكونات معينة، أو الأخطاء المعروفة للعامة بالفعل مباشرةً في فرع AOSP الرئيسي المتاح للعامة؛ وإلا فسيتم إصلاحها في مستودعاتنا الداخلية أولاً.

يعد المكون أيضًا عاملاً في كيفية حصول المستخدمين على التحديثات. يتطلب وجود خطأ في إطار العمل أو النواة تحديث البرنامج الثابت عبر الهواء (OTA) الذي يحتاج كل مصنع OEM إلى دفعه. يمكن إرسال خطأ في تطبيق أو مكتبة منشورة في Google Play (على سبيل المثال، Gmail أو خدمات Google Play أو WebView) إلى مستخدمي Android كتحديث من Google Play.

إخطار الشركاء

عندما يتم إصلاح ثغرة أمنية في AOSP في نشرة أمان Android، فسنقوم بإخطار شركاء Android بتفاصيل المشكلة وتوفير التصحيحات. تتغير قائمة الإصدارات المدعومة من backport مع كل إصدار جديد من Android. اتصل بالشركة المصنعة لجهازك للحصول على قائمة الأجهزة المدعومة.

إطلاق الكود إلى AOSP

إذا كان خطأ الأمان موجودًا في مكون AOSP، فسيتم إرسال الإصلاح إلى AOSP بعد إصدار OTA للمستخدمين. قد يتم إرسال إصلاحات المشكلات منخفضة الخطورة مباشرة إلى فرع AOSP الرئيسي قبل أن يتوفر الإصلاح للأجهزة من خلال OTA.

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

يتم تسليم تحديثات نظام Android عمومًا إلى الأجهزة من خلال حزم تحديث OTA. قد تأتي هذه التحديثات من الشركة المصنعة للجهاز (OEM) التي أنتجت الجهاز أو من شركة الاتصالات التي توفر الخدمة للجهاز. تأتي تحديثات جهاز Google Pixel من فريق Google Pixel بعد اجتياز إجراء اختبار القبول الفني لشركة الاتصالات (TA). تنشر Google أيضًا صور مصنع Pixel التي يمكن تحميلها جانبيًا على الأجهزة.

تحديث خدمات جوجل

بالإضافة إلى توفير تصحيحات للأخطاء الأمنية، يقوم فريق أمان Android بمراجعة الأخطاء الأمنية لتحديد ما إذا كانت هناك طرق أخرى لحماية المستخدمين. على سبيل المثال، يقوم Google Play بفحص جميع التطبيقات وإزالة أي تطبيق يحاول استغلال خطأ أمني. بالنسبة إلى التطبيقات المثبتة من خارج Google Play، قد تستخدم الأجهزة المزودة بخدمات Google Play أيضًا ميزة التحقق من التطبيقات لتحذير المستخدمين بشأن التطبيقات التي قد تكون ضارة.

مصادر أخرى

معلومات لمطوري تطبيقات Android: https://developer.android.com

تتوفر معلومات الأمان عبر مواقع Android مفتوحة المصدر ومواقع المطورين. أماكن جيدة للبدء:

التقارير

في بعض الأحيان ينشر فريق Android Security تقارير أو مستندات تقنية. راجع تقارير الأمان لمزيد من التفاصيل.