تیم امنیتی اندروید مسئول مدیریت آسیبپذیریهای امنیتی کشفشده در پلتفرم اندروید و بسیاری از برنامههای اصلی اندروید است که با دستگاههای اندروید همراه هستند.
تیم امنیتی اندروید از طریق تحقیقات داخلی، آسیبپذیریهای امنیتی را پیدا میکند و همچنین به اشکالات گزارش شده توسط اشخاص ثالث پاسخ میدهد. منابع اشکالات خارجی شامل مواردی است که از طریق فرم آسیبپذیری گزارش میشوند، تحقیقات دانشگاهی منتشر شده و از پیش منتشر شده، نگهدارندگان پروژههای متنباز بالادستی، اعلانهای شرکای سازنده دستگاه ما و مشکلات افشا شده عمومی که در وبلاگها یا رسانههای اجتماعی منتشر میشوند.
گزارش مشکلات امنیتی
هر توسعهدهنده، کاربر اندروید یا محقق امنیتی میتواند از طریق فرم آسیبپذیری، تیم امنیتی اندروید را از مشکلات امنیتی بالقوه مطلع کند.
اشکالاتی که به عنوان مسائل امنیتی علامتگذاری شدهاند، از بیرون قابل مشاهده نیستند، اما ممکن است در نهایت پس از ارزیابی یا حل مشکل، قابل مشاهده شوند. اگر قصد دارید یک وصله یا تست مجموعه تست سازگاری (CTS) برای حل یک مشکل امنیتی ارسال کنید، لطفاً آن را به گزارش اشکال پیوست کنید و قبل از آپلود کد در AOSP منتظر پاسخ باشید.
اشکالات مربوط به اولویتبندی
اولین وظیفه در مدیریت یک آسیبپذیری امنیتی، شناسایی شدت اشکال و اینکه کدام مؤلفه اندروید تحت تأثیر قرار گرفته است، میباشد. شدت، نحوه اولویتبندی مشکل را تعیین میکند و مؤلفه تعیین میکند که چه کسی اشکال را برطرف میکند، به چه کسی اطلاع داده میشود و چگونه این رفع اشکال برای کاربران اعمال میشود.
انواع زمینه
این جدول تعاریف زمینههای امنیتی سختافزار و نرمافزار را پوشش میدهد. زمینه را میتوان با حساسیت دادههایی که معمولاً پردازش میکند یا منطقهای که در آن اجرا میشود تعریف کرد. همه زمینههای امنیتی برای همه سیستمها قابل اجرا نیستند. این جدول از کمترین امتیاز به بیشترین امتیاز مرتب شده است.
| نوع زمینه | تعریف نوع |
|---|---|
| زمینه محدود | یک محیط اجرای محدود که در آن فقط حداقل مجوزها ارائه میشود. برای مثال، برنامههای قابل اعتمادی که دادههای غیرقابل اعتماد را در یک محیط سندباکس پردازش میکنند. |
| زمینهی نامتعارف | یک محیط اجرایی معمول که از کد بدون امتیاز انتظار میرود. برای مثال، یک برنامه اندروید که در یک دامنه SELinux با ویژگی untrusted_app_all اجرا میشود. |
| زمینه ممتاز | یک محیط اجرایی با امتیاز بالا که ممکن است به مجوزهای سطح بالا دسترسی داشته باشد، اطلاعات هویتی چندین کاربر را مدیریت کند و/یا یکپارچگی سیستم را حفظ کند. برای مثال، یک برنامه اندروید با قابلیتهایی که توسط دامنه untrusted_app در SELinux ممنوع شده است یا به مجوزهای privileged|signature دسترسی دارد. |
| هسته سیستم عامل | عملکردی که:
|
| پایگاه سختافزاری مورد اعتماد (THB) | اجزای سختافزاری گسسته، عموماً روی SoC، که عملکردهای حیاتی برای موارد استفاده اصلی دستگاه (مانند باندهای پایه سلولی، DSPها، GPUها و پردازندههای یادگیری ماشین) را فراهم میکنند. |
| زنجیره بوت لودر | کامپوننتی که دستگاه را در هنگام بوت پیکربندی میکند و سپس کنترل را به سیستم عامل اندروید منتقل میکند. |
| محیط اجرای قابل اعتماد (TEE) | مؤلفهای که طوری طراحی شده است که حتی در برابر یک هسته سیستم عامل متخاصم نیز محافظت شود (برای مثال، TrustZone و hypervisors مانند pKVM که از ماشینهای مجازی در برابر هسته سیستم عامل محافظت میکنند). |
| محاصره امن / عنصر امن (SE) | یک جزء سختافزاری اختیاری که برای محافظت در برابر سایر اجزای دستگاه و حمله فیزیکی طراحی شده است، همانطور که در مقدمهای بر عناصر امن تعریف شده است. این شامل تراشه Titan-M موجود در برخی از دستگاههای اندرویدی نیز میشود. |
شدت
شدت یک اشکال عموماً نشاندهندهی آسیب بالقوهای است که در صورت بهرهبرداری موفقیتآمیز از یک اشکال میتواند رخ دهد. برای تعیین شدت از معیارهای زیر استفاده کنید.
| رتبهبندی | پیامد بهرهبرداری موفقیتآمیز |
|---|---|
| بحرانی |
|
| بالا |
|
| متوسط |
|
| کم |
|
| تأثیر امنیتی ناچیز (NSI) |
|
اصلاحکنندههای شدت
اگرچه تشخیص شدت آسیبپذیریهای امنیتی اغلب آسان است، اما رتبهبندیها ممکن است بر اساس شرایط تغییر کنند.
| دلیل | اثر |
|---|---|
| برای اجرای حمله، نیاز به اجرا به عنوان یک بستر ممتاز دارد (برای TEE، SE و هایپروایزرهایی مانند pKVM قابل اجرا نیست) | -1 شدت |
| جزئیات مربوط به آسیبپذیری، تأثیر مشکل را محدود میکند | -1 شدت |
| دور زدن احراز هویت بیومتریک که نیاز به اطلاعات بیومتریک مستقیم از صاحب دستگاه دارد | -1 شدت |
| پیکربندیهای کامپایلر یا پلتفرم، آسیبپذیری در کد منبع را کاهش میدهند. | شدت متوسط اگر آسیبپذیری اساسی متوسط یا بالاتر باشد |
| نیاز به دسترسی فیزیکی به قطعات داخلی دستگاه دارد و اگر دستگاه خاموش باشد یا از زمان روشن شدن قفل آن باز نشده باشد، همچنان امکانپذیر است. | -1 شدت |
| در حالی که دستگاه روشن است و قبلاً قفل آن باز شده است، نیاز به دسترسی فیزیکی به قطعات داخلی دستگاه دارد | -۲ شدت |
| یک حمله محلی که نیاز به باز کردن قفل زنجیره بوت لودر دارد | بالاتر از پایین نیست |
| یک حمله محلی که نیاز به فعال بودن حالت توسعهدهنده یا هرگونه تنظیمات دائمی حالت توسعهدهنده در دستگاه دارد (و خود یک اشکال در حالت توسعهدهنده نیست). | بالاتر از پایین نیست |
| اگر هیچ دامنه SELinux نتواند عملیات را تحت SEPolicy ارائه شده توسط گوگل انجام دهد | تأثیر امنیتی ناچیز |
محلی در مقابل پروگزیمال در مقابل دور
یک بردار حمله از راه دور نشان میدهد که این اشکال میتواند بدون نصب برنامه یا بدون دسترسی فیزیکی به دستگاه مورد سوءاستفاده قرار گیرد. این شامل اشکالاتی میشود که میتوانند با مرور یک صفحه وب، خواندن ایمیل، دریافت پیامک یا اتصال به یک شبکه متخاصم ایجاد شوند.
بردارهای حملهی نزدیک، دور در نظر گرفته میشوند. اینها شامل اشکالاتی هستند که فقط توسط مهاجمی که از نظر فیزیکی در نزدیکی دستگاه هدف قرار دارد، قابل سوءاستفاده هستند، به عنوان مثال، اشکالی که نیاز به ارسال بستههای Wi-Fi یا Bluetooth ناقص دارد. ما حملات مبتنی بر پهنای باند فوق وسیع (UWB) و NFC را به عنوان حملات نزدیک و بنابراین دور در نظر میگیریم.
حملات محلی مستلزم آن است که مهاجم از قبل به قربانی دسترسی داشته باشد. در یک مثال فرضیِ صرفاً نرمافزاری، این میتواند از طریق یک برنامه مخرب که قربانی نصب کرده است یا یک برنامه فوری که او به اجرای آن رضایت داده است، انجام شود.
دستگاههای جفتشده با موفقیت (مانند دستگاههای همراه بلوتوث) محلی در نظر گرفته میشوند. ما بین یک دستگاه جفتشده و دستگاهی که در جریان جفتسازی شرکت میکند، تمایز قائل میشویم.
- باگهایی که توانایی کاربر در شناسایی دستگاه دیگرِ جفتشده (یعنی احراز هویت) را کاهش میدهند، پروگزیمال و بنابراین دور از دسترس در نظر گرفته میشوند.
- اشکالاتی که در طول فرآیند جفتسازی اما قبل از تأیید رضایت کاربر (یعنی مجوز) رخ میدهند، تقریبی و بنابراین دور در نظر گرفته میشوند.
- اشکالاتی که پس از تأیید رضایت کاربر رخ میدهند، حتی اگر جفتسازی در نهایت با شکست مواجه شود، محلی در نظر گرفته میشوند.
بردارهای حمله فیزیکی، محلی در نظر گرفته میشوند. این موارد شامل اشکالاتی هستند که فقط توسط مهاجمی که به دستگاه دسترسی فیزیکی دارد، قابل سوءاستفاده هستند، به عنوان مثال اشکالی در صفحه قفل یا اشکالی که نیاز به اتصال کابل USB دارد. از آنجایی که باز شدن قفل دستگاهها هنگام اتصال به USB امری رایج است، حملاتی که نیاز به اتصال USB دارند، صرف نظر از اینکه دستگاه نیاز به باز شدن قفل داشته باشد یا خیر، شدت یکسانی دارند.
امنیت شبکه
اندروید فرض میکند که همه شبکهها متخاصم هستند و میتوانند حملاتی را تزریق کنند یا از ترافیک جاسوسی کنند. در حالی که امنیت لایه پیوند (به عنوان مثال، رمزگذاری Wi-Fi) ارتباط بین یک دستگاه و نقطه دسترسی که به آن متصل است را ایمن میکند، هیچ کاری برای ایمنسازی پیوندهای باقیمانده در زنجیره بین دستگاه و سرورهایی که با آنها ارتباط برقرار میکند، انجام نمیدهد.
در مقابل، HTTPS معمولاً از کل ارتباط به صورت سرتاسری محافظت میکند، دادهها را در مبدا رمزگذاری میکند و سپس تنها پس از رسیدن به مقصد نهایی، آن را رمزگشایی و تأیید میکند. به همین دلیل، آسیبپذیریهایی که امنیت شبکه لایه پیوند را به خطر میاندازند، نسبت به آسیبپذیریهای HTTPS/TLS شدت کمتری دارند: رمزگذاری Wi-Fi به تنهایی برای اکثر ارتباطات در اینترنت کافی نیست.
احراز هویت بیومتریک
احراز هویت بیومتریک یک حوزه چالشبرانگیز است و حتی بهترین سیستمها را میتوان با یک نمونه تقریباً مشابه فریب داد (به وبلاگ توسعهدهندگان اندروید مراجعه کنید: بهبودهای قفل صفحه و احراز هویت در اندروید ۱۱ ). این رتبهبندیهای شدت، بین دو دسته از حملات تمایز قائل میشوند و برای منعکس کردن خطر واقعی برای کاربر نهایی در نظر گرفته شدهاند.
دسته اول حملات، امکان دور زدن احراز هویت بیومتریک را به روشی قابل تعمیم و بدون نیاز به دادههای بیومتریک با کیفیت بالا از مالک فراهم میکنند. برای مثال، اگر یک مهاجم بتواند یک تکه آدامس را روی حسگر اثر انگشت قرار دهد و بر اساس بقایای باقی مانده روی حسگر، به دستگاه دسترسی پیدا کند، این یک حمله ساده است که میتواند روی هر دستگاه مستعدی انجام شود. نیازی به اطلاع صاحب دستگاه ندارد. با توجه به اینکه قابل تعمیم است و به طور بالقوه تعداد بیشتری از کاربران را تحت تأثیر قرار میدهد، این حمله رتبه شدت کامل (به عنوان مثال، بالا، برای دور زدن قفل صفحه) را دریافت میکند.
دسته دیگر حملات عموماً شامل یک ابزار حمله نمایشی (جعل) بر اساس صاحب دستگاه است. گاهی اوقات به دست آوردن این اطلاعات بیومتریک نسبتاً آسان است (برای مثال، اگر تصویر پروفایل کسی در رسانههای اجتماعی برای فریب دادن احراز هویت بیومتریک کافی باشد، آنگاه یک دور زدن بیومتریک رتبه شدت کامل را دریافت میکند). اما اگر یک مهاجم نیاز داشته باشد که دادههای بیومتریک را مستقیماً از صاحب دستگاه به دست آورد (برای مثال، اسکن مادون قرمز چهره او)، این یک مانع به اندازه کافی قابل توجه است که تعداد افراد تحت تأثیر حمله را محدود میکند، بنابراین یک اصلاحکننده -1 وجود دارد.
SYSTEM_ALERT_WINDOW و tapjacking
برای کسب اطلاعات در مورد سیاستهای ما در رابطه با SYSTEM_ALERT_WINDOW و tapjacking، به بخش « آسیبپذیری Tapjacking/overlay SYSTEM_ALERT_WINDOW در یک صفحه غیر امنیتی-بحرانی » در صفحه «اشکالات بدون تأثیر امنیتی » دانشگاه BugHunter مراجعه کنید.
امنیت چند کاربره در سیستم عامل اندروید اتوموبیل
سیستم عامل اندروید اتوموتیو، مدل امنیتی چندکاربره را اتخاذ میکند که با سایر فرم فاکتورها متفاوت است. هر کاربر اندروید برای استفاده توسط یک شخص فیزیکی متفاوت در نظر گرفته شده است. به عنوان مثال، یک کاربر مهمان موقت میتواند به دوستی که وسیله نقلیه را از صاحب خودرو قرض میگیرد، اختصاص داده شود. برای تطبیق با مواردی مانند این، کاربران به طور پیشفرض به اجزای لازم برای استفاده از وسیله نقلیه، مانند تنظیمات Wi-Fi و شبکه تلفن همراه، دسترسی دارند.
جزء آسیبدیده
تیم توسعهای که مسئول رفع اشکال است، بستگی به این دارد که اشکال در کدام جزء باشد. این جزء میتواند یک جزء اصلی پلتفرم اندروید، یک درایور هسته ارائه شده توسط یک سازنده تجهیزات اصلی (OEM) یا یکی از برنامههای از پیش بارگذاری شده در دستگاههای پیکسل باشد.
اشکالات موجود در کد AOSP توسط تیم مهندسی اندروید در مخازن داخلی ما برطرف میشوند.
این مؤلفه همچنین عاملی در نحوه دریافت بهروزرسانیها توسط کاربران است. یک اشکال در چارچوب یا هسته نیاز به یک بهروزرسانی سیستمعامل OTA دارد که هر تولیدکننده اصلی (OEM) باید آن را منتشر کند. یک اشکال در یک برنامه یا کتابخانه منتشر شده در Google Play (به عنوان مثال، Gmail، Google Play Services یا WebView) میتواند به عنوان یک بهروزرسانی از Google Play برای کاربران اندروید ارسال شود.
به شرکا اطلاع دهید
وقتی یک آسیبپذیری امنیتی در AOSP در یک بولتن امنیتی اندروید برطرف شود، ما شرکای اندروید را از جزئیات مشکل مطلع کرده و وصلههایی را ارائه خواهیم داد. فهرست نسخههای پشتیبانیشده توسط backport با هر نسخه جدید اندروید تغییر میکند. برای فهرست دستگاههای پشتیبانیشده با سازنده دستگاه خود تماس بگیرید.
انتشار کد به AOSP
اگر اشکال امنیتی در یک جزء AOSP باشد، رفع آن پس از انتشار OTA برای کاربران، به AOSP منتقل میشود.
دریافت بهروزرسانیهای اندروید
بهروزرسانیهای سیستم اندروید معمولاً از طریق بستههای بهروزرسانی OTA به دستگاهها ارائه میشوند. این بهروزرسانیها ممکن است از طرف تولیدکننده اصلی دستگاه یا اپراتوری که به دستگاه خدمات ارائه میدهد، ارائه شوند. بهروزرسانیهای دستگاه گوگل پیکسل پس از طی مراحل آزمایش پذیرش فنی اپراتور (TA) توسط تیم گوگل پیکسل ارائه میشوند. گوگل همچنین تصاویر کارخانهای پیکسل را منتشر میکند که میتوانند به صورت جانبی روی دستگاهها بارگذاری شوند.
بهروزرسانی سرویسهای گوگل
تیم امنیتی اندروید علاوه بر ارائه وصلههایی برای رفع اشکالات امنیتی، اشکالات امنیتی را بررسی میکند تا مشخص شود آیا راههای دیگری برای محافظت از کاربران وجود دارد یا خیر. به عنوان مثال، گوگل پلی تمام برنامهها را اسکن میکند و هر برنامهای را که سعی در سوءاستفاده از یک اشکال امنیتی دارد، حذف میکند. برای برنامههای نصب شده از خارج از گوگل پلی، دستگاههای دارای سرویسهای گوگل پلی ممکن است از ویژگی تأیید برنامهها نیز برای هشدار به کاربران در مورد برنامههایی که ممکن است به طور بالقوه مضر باشند، استفاده کنند.
منابع دیگر
اطلاعات برای توسعهدهندگان برنامههای اندروید: https://developer.android.com
اطلاعات امنیتی در سراسر سایتهای منبع باز اندروید و توسعهدهندگان وجود دارد. مکانهای خوبی برای شروع:
گزارشها
گاهی اوقات تیم امنیت اندروید گزارشها یا گزارشهای رسمی منتشر میکند. برای جزئیات بیشتر به گزارشهای امنیتی مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2026-04-16 بهوقت ساعت هماهنگ جهانی.