Pembaruan dan Sumber Daya Keamanan

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

Tim keamanan Android menemukan kerentanan keamanan melalui penelitian internal dan juga menanggapi bug yang dilaporkan oleh pihak ketiga. Sumber bug eksternal mencakup masalah yang dilaporkan melalui template Android Security Issue , penelitian akademis yang diterbitkan dan dipublikasikan sebelumnya, pengelola proyek open source upstream, pemberitahuan dari mitra produsen perangkat kami, dan masalah yang diungkapkan secara publik yang diposting di blog atau media sosial.

Melaporkan masalah keamanan

Setiap pengembang, pengguna Android, atau peneliti keamanan dapat memberi tahu tim keamanan Android tentang potensi masalah keamanan melalui formulir pelaporan kerentanan keamanan .

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 uji Compatibility Test Suite (CTS) untuk menyelesaikan masalah keamanan, harap lampirkan ke laporan bug dan tunggu tanggapan sebelum mengunggah kode ke AOSP.

Triaging 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 di mana ia berjalan. Tidak semua konteks keamanan berlaku untuk semua sistem. Tabel ini diurutkan dari yang paling sedikit ke yang paling istimewa.

Jenis konteks Definisi tipe
Konteks terbatas Lingkungan eksekusi terbatas di mana hanya izin paling minimal yang disediakan.

Misalnya, aplikasi "kotak pasir" untuk memproses data yang tidak tepercaya tanpa mengizinkan akses ke sistem yang mendasarinya.
Konteks yang tidak diistimewakan Lingkungan eksekusi tipikal yang diharapkan oleh kode unprivileged.

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 mempertahankan integritas sistem.

Misalnya, aplikasi Android dengan kemampuan yang akan dilarang oleh domain SELinux untrusted_app atau dengan akses ke izin privileged|signature .
Basis komputasi tepercaya (TCB) Fungsionalitas yang merupakan bagian dari kernel, berjalan dalam konteks CPU yang sama dengan kernel (seperti driver perangkat), memiliki akses langsung ke memori kernel (seperti komponen perangkat keras pada perangkat), memiliki kemampuan untuk memuat skrip ke dalam komponen kernel ( misalnya, eBPF), prosesor komunikasi, atau merupakan salah satu dari segelintir layanan pengguna yang dianggap setara dengan kernel: apexd , bpfloader , init , ueventd , dan vold .
Rantai Bootloader Komponen yang mengonfigurasi perangkat saat boot dan kemudian meneruskan kontrol ke OS Android.
Lingkungan Eksekusi Tepercaya (TEE) Sebuah komponen yang dirancang untuk dilindungi bahkan dari kernel yang tidak bersahabat (misalnya, TrustZone dan Hypervisor).
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 Pixel.

Kerasnya

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

Peringkat Konsekuensi dari eksploitasi yang berhasil
Kritis
  • Akses tidak sah ke data yang diamankan oleh SE
  • Eksekusi kode arbitrer di TEE atau SE
  • Eksekusi kode arbitrer jarak jauh dalam konteks istimewa, rantai bootloader, atau TCB
  • Penolakan layanan persisten jarak jauh (permanen atau memerlukan reflash seluruh sistem operasi atau reset pabrik)
  • Bypass jarak jauh dari persyaratan interaksi pengguna pada instalasi paket atau perilaku yang setara
  • Mengabaikan persyaratan interaksi pengguna dari jarak jauh untuk pengaturan pengembang, keamanan, atau privasi apa pun
  • Bypass boot aman jarak jauh
  • Melewati mekanisme yang dirancang untuk mencegah kegagalan fungsi perangkat lunak atau komponen perangkat keras yang terkait dengan keselamatan (misalnya, perlindungan termal)
  • Akses jarak jauh ke kredensial sensitif yang digunakan untuk otentikasi layanan jarak jauh (Misalnya, kata sandi akun atau token pembawa)
