Tim keamanan Android bertanggung jawab untuk mengelola kerentanan keamanan yang ditemukan di platform Android dan banyak aplikasi inti Android yang dipaketkan dengan perangkat Android.
Tim keamanan Android menemukan kerentanan keamanan melalui riset internal dan juga menanggapi bug yang dilaporkan oleh pihak ketiga. Sumber bug eksternal mencakup masalah yang dilaporkan melalui formulir kerentanan , penelitian akademis yang diterbitkan dan diterbitkan sebelumnya, pengelola proyek sumber terbuka hulu, pemberitahuan dari mitra produsen perangkat kami, dan masalah yang diungkapkan secara publik yang diposting di blog atau media sosial.
Melaporkan masalah keamanan
Semua pengembang, pengguna Android, atau peneliti keamanan dapat memberi tahu tim keamanan Android tentang potensi masalah keamanan melalui formulir kerentanan .
Bug yang ditandai sebagai masalah keamanan tidak terlihat secara eksternal, tetapi pada akhirnya dapat terlihat setelah masalah dievaluasi atau diselesaikan. Jika Anda berencana untuk mengirimkan patch atau pengujian Compatibility Test Suite (CTS) untuk mengatasi masalah keamanan, lampirkan patch tersebut ke laporan bug dan tunggu tanggapan sebelum mengunggah kode ke AOSP.
Triase bug
Tugas pertama dalam menangani kerentanan keamanan adalah mengidentifikasi tingkat keparahan bug dan komponen Android mana yang terpengaruh. Tingkat keparahan menentukan bagaimana masalah diprioritaskan, dan komponen menentukan siapa yang memperbaiki bug, siapa yang diberi tahu, dan bagaimana perbaikan diterapkan ke pengguna.
Jenis konteks
Tabel ini mencakup definisi konteks keamanan perangkat keras dan perangkat lunak. Konteks dapat ditentukan oleh sensitivitas data yang biasanya diproses atau area tempat data dijalankan. Tidak semua konteks keamanan berlaku untuk semua sistem. Tabel ini diurutkan dari yang paling rendah hingga yang paling diistimewakan.
Jenis konteks | Definisi jenis |
---|---|
Konteks yang dibatasi | Lingkungan eksekusi terbatas yang hanya menyediakan izin paling minimal. Misalnya, aplikasi tepercaya yang memproses data tidak tepercaya dalam lingkungan kotak pasir. |
Konteks yang tidak terjangkau | Lingkungan eksekusi tipikal yang diharapkan oleh kode yang tidak memiliki hak istimewa. Misalnya, aplikasi Android yang berjalan di domain SELinux dengan atribut untrusted_app_all . |
Konteks istimewa | Lingkungan eksekusi istimewa yang mungkin memiliki akses ke izin yang lebih tinggi, menangani beberapa PII pengguna, dan/atau menjaga integritas sistem. Misalnya, aplikasi Android dengan kemampuan yang akan dilarang oleh domain SELinux untrusted_app atau dengan akses ke privileged|signature permissions. |
Kernel OS | Fungsi yang:
|
Basis Perangkat Keras Tepercaya (THB) | Komponen perangkat keras terpisah, umumnya pada SoC, yang menyediakan fungsionalitas penting untuk kasus penggunaan inti perangkat (seperti, pita dasar seluler, DSP, GPU, dan prosesor ML). |
Rantai bootloader | Komponen yang mengonfigurasi perangkat saat boot dan kemudian meneruskan kontrol ke OS Android. |
Lingkungan Eksekusi Tepercaya (TEE) | Komponen yang dirancang untuk dilindungi bahkan dari Kernel OS yang bermusuhan (misalnya, TrustZone dan hypervisor, seperti pKVM, yang melindungi Mesin Virtual dari Kernel OS). |
Enklave Aman / Elemen Aman (SE) | Komponen perangkat keras opsional yang dirancang untuk dilindungi dari semua komponen lain pada perangkat dan dari serangan fisik, seperti yang didefinisikan dalam Pengantar Elemen Aman . Ini termasuk chip Titan-M yang ada di beberapa perangkat Android. |
Kerasnya
Tingkat keparahan bug umumnya mencerminkan potensi kerusakan yang dapat terjadi jika bug berhasil dieksploitasi. Gunakan kriteria berikut untuk menentukan tingkat keparahan.
Peringkat | Konsekuensi eksploitasi yang berhasil |
---|---|
Kritis |
|
Tinggi |
|
Sedang |
|
Rendah |
|
Dampak Keamanan yang Dapat Diabaikan (NSI) |
|
Pengubah peringkat
Sementara tingkat keparahan kerentanan keamanan seringkali mudah diidentifikasi, peringkat dapat berubah berdasarkan keadaan.
Alasan | Memengaruhi |
---|---|
Membutuhkan menjalankan sebagai konteks istimewa untuk mengeksekusi serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM) | -1 Keparahan |
Detail khusus kerentanan membatasi dampak masalah | -1 Keparahan |
Bypass otentikasi biometrik yang memerlukan informasi biometrik langsung dari pemilik perangkat | -1 Keparahan |
Konfigurasi kompiler atau platform mengurangi kerentanan dalam kode sumber | Tingkat Keparahan Sedang jika kerentanan yang mendasarinya Sedang atau lebih tinggi |
Membutuhkan akses fisik ke internal perangkat dan masih memungkinkan jika perangkat mati atau belum dibuka kuncinya sejak dihidupkan | -1 Keparahan |
Membutuhkan akses fisik ke internal perangkat saat perangkat aktif dan sebelumnya telah dibuka kuncinya | -2 Keparahan |
Serangan lokal yang mengharuskan rantai bootloader dibuka kuncinya | Tidak lebih tinggi dari Rendah |
Serangan lokal yang membutuhkan Mode Pengembang atau pengaturan mode pengembang tetap apa pun untuk saat ini diaktifkan pada perangkat (dan bukan merupakan bug dalam Mode Pengembang itu sendiri). | Tidak lebih tinggi dari Rendah |
Jika tidak ada domain SELinux yang dapat melakukan operasi berdasarkan SEPolicy yang disediakan Google | Dampak Keamanan yang Dapat Diabaikan |
Lokal versus Proksimal versus Jarak Jauh
Vektor serangan jarak jauh menunjukkan bahwa bug dapat dieksploitasi tanpa menginstal aplikasi atau tanpa akses fisik ke perangkat. Ini termasuk bug yang dapat dipicu dengan menjelajah ke halaman web, membaca email, menerima pesan SMS, atau menghubungkan ke jaringan yang tidak bersahabat. Untuk tujuan peringkat keparahan kami, kami juga menganggap vektor serangan "proksimal" sebagai jarak jauh. Ini termasuk bug yang hanya dapat dieksploitasi oleh penyerang yang secara fisik berada di dekat perangkat target, misalnya, bug yang memerlukan pengiriman paket Wi-Fi atau Bluetooth yang cacat. Kami menganggap serangan berbasis Ultra-wideband (UWB) dan NFC sebagai proksimal dan karenanya jarak jauh.
Serangan lokal mengharuskan korban untuk menjalankan aplikasi, baik dengan memasang dan menjalankan aplikasi atau dengan menyetujui untuk menjalankan Aplikasi Instan . Perangkat pendamping yang dipasangkan akan dianggap sebagai perangkat lokal. Untuk tujuan pemeringkatan tingkat keparahan, tim keamanan Android juga mempertimbangkan vektor serangan fisik sebagai lokal. Ini termasuk bug yang hanya dapat dieksploitasi oleh penyerang yang memiliki akses fisik ke perangkat, misalnya bug di layar kunci atau bug yang memerlukan mencolokkan kabel USB.
Keamanan jaringan
Android berasumsi bahwa semua jaringan tidak bersahabat dan dapat menyuntikkan serangan atau memata-matai lalu lintas. Meskipun keamanan lapisan tautan (misalnya, enkripsi Wi-Fi) mengamankan komunikasi antara perangkat dan Titik Akses yang terhubung dengannya, ia tidak melakukan apa pun untuk mengamankan tautan yang tersisa dalam rantai antara perangkat dan server yang berkomunikasi dengannya.
Sebaliknya, HTTPS biasanya melindungi seluruh komunikasi ujung ke ujung, mengenkripsi data pada sumbernya, lalu mendekripsi dan memverifikasinya hanya setelah mencapai tujuan akhirnya. Oleh karena itu, kerentanan yang membahayakan keamanan jaringan lapisan tautan dinilai tidak separah kerentanan di HTTPS/TLS: Enkripsi Wi-Fi saja tidak cukup untuk sebagian besar komunikasi di internet.
Otentikasi biometrik
Autentikasi biometrik adalah ruang yang menantang, dan bahkan sistem terbaik pun dapat dikelabui oleh kecocokan yang hampir sama (lihat Blog Pengembang Android: Perbaikan layar kunci dan autentikasi di Android 11 ). Peringkat keparahan ini membedakan antara dua kelas serangan dan dimaksudkan untuk mencerminkan risiko aktual bagi pengguna akhir.
Kelas serangan pertama memungkinkan melewati otentikasi biometrik dengan cara yang dapat digeneralisasikan, tanpa data biometrik berkualitas tinggi dari pemiliknya. Jika, misalnya, seorang penyerang dapat menempatkan permen karet pada sensor sidik jari, dan memberikan akses ke perangkat berdasarkan residu yang tertinggal di sensor, itu adalah serangan sederhana yang dapat dilakukan pada perangkat yang rentan. Itu tidak memerlukan pengetahuan apa pun dari pemilik perangkat. Karena dapat digeneralisasikan dan berpotensi memengaruhi lebih banyak pengguna, serangan ini menerima peringkat keparahan penuh (misalnya, Tinggi, untuk pintasan Layar Kunci).
Kelas serangan lain umumnya melibatkan instrumen serangan presentasi (spoof) berdasarkan pemilik perangkat. Terkadang informasi biometrik ini relatif mudah didapat (misalnya, jika foto profil seseorang di media sosial cukup untuk mengelabui autentikasi biometrik, maka bypass biometrik akan menerima peringkat keparahan penuh). Namun jika penyerang perlu memperoleh data biometrik langsung dari pemilik perangkat (misalnya, pemindaian inframerah wajah mereka), itu adalah penghalang yang cukup signifikan sehingga membatasi jumlah orang yang terkena serangan, jadi ada pengubah -1 .
SYSTEM_ALERT_WINDOW
dan Tapjacking
Untuk informasi tentang kebijakan kami tentang SYSTEM_ALERT_WINDOW
dan tapjacking, lihat bagian " Tapjacking/overlay SYSTEM_ALERT_WINDOW kerentanan pada layar non-keamanan-kritis " BugHunter University's Bugs with no security impact page.
Keamanan multi-pengguna di Android Automotive OS
Android Automotive OS mengadopsi model keamanan multi-pengguna yang berbeda dari faktor bentuk lainnya. Setiap pengguna Android dimaksudkan untuk digunakan oleh orang fisik yang berbeda. Misalnya, pengguna tamu sementara dapat ditugaskan ke teman yang meminjam kendaraan dari pemilik mobil. Untuk mengakomodir kasus penggunaan seperti ini, pengguna secara default memiliki akses ke komponen yang diperlukan untuk menggunakan kendaraan, seperti Wi-Fi dan pengaturan jaringan seluler.
Komponen yang terpengaruh
Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen mana bug tersebut berada. Ini bisa berupa komponen inti dari platform Android, driver kernel yang disediakan oleh Original Equipment Manufacturer (OEM), atau salah satu aplikasi bawaan pada perangkat Pixel .
Bug dalam kode AOSP diperbaiki oleh tim teknisi Android. Bug dengan tingkat keparahan rendah, bug pada komponen tertentu, atau bug yang sudah diketahui publik dapat diperbaiki langsung di cabang master AOSP yang tersedia untuk umum; jika tidak, mereka diperbaiki di repositori internal kami terlebih dahulu.
Komponen juga menjadi faktor bagaimana pengguna mendapatkan pembaruan. Bug dalam kerangka kerja atau kernel memerlukan pembaruan firmware over-the-air (OTA) yang harus didorong oleh setiap OEM. Bug di aplikasi atau pustaka yang dipublikasikan di Google Play (misalnya, Gmail, Layanan Google Play, atau WebView) dapat dikirim ke pengguna Android sebagai pembaruan dari Google Play.
Memberitahu mitra
Saat kerentanan keamanan di AOSP diperbaiki di Buletin Keamanan Android, kami akan memberi tahu partner Android tentang detail masalah dan memberikan tambalan. Daftar versi yang didukung backport berubah dengan setiap rilis Android baru. Hubungi produsen perangkat Anda untuk mengetahui daftar perangkat yang didukung.
Merilis kode ke AOSP
Jika bug keamanan ada di komponen AOSP, perbaikan akan didorong ke AOSP setelah OTA dirilis ke pengguna. Perbaikan untuk masalah tingkat keparahan rendah dapat dikirimkan langsung ke cabang master AOSP sebelum perbaikan tersedia untuk perangkat melalui OTA.
Menerima pembaruan Android
Pembaruan sistem Android umumnya dikirimkan ke perangkat melalui paket pembaruan OTA. Pembaruan ini mungkin berasal dari OEM yang memproduksi perangkat atau operator yang menyediakan layanan ke perangkat tersebut. Pembaruan perangkat Google Pixel berasal dari tim Google Pixel setelah melalui prosedur pengujian penerimaan teknis (TA) operator. Google juga menerbitkan gambar pabrik Pixel yang dapat dimuat ke perangkat.
Memperbarui layanan Google
Selain menyediakan tambalan untuk bug keamanan, tim keamanan Android meninjau bug keamanan untuk menentukan apakah ada cara lain untuk melindungi pengguna. Misalnya, Google Play memindai semua aplikasi dan menghapus aplikasi apa pun yang mencoba mengeksploitasi bug keamanan. Untuk aplikasi yang diinstal dari luar Google Play, perangkat dengan Layanan Google Play juga dapat menggunakan fitur Verifikasi Aplikasi untuk memperingatkan pengguna tentang aplikasi yang berpotensi membahayakan.
Sumber daya lainnya
Informasi untuk pengembang aplikasi Android: https://developer.android.com
Informasi keamanan tersedia di seluruh situs Android Open Source dan Developer. Tempat yang bagus untuk memulai:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Laporan
Terkadang tim Keamanan Android menerbitkan laporan atau laporan resmi. Lihat Laporan Keamanan untuk detail lebih lanjut.