Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Pembaruan Keamanan dan Sumber Daya

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 termasuk masalah yang dilaporkan melalui Keamanan Android Isu Template , diterbitkan dan prepublished penelitian akademis, hulu terbuka pengelola proyek sumber, pemberitahuan dari mitra produsen perangkat kami, dan secara terbuka isu diungkapkan diposting di blog atau media sosial.

Melaporkan masalah keamanan

Setiap pengembang, pengguna Android, atau peneliti keamanan dapat memberitahu tim keamanan Android dari masalah keamanan potensial 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.

Sebagai contoh, sebuah aplikasi Android yang berjalan dalam domain SELinux dengan untrusted_app_all atribut.
Konteks istimewa Lingkungan eksekusi istimewa yang mungkin memiliki akses ke izin yang lebih tinggi, menangani beberapa PII pengguna, dan/atau mempertahankan integritas sistem.

Sebagai contoh, sebuah aplikasi Android dengan kemampuan yang akan dilarang oleh SELinux untrusted_app domain atau dengan akses ke privileged|signature izin.
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 pengguna jasa yang dianggap kernel setara: 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 hardware opsional yang dirancang untuk dilindungi dari semua komponen lainnya pada perangkat dan dari serangan fisik, sebagaimana 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 keparahannya.

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
  • Memotong umum pada perangkat personalisasi fitur seperti Pertandingan Voice atau Pertandingan Wajah
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 membutuhkan filesystem cacat, jika filesystem yang 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 memerlukan korban untuk menjalankan sebuah aplikasi, baik dengan menginstal dan menjalankan aplikasi atau dengan menyetujui untuk menjalankan sebuah Instant App . 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 menantang, dan bahkan sistem terbaik dapat tertipu oleh dekat-pertandingan (lihat Android Developers Blog: Lockscreen dan otentikasi perbaikan 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 tapjacking, lihat "Tapjacking / overlay SYSTEM_ALERT_WINDOW kerentanan pada non-keamanan-kritis layar" dari BugHunter Universitas Bugs dengan tidak berdampak keamanan halaman.

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 sisi-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 diinstal dari luar Google Play, perangkat dengan Play Layanan Google juga dapat menggunakan Verifikasi Apps fitur 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:

Laporan

Terkadang tim Keamanan Android menerbitkan laporan atau laporan resmi. Lihat Laporan Keamanan untuk lebih jelasnya.