Update dan referensi keamanan

Tim keamanan Android bertanggung jawab untuk mengelola kerentanan keamanan yang ditemukan di platform Android dan banyak aplikasi inti Android yang disertakan dengan perangkat Android.

Tim keamanan Android menemukan kerentanan keamanan melalui riset internal dan juga merespons bug yang dilaporkan oleh pihak ketiga. Sumber bug eksternal mencakup masalah yang dilaporkan melalui formulir kerentanan, riset akademis yang dipublikasikan dan belum dipublikasikan, pengelola project open source upstream, notifikasi dari partner produsen perangkat kami, dan masalah yang diungkapkan secara publik yang diposting di blog atau media sosial.

Melaporkan masalah keamanan

Setiap developer, 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 mengirimkan patch atau pengujian Compatibility Test Suite (CTS) untuk menyelesaikan masalah keamanan, lampirkan ke laporan bug dan tunggu respons sebelum mengupload kode ke AOSP.

Menyeleksi bug

Tugas pertama dalam menangani kerentanan keamanan adalah mengidentifikasi tingkat keparahan bug dan komponen Android mana yang terpengaruh. Tingkat keparahan menentukan prioritas masalah, dan komponen menentukan siapa yang memperbaiki bug, siapa yang diberi tahu, dan bagaimana perbaikan di-deploy kepada pengguna.

Jenis konteks

Tabel ini mencakup definisi konteks keamanan hardware dan software. Konteks dapat ditentukan oleh sensitivitas data yang biasanya diproses atau area tempat data tersebut berjalan. Tidak semua konteks keamanan berlaku untuk semua sistem. Tabel ini diurutkan dari hak istimewa terendah hingga tertinggi.

Jenis konteks Definisi jenis
Konteks terbatas Lingkungan eksekusi terbatas yang hanya memberikan izin paling minimal.

Misalnya, aplikasi tepercaya memproses data yang tidak tepercaya dalam lingkungan sandbox.
Konteks yang tidak memiliki hak istimewa Lingkungan eksekusi umum yang diharapkan oleh kode tanpa 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 ditingkatkan, menangani beberapa PII pengguna, dan/atau menjaga integritas sistem.

Misalnya, aplikasi Android dengan kemampuan yang akan dilarang oleh domain untrusted_app SELinux atau dengan akses ke izin privileged|signature.
Kernel OS Fungsi yang:
  • adalah bagian dari kernel
  • berjalan dalam konteks CPU yang sama dengan kernel (misalnya, driver perangkat)
  • memiliki akses langsung ke memori kernel (misalnya, komponen hardware di perangkat)
  • memiliki kemampuan untuk memuat skrip ke dalam komponen kernel (misalnya, eBPF)
  • adalah salah satu dari beberapa layanan pengguna yang dianggap setara dengan kernel (seperti, apexd, bpfloader, init, ueventd, dan vold).
Dasar Hardware Tepercaya (THB) Komponen hardware diskrit, umumnya pada SoC, yang menyediakan fungsi penting untuk kasus penggunaan inti perangkat (seperti, baseband seluler, DSP, GPU, dan prosesor ML).
Rantai Bootloader Komponen yang mengonfigurasi perangkat saat booting, lalu meneruskan kontrol ke OS Android.
Trusted Execution Environment (TEE) Komponen yang didesain untuk dilindungi dari kernel OS yang berbahaya (misalnya, TrustZone dan hypervisor, seperti pKVM, yang melindungi Virtual Machine dari kernel OS).
Secure Enclave / Elemen Pengaman (SE) Komponen hardware opsional yang didesain untuk dilindungi dari semua komponen lain di perangkat dan dari serangan fisik, sebagaimana ditentukan dalam Pengantar Secure Element.

Hal ini mencakup chip Titan-M yang ada di beberapa perangkat Android.

Tingkat Keparahan

Tingkat keparahan bug umumnya mencerminkan potensi bahaya yang dapat terjadi jika bug berhasil dieksploitasi. Gunakan kriteria berikut untuk menentukan tingkat keparahan.

