Tim keamanan Android bertanggung jawab untuk mengelola kerentanan keamanan yang ditemukan di platform Android dan banyak aplikasi inti Android yang digabungkan dengan perangkat Android.
Tim keamanan Android menemukan kerentanan keamanan melalui penelitian internal dan juga merespons bug yang dilaporkan oleh pihak ketiga. Sumber bug eksternal mencakup masalah yang dilaporkan melalui formulir kerentanan , penelitian akademis yang dipublikasikan dan dipublikasikan 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
Pengembang, pengguna Android, atau peneliti keamanan mana pun dapat memberi tahu tim keamanan Android tentang potensi masalah keamanan melalui formulir kerentanan .
Bug yang ditandai sebagai masalah keamanan tidak terlihat secara eksternal, namun pada akhirnya dapat terlihat setelah masalah dievaluasi atau diselesaikan. Jika Anda berencana mengirimkan patch atau pengujian Compatibility Test Suite (CTS) untuk menyelesaikan masalah keamanan, harap lampirkan ke laporan bug dan tunggu respons sebelum mengunggah kode ke AOSP.
Memprioritaskan 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 kepada pengguna.
Jenis konteks
Tabel ini mencakup definisi konteks keamanan perangkat keras dan perangkat lunak. Konteksnya dapat ditentukan oleh sensitivitas data yang biasanya diproses atau area di mana data tersebut dijalankan. Tidak semua konteks keamanan dapat diterapkan pada semua sistem. Tabel ini diurutkan dari yang paling istimewa hingga yang paling istimewa.
Tipe konteks | Definisi tipe |
---|---|
Konteks terbatas | Lingkungan eksekusi terbatas yang hanya memberikan izin paling minimal. Misalnya, aplikasi tepercaya memproses data tidak tepercaya dalam lingkungan sandbox. |
Konteks yang tidak memiliki hak istimewa | 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 dengan hak istimewa yang mungkin memiliki akses ke izin yang lebih tinggi, menangani banyak PII pengguna, dan/atau menjaga integritas sistem. Misalnya, aplikasi Android dengan kemampuan yang dilarang oleh domain SELinux untrusted_app atau dengan akses ke privileged|signature . |
inti sistem operasi | Fungsionalitas 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 tidak bersahabat (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, sebagaimana didefinisikan dalam Pengantar Elemen Aman . Ini termasuk chip Titan-M yang ada di beberapa perangkat Android. |
Kerasnya
Tingkat keparahan bug umumnya mencerminkan potensi kerugian yang dapat terjadi jika bug berhasil dieksploitasi. Gunakan kriteria berikut untuk menentukan tingkat keparahannya.
Peringkat | Konsekuensi dari eksploitasi yang berhasil |
---|---|
Kritis |
|
Tinggi |
|
Sedang |
|
Rendah |
|
Dampak Keamanan yang Dapat Diabaikan (NSI) |
|
Pengubah peringkat
Meskipun tingkat keparahan kerentanan keamanan sering kali mudah diidentifikasi, peringkat dapat berubah berdasarkan keadaan.
Alasan | Memengaruhi |
---|---|
Memerlukan berjalan sebagai konteks istimewa untuk mengeksekusi serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM) | -1 Tingkat Keparahan |
Detail spesifik kerentanan membatasi dampak masalah ini | -1 Tingkat Keparahan |
Bypass otentikasi biometrik yang memerlukan informasi biometrik langsung dari pemilik perangkat | -1 Tingkat Keparahan |
Konfigurasi kompiler atau platform mengurangi kerentanan dalam kode sumber | Tingkat Keparahan Sedang jika kerentanan yang mendasarinya adalah Sedang atau lebih tinggi |
Memerlukan akses fisik ke internal perangkat dan masih dapat dilakukan jika perangkat mati atau belum dibuka kuncinya sejak dihidupkan | -1 Tingkat Keparahan |
Memerlukan akses fisik ke internal perangkat saat perangkat aktif dan sebelumnya telah dibuka kuncinya | -2 Tingkat Keparahan |
Serangan lokal yang mengharuskan rantai bootloader dibuka kuncinya | Tidak lebih tinggi dari Rendah |
Serangan lokal yang memerlukan Mode Pengembang atau pengaturan mode pengembang persisten 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 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 oleh browsing ke halaman web, membaca email, menerima pesan SMS, atau menghubungkan ke jaringan yang tidak bersahabat. Untuk tujuan penilaian tingkat keparahan, kami juga menganggap vektor serangan "proksimal" sebagai vektor serangan 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 formatnya salah. Kami menganggap serangan berbasis Ultra-wideband (UWB) dan NFC sebagai serangan proksimal dan oleh karena itu jarak jauh.
Serangan lokal mengharuskan korban untuk menjalankan aplikasi, baik dengan menginstal dan menjalankan aplikasi atau dengan menyetujui untuk menjalankan Aplikasi Instan . Perangkat pendamping yang dipasangkan akan dianggap sebagai perangkat lokal. Untuk tujuan penilaian tingkat keparahan, tim keamanan Android juga menganggap vektor serangan fisik bersifat 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 kabel USB untuk dicolokkan.
Keamanan jaringan
Android berasumsi bahwa semua jaringan bersifat bermusuhan dan dapat melakukan serangan atau memata-matai lalu lintas. Meskipun keamanan lapisan tautan (misalnya, enkripsi Wi-Fi) mengamankan komunikasi antara perangkat dan Titik Akses yang terhubung dengannya, keamanan ini 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 data 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
Otentikasi biometrik adalah bidang yang menantang, dan bahkan sistem terbaik pun bisa tertipu oleh kecocokan yang hampir sama (lihat Blog Pengembang Android: Layar kunci dan penyempurnaan autentikasi di Android 11 ). Peringkat tingkat keparahan ini membedakan dua kelas serangan dan dimaksudkan untuk mencerminkan risiko sebenarnya bagi pengguna akhir.
Serangan kelas satu memungkinkan melewati otentikasi biometrik dengan cara yang dapat digeneralisasikan, tanpa data biometrik berkualitas tinggi dari pemiliknya. Jika, misalnya, penyerang dapat menempelkan permen karet pada sensor sidik jari, dan hal tersebut memberikan akses ke perangkat berdasarkan residu yang tertinggal pada sensor, maka ini adalah serangan sederhana yang dapat dilakukan pada perangkat mana pun yang rentan. Itu tidak memerlukan pengetahuan apa pun dari pemilik perangkat. Mengingat serangan ini dapat digeneralisasikan dan berpotensi berdampak pada lebih banyak pengguna, serangan ini menerima peringkat tingkat keparahan penuh (misalnya, Tinggi, untuk bypass Lockscreen).
Kelas serangan lainnya umumnya melibatkan instrumen serangan presentasi (spoof) berdasarkan pemilik perangkat. Terkadang informasi biometrik ini relatif mudah diperoleh (misalnya, jika gambar profil seseorang di media sosial cukup untuk mengelabui autentikasi biometrik, maka bypass biometrik akan menerima peringkat tingkat keparahan penuh). Namun jika penyerang perlu memperoleh data biometrik langsung dari pemilik perangkat (misalnya, pemindaian inframerah pada wajahnya), hal tersebut merupakan penghalang yang cukup signifikan sehingga membatasi jumlah orang yang terkena dampak serangan tersebut, jadi terdapat pengubah -1 .
SYSTEM_ALERT_WINDOW
dan Tapjacking
Untuk informasi tentang kebijakan kami mengenai SYSTEM_ALERT_WINDOW
dan tapjacking, lihat bagian " Kerentanan Tapjacking/overlay SYSTEM_ALERT_WINDOW pada layar yang tidak kritis terhadap keamanan " di halaman Bugs tanpa dampak keamanan di Universitas BugHunter.
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 mengakomodasi kasus penggunaan seperti ini, pengguna secara default memiliki akses ke komponen penting yang diperlukan untuk menggunakan kendaraan, seperti pengaturan jaringan Wi-Fi dan seluler.
Komponen yang terkena dampak
Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen mana yang berisi bug tersebut. Ini bisa berupa komponen inti platform Android, driver kernel yang disediakan oleh produsen peralatan asli (OEM), atau salah satu aplikasi yang dimuat sebelumnya di perangkat Pixel .
Bug dalam kode AOSP diperbaiki oleh tim teknik Android. Bug dengan tingkat keparahan rendah, bug pada komponen tertentu, atau bug yang sudah diketahui publik dapat diperbaiki langsung di cabang utama AOSP yang tersedia untuk umum; jika tidak, mereka akan 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 perlu dilakukan oleh setiap OEM. Bug pada aplikasi atau pustaka yang dipublikasikan di Google Play (misalnya, Gmail, Layanan Google Play, atau WebView) dapat dikirimkan ke pengguna Android sebagai pembaruan dari Google Play.
Memberi tahu mitra
Ketika kerentanan keamanan di AOSP diperbaiki di Buletin Keamanan Android, kami akan memberi tahu mitra Android mengenai detail masalahnya dan memberikan patch. Daftar versi yang didukung backport berubah 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 diterapkan ke AOSP setelah OTA dirilis ke pengguna. Perbaikan untuk masalah dengan tingkat keparahan rendah dapat dikirimkan langsung ke cabang utama AOSP sebelum perbaikan tersedia untuk perangkat melalui OTA.
Menerima pembaruan Android
Pembaruan pada sistem Android umumnya dikirimkan ke perangkat melalui paket pembaruan OTA. Pembaruan ini mungkin berasal dari OEM yang memproduksi perangkat atau operator yang memberikan layanan pada perangkat tersebut. Pembaruan perangkat Google Pixel berasal dari tim Google Pixel setelah melalui prosedur pengujian penerimaan teknis operator (TA). Google juga menerbitkan gambar pabrik Pixel yang dapat dimuat ke perangkat.
Memperbarui layanan Google
Selain memberikan patch 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 mungkin berpotensi membahayakan.
Sumber daya lainnya
Informasi untuk pengembang aplikasi Android: https://developer.android.com
Informasi keamanan ada di seluruh situs Sumber Terbuka dan Pengembang Android. 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 whitepaper. Lihat Laporan Keamanan untuk detail selengkapnya.