Tinggi
  • Bypass boot aman lokal
  • Pengabaian lengkap fitur keamanan inti (seperti SELinux, FDE, atau seccomp)
  • Eksekusi kode arbitrer jarak jauh dalam konteks yang tidak diprioritaskan
  • Eksekusi kode arbitrer lokal dalam konteks istimewa, rantai bootloader, atau TCB
  • Akses tidak sah ke data yang diamankan oleh TEE
  • Serangan terhadap SE yang mengakibatkan penurunan versi ke implementasi yang kurang aman
  • Bypass lokal dari persyaratan interaksi pengguna pada instalasi paket atau perilaku yang setara
  • Akses jarak jauh ke data yang dilindungi (data yang terbatas pada konteks yang diistimewakan)
  • Penolakan layanan terus-menerus lokal (permanen atau memerlukan reflashing seluruh sistem operasi atau reset pabrik)
  • Pengabaian jarak jauh dari persyaratan interaksi pengguna (akses ke fungsionalitas atau data yang biasanya memerlukan inisiasi pengguna atau izin pengguna)
  • Mengirimkan informasi sensitif melalui protokol jaringan yang tidak aman (misalnya, HTTP dan Bluetooth yang tidak terenkripsi) saat pemohon mengharapkan transmisi yang aman (perhatikan bahwa ini tidak berlaku untuk enkripsi Wi-Fi, seperti WEP)
  • Bypass umum untuk pertahanan secara mendalam atau mengeksploitasi teknologi mitigasi dalam rantai bootloader, TEE, atau SE
  • Bypass umum untuk perlindungan sistem operasi yang mengisolasi data aplikasi atau profil pengguna satu sama lain
  • Pengabaian lokal persyaratan interaksi pengguna untuk pengembang, keamanan, atau pengaturan privasi apa pun
  • Kerentanan kriptografi yang memungkinkan serangan terhadap protokol end-to-end, termasuk serangan terhadap transport layer security (TLS) dan Bluetooth (BT).
  • Bypass layar kunci
  • Lewati perlindungan perangkat/perlindungan reset pabrik/pembatasan operator
  • Pencegahan yang ditargetkan terhadap akses ke layanan darurat
  • Lewati persyaratan interaksi pengguna yang diamankan oleh TEE
  • Pencegahan jarak jauh terhadap akses ke layanan seluler tanpa interaksi pengguna (misalnya, merusak layanan radio seluler dengan paket yang salah format)
  • Akses lokal ke kredensial sensitif yang digunakan untuk otentikasi layanan jarak jauh (misalnya, kata sandi akun atau token pembawa)
Sedang
  • Eksekusi kode arbitrer jarak jauh dalam konteks terbatas
  • Penolakan layanan perangkat sementara jarak jauh (hang atau reboot jarak jauh)
  • Eksekusi kode arbitrer lokal dalam konteks unprivileged
  • Bypass umum untuk pertahanan secara mendalam atau mengeksploitasi teknologi mitigasi dalam konteks istimewa atau TCB
  • Bypass pembatasan pada proses yang dibatasi
  • Akses jarak jauh ke data yang tidak dilindungi (data biasanya dapat diakses oleh aplikasi yang diinstal secara lokal)
  • Akses lokal ke data yang dilindungi (data yang terbatas pada konteks yang diistimewakan)
  • Bypass lokal dari persyaratan interaksi pengguna (akses ke fungsionalitas atau data yang biasanya memerlukan inisiasi pengguna atau izin pengguna)
  • Kerentanan kriptografis dalam primitif kripto standar yang memungkinkan kebocoran teks biasa (bukan primitif yang digunakan dalam TLS)
  • Melewati enkripsi atau otentikasi Wi-Fi
Rendah
  • Eksekusi kode arbitrer lokal dalam konteks terbatas
  • Kerentanan kriptografi dalam penggunaan non-standar
  • Bypass umum untuk pertahanan tingkat pengguna secara mendalam atau mengeksploitasi teknologi mitigasi dalam konteks yang tidak diprioritaskan
  • Dokumentasi yang salah yang dapat menyebabkan kesalahpahaman terkait keamanan dengan kerusakan kode berikutnya
  • Pengabaian umum fitur personalisasi pada perangkat seperti Voice Match atau Face Match
Dampak Keamanan yang Dapat Diabaikan (NSI)
  • Kerentanan yang dampaknya telah dikurangi oleh satu atau lebih pengubah peringkat atau perubahan arsitektur khusus versi sehingga tingkat keparahan efektif di bawah Rendah, meskipun masalah kode yang mendasarinya mungkin tetap ada
  • Setiap kerentanan yang memerlukan sistem file yang cacat, jika sistem file tersebut selalu diadopsi/dienkripsi sebelum digunakan.

Pengubah peringkat

Sementara tingkat keparahan kerentanan keamanan seringkali mudah diidentifikasi, peringkat dapat berubah berdasarkan keadaan.

Alasan Memengaruhi
Membutuhkan berjalan sebagai konteks istimewa untuk mengeksekusi serangan -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
Memerlukan akses fisik ke internal perangkat dan masih memungkinkan jika perangkat mati atau belum dibuka kuncinya sejak dihidupkan -1 Keparahan
Memerlukan akses fisik ke internal perangkat saat perangkat aktif dan sebelumnya telah dibuka kuncinya -2 Keparahan
Serangan lokal yang membutuhkan rantai bootloader untuk dibuka kuncinya Tidak lebih tinggi dari Rendah
Serangan lokal yang memerlukan Mode Pengembang atau pengaturan mode pengembang tetap untuk saat ini diaktifkan di perangkat (dan bukan merupakan bug dalam Mode Pengembang itu sendiri). Tidak lebih tinggi dari Rendah
Jika tidak ada domain SELinux yang dapat melakukan operasi di bawah 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 menjelajahi halaman web, membaca email, menerima pesan SMS, atau terhubung 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 mengharuskan pengiriman paket Wi-Fi atau Bluetooth yang salah. Kami menganggap serangan Ultra-wideband (UWB) dan berbasis NFC sebagai serangan proksimal dan karena itu jauh.