Rating Konsekuensi eksploitasi yang berhasil
Kritis
  • Eksekusi kode arbitrer di TEE atau SE
  • Mengakali mekanisme software yang dirancang untuk mencegah komponen software atau hardware terkait keselamatan berfungsi tidak semestinya (misalnya, perlindungan termal)
  • Akses jarak jauh ke kredensial sensitif yang digunakan untuk autentikasi layanan jarak jauh (misalnya, sandi akun atau token pembawa)
  • Eksekusi kode arbitrer jarak jauh dalam konteks baseband seluler tanpa interaksi pengguna (misalnya, mengeksploitasi bug dalam layanan radio seluler)
  • Eksekusi kode arbitrer jarak jauh dalam konteks istimewa, rantai bootloader, THB, atau kernel OS
  • Melewati persyaratan interaksi pengguna dari jarak jauh pada penginstalan paket atau perilaku yang setara
  • Melewati persyaratan interaksi pengguna dari jarak jauh untuk setelan privasi, keamanan, atau developer inti
  • Penolakan layanan persisten jarak jauh (permanen, memerlukan penginstalan ulang seluruh sistem operasi, atau reset ke setelan pabrik)
  • Pengabaian booting aman jarak jauh
  • Akses tidak sah ke data yang diamankan oleh SE, termasuk akses yang diaktifkan oleh kunci lemah di SE.
Tinggi
  • Penghindaran lengkap fitur keamanan inti (misalnya, SELinux, FBE, atau seccomp)
  • Pelewatan umum untuk teknologi defense in depth atau mitigasi eksploitasi dalam rantai bootloader, TEE, atau SE
  • Pengabaian umum untuk perlindungan sistem operasi yang mengungkapkan konten memori atau file di seluruh batas aplikasi, pengguna, atau profil
  • Serangan terhadap SE yang mengakibatkan downgrade ke penerapan yang kurang aman
  • Melakukan pivot dari firmware bare metal yang terkompromi dan dapat dijangkau dari jarak jauh (misalnya, baseband, Communications Processor (CP)) ke kernel Application Processor (AP) atau mekanisme bypass yang dirancang untuk mengisolasi firmware bare metal dari kernel AP
  • Melewati perlindungan perangkat, perlindungan reset ke setelan pabrik (di Android 15 dan yang lebih baru), atau batasan operator
  • Melewati persyaratan interaksi pengguna yang diamankan oleh TEE
  • Kerentanan kriptografi yang memungkinkan serangan terhadap protokol end-to-end, termasuk serangan terhadap keamanan lapisan transport (TLS) dan Bluetooth (BT).
  • Akses lokal ke kredensial sensitif yang digunakan untuk autentikasi layanan jarak jauh (misalnya, sandi akun atau token pembawa)
  • Eksekusi kode arbitrer lokal dalam konteks yang memiliki hak istimewa, rantai bootloader, THB, atau kernel OS
  • Melewati booting aman lokal
  • Melewati layar kunci
  • Pengabaian lokal persyaratan interaksi pengguna untuk setelan developer, keamanan, atau privasi inti
  • Pelewatan lokal persyaratan interaksi pengguna pada penginstalan paket atau perilaku yang setara
  • Penolakan layanan persisten lokal (permanen, memerlukan penginstalan ulang seluruh sistem operasi, atau reset ke setelan pabrik)
  • Akses jarak jauh ke data yang dilindungi (yaitu, data yang terbatas pada konteks yang memiliki hak istimewa)
  • Eksekusi kode arbitrer jarak jauh dalam konteks yang bukan hak istimewa
  • Penolakan layanan jarak jauh untuk layanan seluler atau Wi-Fi yang berlanjut hingga intervensi pengguna, dipicu tanpa interaksi pengguna (misalnya, error pada layanan radio seluler dengan paket yang salah bentuk yang tidak dipulihkan secara otomatis dan memerlukan mulai ulang manual atau reboot perangkat).
  • Pelewatan jarak jauh persyaratan interaksi pengguna (akses ke fungsi atau data yang seharusnya memerlukan inisiasi pengguna atau izin pengguna)
  • Pencegahan akses ke layanan darurat yang ditargetkan
  • Mentransmisikan informasi sensitif melalui protokol jaringan yang tidak aman (misalnya, HTTP dan Bluetooth yang tidak terenkripsi) saat pemohon mengharapkan transmisi yang aman. Perhatikan bahwa hal ini tidak berlaku untuk enkripsi Wi-Fi (seperti WEP)
  • Akses tidak sah ke data yang diamankan oleh TEE, termasuk akses yang diaktifkan oleh kunci lemah di TEE
