Update dan referensi keamanan

Tim keamanan Android bertanggung jawab untuk mengelola kerentanan keamanan yang ditemukan di platform Android dan banyak aplikasi Android inti yang dipaketkan 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 prapublikasi, 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 bug tersebut 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.

Melakukan triage bug

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

Jenis konteks

Tabel ini membahas 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 yang paling rendah hingga paling istimewa.

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

Misalnya, aplikasi tepercaya yang memproses data tidak tepercaya dalam lingkungan sandbox.
Konteks tanpa hak istimewa Lingkungan eksekusi standar yang diharapkan oleh kode tanpa hak istimewa.

Misalnya, aplikasi Android yang berjalan di domain SELinux dengan atribut untrusted_app_all.
Konteks dengan hak istimewa Privileged execution environment yang mungkin memiliki akses ke izin yang ditingkatkan, menangani beberapa PII pengguna, dan/atau mempertahankan 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:
  • merupakan 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).
Trusted Hardware Base (THB) Komponen hardware terpisah, umumnya di SoC, yang memberikan fungsi yang 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 Android OS.
Trusted Execution Environment (TEE) Komponen yang dirancang untuk dilindungi bahkan dari kernel OS yang berbahaya (misalnya, TrustZone dan hypervisor, seperti pKVM, yang melindungi Virtual Machine dari kernel OS).
Enklave Aman / Elemen Pengaman (SE) Komponen hardware opsional yang dirancang untuk dilindungi dari semua komponen lain di perangkat dan dari serangan fisik, seperti yang dijelaskan dalam Pengantar Elemen Pengaman.