Serangan lokal mengharuskan korban untuk menjalankan aplikasi, baik dengan menginstal dan menjalankan aplikasi atau dengan menyetujui untuk menjalankan Aplikasi Instan . Untuk tujuan peringkat keparahan, kami juga menganggap 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 yang memerlukan mencolokkan kabel USB. Perhatikan bahwa serangan yang memerlukan koneksi USB memiliki tingkat keparahan yang sama terlepas dari apakah perangkat harus dibuka kuncinya atau tidak; biasanya perangkat dibuka kuncinya saat dicolokkan ke USB.

Keamanan jaringan

Android berasumsi bahwa semua jaringan bermusuhan dan dapat menyuntikkan serangan atau memata-matai lalu lintas. Sementara keamanan lapisan tautan (misalnya, enkripsi Wi-Fi) mengamankan komunikasi antara perangkat dan Titik Akses yang terhubung dengannya, itu 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, kemudian mendekripsi dan memverifikasinya hanya setelah mencapai tujuan akhirnya. Karena itu, kerentanan yang membahayakan keamanan jaringan lapisan tautan dinilai lebih ringan daripada kerentanan di HTTPS/TLS: Enkripsi Wi-Fi saja tidak cukup untuk sebagian besar komunikasi di internet.

Otentikasi biometrik

Otentikasi biometrik adalah ruang yang menantang, dan bahkan sistem terbaik pun dapat dikelabui dengan hampir sama (lihat Blog Pengembang Android: Layar kunci dan peningkatan autentikasi di Android 11 ). Peringkat keparahan ini membedakan antara dua kelas serangan dan dimaksudkan untuk mencerminkan risiko aktual bagi pengguna akhir.

Serangan kelas pertama memungkinkan melewati otentikasi biometrik dengan cara yang dapat digeneralisasikan, tanpa data biometrik berkualitas tinggi dari pemiliknya. Jika, misalnya, penyerang dapat menempatkan sepotong permen karet pada sensor sidik jari, dan memberikan akses ke perangkat berdasarkan residu yang tersisa di sensor, itu adalah serangan sederhana yang dapat dilakukan pada perangkat yang rentan. Itu tidak memerlukan pengetahuan tentang pemilik perangkat. Mengingat bahwa itu 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 didapat (misalnya, jika gambar profil seseorang di media sosial cukup untuk mengelabui autentikasi biometrik, maka bypass biometrik akan menerima peringkat tingkat keparahan penuh). Tetapi 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 mengenai SYSTEM_ALERT_WINDOW dan penyadapan, lihat bagian " Penyadapan/overlay kerentanan SYSTEM_ALERT_WINDOW pada layar non-keamanan-kritis " dari Bug Universitas BugHunter tanpa dampak keamanan .

Komponen yang terpengaruh

Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen di 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 yang dimuat sebelumnya pada 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 secara langsung di cabang master AOSP yang tersedia untuk umum; jika tidak, mereka diperbaiki di repositori internal kami terlebih dahulu.

Komponen juga merupakan faktor bagaimana pengguna mendapatkan pembaruan. Bug dalam kerangka kerja atau kernel memerlukan pembaruan firmware over-the-air (OTA) yang perlu 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.

Memberi tahu mitra

Saat kerentanan keamanan di AOSP diperbaiki di Buletin Keamanan Android, kami akan memberi tahu mitra Android tentang detail masalah dan memberikan tambalan. Daftar versi yang didukung backport berubah dengan setiap rilis Android baru. Hubungi produsen perangkat Anda untuk daftar perangkat yang didukung.

Melepaskan kode ke AOSP

Jika bug keamanan ada di komponen AOSP, perbaikannya didorong ke AOSP setelah OTA dirilis ke pengguna. Perbaikan untuk masalah dengan 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. 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 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 dipasang dari luar Google Play, perangkat dengan Layanan Google Play juga dapat menggunakan fitur Verifikasi Aplikasi untuk memperingatkan pengguna tentang aplikasi yang mungkin berpotensi berbahaya.

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:

Laporan

Terkadang tim Keamanan Android menerbitkan laporan atau laporan resmi. Lihat Laporan Keamanan untuk detail selengkapnya.