Sedang
  • Pengabaian umum untuk teknologi pertahanan mendalam atau mitigasi eksploitasi dalam konteks istimewa, THB, atau kernel OS
  • Pengabaian umum untuk perlindungan sistem operasi yang mengungkapkan status atau metadata proses di seluruh batas aplikasi, pengguna, atau profil
  • Melewati enkripsi atau autentikasi Wi-Fi
  • Kerentanan kriptografi dalam primitif kripto standar yang memungkinkan kebocoran plaintext (bukan primitif yang digunakan dalam TLS)
  • Akses lokal ke data yang dilindungi (yaitu, data yang terbatas pada konteks yang memiliki hak istimewa)
  • Eksekusi kode arbitrer lokal dalam konteks yang tidak memiliki hak istimewa
  • Pelewatan lokal persyaratan interaksi pengguna (akses ke fungsi atau data yang biasanya memerlukan inisiasi pengguna atau izin pengguna)
  • Akses jarak jauh ke data yang tidak dilindungi (yaitu, data yang biasanya dapat diakses oleh aplikasi yang diinstal secara lokal)
  • Eksekusi kode arbitrer jarak jauh dalam konteks terbatas
  • Penolakan layanan perangkat sementara dari jarak jauh (hang atau reboot dari jarak jauh)
Rendah
  • Pengabaian umum untuk teknologi mitigasi eksploitasi atau pertahanan mendalam tingkat pengguna dalam konteks yang tidak memiliki hak istimewa
  • Pengabaian izin tingkat perlindungan normal
  • Kerentanan kriptografi dalam penggunaan yang tidak standar
  • Pelewatan umum fitur personalisasi di perangkat seperti Voice Match atau Face Match
  • Dokumentasi yang salah yang dapat menyebabkan kerentanan keamanan
  • Eksekusi kode arbitrer lokal dalam konteks terbatas
  • Teks yang ditentukan sistem yang menyertakan deskripsi menyesatkan yang menciptakan ekspektasi keamanan palsu
Dampak Keamanan yang Dapat Diabaikan (NSI)
  • Kerentanan yang dampaknya telah dimitigasi oleh satu atau beberapa pengubah rating atau perubahan arsitektur khusus versi sehingga tingkat keparahannya yang efektif berada di bawah Rendah, meskipun masalah kode yang mendasarinya mungkin tetap ada
  • Kerentanan apa pun yang memerlukan sistem file yang salah bentuk, jika sistem file tersebut selalu diadopsi/dienkripsi sebelum digunakan.
  • Penolakan layanan sementara lokal, seperti jika kondisi dapat diselesaikan dengan memulai ulang perangkat atau meng-uninstal aplikasi yang memicu.

Pengubah tingkat keparahan

Meskipun tingkat keparahan kerentanan keamanan sering kali mudah diidentifikasi, rating dapat berubah berdasarkan keadaan.