Ini termasuk 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 dari eksploitasi yang berhasil
Kritis
  • Eksekusi kode arbitrer di TEE atau SE
  • Mengabaikan mekanisme software yang dirancang untuk mencegah komponen software atau hardware terkait keselamatan tidak berfungsi (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 dengan hak istimewa, rantai bootloader, THB, atau kernel OS
  • Pengabaian jarak jauh persyaratan interaksi pengguna pada penginstalan paket atau perilaku yang setara
  • Pengabaian jarak jauh persyaratan interaksi pengguna untuk setelan developer inti, keamanan, atau privasi
  • Denial of service persisten jarak jauh (permanen, memerlukan flashing 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
  • Pengabaian lengkap fitur keamanan inti (misalnya, SELinux, FBE, atau seccomp)
  • Pengabaian umum untuk defense in depth atau teknologi mitigasi eksploitasi dalam rantai bootloader, TEE, atau SE
  • Pengabaian umum untuk perlindungan sistem operasi yang mengungkapkan memori atau konten file di seluruh batas aplikasi, pengguna, atau profil
  • Serangan terhadap SE yang mengakibatkan downgrade ke implementasi yang kurang aman
  • Beralih dari firmware bare metal yang disusupi dan dapat dijangkau dari jarak jauh (misalnya, baseband, pemroses komunikasi (CP)) ke kernel pemroses aplikasi (AP) atau mekanisme pengabaian yang dirancang untuk mengisolasi firmware bare metal dari kernel AP
  • Mengabaikan perlindungan perangkat, perlindungan reset ke setelan pabrik, atau batasan operator
  • Mengabaikan persyaratan interaksi pengguna yang diamankan oleh TEE
  • Kerentanan kriptografi yang memungkinkan serangan terhadap protokol end-to-end, termasuk serangan terhadap transport layer security (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 dengan hak istimewa, rantai bootloader, THB, atau kernel OS
  • Pengabaian booting aman lokal
  • Pengabaian layar kunci
  • Pengabaian lokal persyaratan interaksi pengguna untuk setelan developer inti, keamanan, atau privasi
  • Pengabaian lokal persyaratan interaksi pengguna pada penginstalan paket atau perilaku yang setara
  • Denial of service persisten lokal (permanen, memerlukan flashing ulang seluruh sistem operasi, atau reset ke setelan pabrik)
  • Akses jarak jauh ke data yang dilindungi (yaitu, data yang dibatasi untuk konteks dengan hak istimewa)
  • Eksekusi kode arbitrer jarak jauh dalam konteks yang tidak memiliki hak istimewa
  • Pencegahan jarak jauh terhadap akses ke layanan seluler atau Wi-Fi tanpa interaksi pengguna (misalnya, membuat layanan radio seluler error dengan paket yang salah formatnya)
  • Pengabaian jarak jauh terhadap persyaratan interaksi pengguna (akses ke fungsi atau data yang harus memerlukan inisiasi pengguna atau izin pengguna)
  • Pencegahan yang ditargetkan terhadap akses ke layanan darurat
  • Mentransmisikan informasi sensitif melalui protokol jaringan yang tidak aman (misalnya, HTTP dan Bluetooth yang tidak dienkripsi) 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 pertahanan mendalam atau teknologi mitigasi eksploitasi dalam konteks dengan hak istimewa, THB, atau kernel OS
  • Pengabaian umum untuk perlindungan sistem operasi yang mengungkapkan status proses atau metadata di seluruh batas aplikasi, pengguna, atau profil
  • Mengabaikan enkripsi atau autentikasi Wi-Fi
  • Kerentanan kriptografis dalam primitif kripto standar yang memungkinkan kebocoran teks biasa (bukan primitif yang digunakan di TLS)
  • Akses lokal ke data yang dilindungi (yaitu, data yang dibatasi untuk konteks dengan hak istimewa)
  • Eksekusi kode arbitrer lokal dalam konteks tanpa hak istimewa
  • Pengabaian lokal terhadap 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 apa pun yang diinstal secara lokal)
  • Eksekusi kode arbitrer jarak jauh dalam konteks yang dibatasi
  • Denial of service perangkat sementara jarak jauh (hang atau mulai ulang jarak jauh)
Rendah
  • Pengabaian umum untuk pertahanan mendalam tingkat pengguna atau teknologi mitigasi eksploitasi dalam konteks tanpa hak istimewa
  • Pengabaian izin tingkat perlindungan normal
  • Kerentanan kriptografis dalam penggunaan yang tidak standar
  • Pengabaian 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 yang dibatasi
  • Teks yang ditentukan sistem yang menyertakan deskripsi menyesatkan yang menciptakan ekspektasi keamanan palsu
Dampak Keamanan yang Tidak Signifikan (NSI​)
  • Kerentanan yang dampaknya telah dimitigasi oleh satu atau beberapa pengubah rating atau perubahan arsitektur khusus versi sehingga tingkat keparahan yang efektif berada di bawah Rendah, meskipun masalah kode yang mendasarinya mungkin tetap ada
  • Setiap kerentanan yang memerlukan sistem file yang salah format, jika sistem file tersebut selalu diadopsi/dienkripsi sebelum digunakan.
  • Denial of service lokal sementara, seperti saat kondisi dapat diatasi dengan memulai ulang perangkat atau meng-uninstal aplikasi pemicu.

Pengubah tarif

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

Alasan Efek
Memerlukan operasi sebagai konteks dengan hak istimewa untuk mengeksekusi serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM) Keparahan -1
Detail khusus kerentanan membatasi dampak masalah Keparahan -1
Pengabaian autentikasi biometrik yang memerlukan informasi biometrik langsung dari pemilik perangkat Keparahan -1
Konfigurasi compiler atau platform mengurangi kerentanan dalam kode sumber Tingkat Keparahan Sedang jika kerentanan yang mendasarinya adalah Sedang atau lebih tinggi
Memerlukan akses fisik ke bagian dalam perangkat dan masih dapat dilakukan jika perangkat nonaktif atau belum dibuka kuncinya sejak dinyalakan Keparahan -1
Memerlukan akses fisik ke bagian dalam perangkat saat perangkat aktif dan sebelumnya telah dibuka kuncinya Keparahan -2
Serangan lokal yang mengharuskan rantai bootloader dibuka kuncinya Tidak lebih tinggi dari Rendah
Serangan lokal yang mengharuskan Mode Developer atau setelan mode developer persisten 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 Tidak Signifikan

Lokal versus proksimal versus jarak 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 membuka 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 Ultra-wideband (UWB) dan berbasis NFC sebagai serangan jarak dekat sehingga merupakan serangan jarak jauh.

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

Perangkat yang berhasil disambungkan (seperti perangkat pendamping Bluetooth) dianggap lokal. Kami membuat perbedaan 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 karenanya bersifat jarak jauh.
  • Bug yang terjadi selama alur penyambungan, tetapi sebelum izin pengguna (yaitu otorisasi) ditetapkan, dianggap proksimal dan karenanya bersifat jarak jauh.
  • Bug yang terjadi setelah izin pengguna ditetapkan dianggap lokal, meskipun penyambungan pada akhirnya 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 penyambungan kabel USB. Karena perangkat biasanya tidak terkunci saat dicolokkan ke USB, serangan yang memerlukan koneksi USB memiliki tingkat keparahan yang sama, terlepas dari apakah perangkat harus dibuka kuncinya atau tidak.

Keamanan jaringan

Android mengasumsikan bahwa semua jaringan berbahaya dan dapat memasukkan 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 mengamankan link yang tersisa dalam rantai antara perangkat dan server yang berkomunikasi dengannya.

Sebaliknya, HTTPS biasanya melindungi seluruh komunikasi secara menyeluruh, mengenkripsi data di sumbernya, lalu mendekripsi dan memverifikasinya hanya setelah mencapai tujuan akhir. Oleh karena itu, kerentanan yang membahayakan keamanan jaringan lapisan link diberi rating kurang parah daripada kerentanan di HTTPS/TLS: Enkripsi Wi-Fi saja tidak memadai untuk sebagian besar komunikasi di internet.

Autentikasi biometrik

Autentikasi biometrik adalah ruang yang menantang, dan bahkan sistem terbaik pun dapat tertipu oleh kemiripan (lihat Blog Android Developers: Peningkatan lockscreen dan autentikasi di Android 11). Rating keparahan ini membedakan antara dua class serangan dan dimaksudkan untuk mencerminkan risiko sebenarnya bagi pengguna akhir.

Kelas serangan pertama memungkinkan pengabaian autentikasi biometrik dengan cara yang dapat digeneralisasi, tanpa data biometrik berkualitas tinggi dari pemilik. Misalnya, jika penyerang dapat menempatkan permen karet di 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 apa pun yang rentan. Anda tidak memerlukan pengetahuan apa pun tentang pemilik perangkat. Mengingat bahwa serangan ini dapat digeneralisasi dan berpotensi memengaruhi lebih banyak pengguna, serangan ini menerima rating keparahan penuh (misalnya, Tinggi, untuk pengabaian Lockscreen).

Class serangan lainnya umumnya melibatkan instrumen serangan presentasi (spoofing) berdasarkan pemilik perangkat. Terkadang informasi biometrik ini relatif mudah didapat (misalnya, jika foto profil seseorang di media sosial cukup untuk mengelabui autentikasi biometrik, pengabaian biometrik akan menerima rating keparahan penuh). Namun, jika penyerang perlu memperoleh data biometrik langsung dari pemilik perangkat (misalnya, pemindaian inframerah wajahnya), hal itu merupakan hambatan yang cukup signifikan sehingga membatasi jumlah orang yang terpengaruh oleh serangan, sehingga ada pengubah -1.

SYSTEM_ALERT_WINDOW dan tapjacking

Untuk informasi tentang kebijakan kami terkait SYSTEM_ALERT_WINDOW dan tapjacking, lihat bagian "Kerentanan SYSTEM_ALERT_WINDOW Tapjacking/overlay pada layar yang tidak penting bagi 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 dimaksudkan 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 Wi-Fi dan jaringan seluler.

Komponen yang terpengaruh

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

Komponen ini juga merupakan faktor dalam cara pengguna mendapatkan update. Bug dalam framework atau kernel memerlukan update firmware over-the-air (OTA) yang perlu di-push 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

Saat kerentanan keamanan di AOSP diperbaiki dalam Android Security Bulletin, kami akan memberi tahu partner Android tentang detail masalah dan memberikan patch. Daftar versi yang didukung backport berubah dengan setiap rilis Android baru. Hubungi produsen perangkat untuk mengetahui daftar perangkat yang didukung.

Merilis kode ke AOSP

Jika bug keamanan ada di komponen AOSP, perbaikan akan diluncurkan ke AOSP setelah OTA dirilis kepada pengguna.

Mendapatkan update Android

Update pada sistem Android biasanya dikirimkan ke perangkat melalui paket update OTA. Update ini dapat 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 setelan pabrik 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 berbahaya.

Referensi lainnya

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

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

Laporan

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