Alasan Efek
Memerlukan eksekusi sebagai konteks dengan hak istimewa untuk menjalankan serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM) Tingkat Keparahan -1
Detail khusus kerentanan membatasi dampak masalah Tingkat Keparahan -1
Pengabaian autentikasi biometrik yang memerlukan informasi biometrik langsung dari pemilik perangkat Tingkat Keparahan -1
Konfigurasi compiler atau platform memitigasi kerentanan dalam kode sumber Tingkat Keseriusan Sedang jika kerentanan yang mendasarinya adalah Sedang atau lebih tinggi
Memerlukan akses fisik ke komponen internal perangkat dan masih dapat dilakukan jika perangkat nonaktif atau belum dibuka kuncinya sejak diaktifkan Tingkat Keparahan -1
Memerlukan akses fisik ke komponen internal perangkat saat perangkat aktif dan telah dibuka kuncinya sebelumnya -2 Tingkat Keparahan
Serangan lokal yang memerlukan pembukaan kunci rantai bootloader Tidak lebih tinggi dari Rendah
Serangan lokal yang memerlukan Mode Developer atau setelan mode developer persisten apa pun agar saat ini diaktifkan di perangkat (dan bukan bug di Mode Developer 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 jauh

Vektor serangan jarak jauh menunjukkan bahwa bug dapat dieksploitasi tanpa menginstal aplikasi atau tanpa akses fisik ke perangkat. Hal ini mencakup bug yang dapat dipicu dengan menjelajahi halaman web, membaca email, menerima pesan SMS, atau terhubung ke jaringan yang tidak aman.

Vektor serangan proksimal dianggap jarak jauh. Hal ini mencakup 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 salah format. Kami menganggap serangan berbasis NFC dan Ultra-wideband (UWB) sebagai serangan proksimal dan oleh karena itu, serangan jarak jauh.

Serangan lokal mengharuskan penyerang memiliki akses sebelumnya ke korban. Dalam contoh hipotetis khusus software, hal ini dapat terjadi melalui aplikasi berbahaya yang telah diinstal korban, atau Aplikasi Instan yang telah disetujui untuk dijalankan.

Perangkat yang berhasil disambungkan (seperti perangkat pendamping Bluetooth) dianggap sebagai perangkat lokal. Kami membedakan antara perangkat yang disambungkan dan perangkat yang berpartisipasi dalam alur penyambungan.

  • Bug yang menurunkan kemampuan pengguna untuk mengidentifikasi perangkat lain yang disambungkan (yaitu autentikasi) dianggap proksimal dan oleh karena itu, jarak jauh.
  • Bug yang terjadi selama alur penyambungan, tetapi sebelum izin pengguna (yaitu otorisasi) ditetapkan, dianggap proksimal dan oleh karena itu, jauh.
  • Bug yang terjadi setelah izin pengguna ditetapkan dianggap bersifat lokal, meskipun pada akhirnya proses penyambungan gagal.

Vektor serangan fisik dianggap lokal. Hal ini mencakup bug yang hanya dapat dieksploitasi oleh penyerang yang memiliki akses fisik ke perangkat, misalnya bug di layar kunci atau bug yang memerlukan pencolokan kabel USB. Karena perangkat sering kali tidak terkunci saat dicolokkan ke USB, serangan yang memerlukan koneksi USB memiliki tingkat keparahan yang sama, terlepas dari apakah perangkat harus tidak terkunci atau tidak.

Keamanan jaringan

Android mengasumsikan bahwa semua jaringan berbahaya dan dapat menyisipkan serangan atau memata-matai traffic. Meskipun keamanan lapisan link (misalnya, enkripsi Wi-Fi) mengamankan komunikasi antara perangkat dan Titik Akses yang terhubung dengannya, keamanan ini tidak melakukan apa pun untuk mengamankan link yang tersisa dalam rantai antara perangkat dan server yang berkomunikasi dengannya.

Sebaliknya, HTTPS biasanya melindungi seluruh komunikasi end-to-end, mengenkripsi data di sumbernya, lalu mendekripsi dan memverifikasinya hanya setelah data mencapai tujuan akhirnya. Oleh karena itu, kerentanan yang membahayakan keamanan jaringan lapisan link dinilai kurang parah dibandingkan kerentanan di HTTPS/TLS: Enkripsi Wi-Fi saja tidak cukup untuk sebagian besar komunikasi di internet.

Autentikasi biometrik

Autentikasi biometrik adalah bidang yang menantang, dan bahkan sistem terbaik pun dapat ditipu oleh kecocokan yang hampir sama (lihat Blog Developer Android: Peningkatan layar kunci dan autentikasi di Android 11). Rating tingkat keparahan ini membedakan dua kelas serangan dan dimaksudkan untuk mencerminkan risiko sebenarnya bagi pengguna akhir.

Serangan kelas pertama memungkinkan melewati autentikasi biometrik secara umum, tanpa data biometrik berkualitas tinggi dari pemilik. Misalnya, jika penyerang dapat menempelkan sepotong permen karet pada sensor sidik jari, dan permen karet tersebut memberikan akses ke perangkat berdasarkan residu yang tertinggal di sensor, itu adalah serangan sederhana yang dapat dilakukan pada perangkat yang rentan. Fitur ini tidak memerlukan pengetahuan apa pun tentang pemilik perangkat. Mengingat bahwa serangan ini dapat digeneralisasi dan berpotensi memengaruhi lebih banyak pengguna, serangan ini menerima rating tingkat keparahan penuh (misalnya, Tinggi, untuk melewati Layar kunci).

Kelas serangan lainnya umumnya melibatkan instrumen serangan presentasi (spoof) berdasarkan pemilik perangkat. Terkadang, informasi biometrik ini relatif mudah didapatkan (misalnya, jika foto profil seseorang di media sosial sudah cukup untuk menipu autentikasi biometrik, maka bypass biometrik akan menerima rating tingkat keparahan penuh). Namun, jika penyerang perlu mendapatkan data biometrik langsung dari pemilik perangkat (misalnya, pemindaian inframerah wajahnya), hal itu merupakan penghalang yang cukup signifikan sehingga membatasi jumlah orang yang terpengaruh oleh serangan, sehingga ada pengubah -1.

SYSTEM_ALERT_WINDOW dan pembajakan ketukan

Untuk mengetahui informasi tentang kebijakan kami terkait SYSTEM_ALERT_WINDOW dan pembajakan ketuk, lihat bagian "Kerentanan pembajakan ketuk/overlay SYSTEM_ALERT_WINDOW di layar yang tidak penting untuk keamanan" di halaman Bug tanpa dampak keamanan BugHunter University.

Keamanan multi-pengguna di Android Automotive OS

Android Automotive OS mengadopsi model keamanan multi-pengguna yang berbeda dari faktor bentuk lainnya. Setiap pengguna Android ditujukan untuk digunakan oleh orang fisik yang berbeda. Misalnya, pengguna tamu sementara dapat ditetapkan ke teman yang meminjam kendaraan dari pemilik mobil. Untuk mengakomodasi kasus penggunaan seperti ini, pengguna secara default memiliki akses ke komponen yang diperlukan untuk menggunakan kendaraan, seperti setelan jaringan seluler dan Wi-Fi.

Komponen yang terpengaruh

Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen tempat bug berada. Hal ini dapat 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 engineering Android di repositori internal kami.

Komponen ini juga menjadi faktor dalam cara pengguna mendapatkan update. Bug dalam framework atau kernel memerlukan update firmware over-the-air (OTA) yang harus didorong oleh setiap OEM. Bug dalam aplikasi atau library yang dipublikasikan di Google Play (misalnya, Gmail, Layanan Google Play, atau WebView) dapat dikirim ke pengguna Android sebagai update dari Google Play.

Memberi tahu partner

Jika kerentanan keamanan di AOSP diperbaiki dalam Android Security Bulletin, kami akan memberi tahu partner Android tentang detail masalah dan menyediakan patch. 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 dikirim ke AOSP setelah OTA dirilis kepada pengguna.

Menerima update Android

Update pada sistem Android umumnya dikirimkan ke perangkat melalui paket update OTA. Update ini mungkin berasal dari OEM yang memproduksi perangkat atau operator yang menyediakan layanan ke perangkat. Update perangkat Google Pixel berasal dari tim Google Pixel setelah melalui prosedur pengujian penerimaan teknis (TA) operator. Google juga memublikasikan image pabrikan Pixel yang dapat di-sideload ke perangkat.

Mengupdate layanan Google

Selain menyediakan 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 berpotensi membahayakan.

Referensi lainnya

Informasi untuk developer aplikasi Android: https://developer.android.com

Informasi keamanan ada di seluruh situs Developer dan Open Source Android. Tempat yang baik untuk memulai:

Laporan

Terkadang tim Keamanan Android memublikasikan laporan atau whitepaper. Lihat Laporan Keamanan untuk mengetahui detail selengkapnya.