Resource dan Update Keamanan

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

Tim keamanan Android menemukan kerentanan keamanan melalui penelitian internal dan juga menanggapi {i>bug<i} yang dilaporkan oleh pihak ketiga. Sumber bug eksternal termasuk masalah yang dilaporkan melalui formulir kerentanan, penelitian akademis yang telah dipublikasikan dan telah dipublikasikan, pengelola project open source upstream, notifikasi dari partner produsen perangkat kami, serta masalah yang diungkapkan secara publik yang diposting di blog atau media sosial.

Melaporkan masalah keamanan

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 terjadi terlihat setelah masalah dievaluasi atau diselesaikan. Jika Anda berencana untuk mengirimkan patch atau Tes Compatibility Test Suite (CTS) untuk menyelesaikan masalah keamanan, harap lampirkan ke bug dan menunggu respons sebelum mengupload kode ke AOSP.

Memilah bug

Tugas pertama dalam menangani kerentanan keamanan adalah mengidentifikasi tingkat keparahan {i>bug<i} 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 di-deploy kepada pengguna.

Jenis konteks

Tabel ini mencakup definisi dalam konteks keamanan hardware dan software. Konteks dapat ditentukan oleh sensitivitas data yang biasanya diproses atau area tempat data dijalankan. Bukan semua konteks keamanan berlaku untuk semua sistem. Tabel ini diurutkan dari yang paling sedikit ke yang paling banyak dilindungi.

Jenis konteks Definisi jenis
Konteks terbatas {i>Restricted execution environment<i} di mana hanya izin akses yang paling minimal yang Anda berikan.

Misalnya, aplikasi tepercaya yang memproses data tidak tepercaya dalam sandbox lingkungan fleksibel App Engine.
Konteks tanpa hak istimewa Lingkungan eksekusi umum yang diharapkan oleh kode yang tidak memiliki hak istimewa.

Misalnya, aplikasi Android yang berjalan dalam domain SELinux dengan Atribut untrusted_app_all.
Konteks istimewa Lingkungan eksekusi dengan hak istimewa yang mungkin memiliki akses ke izin yang ditingkatkan, beberapa pengguna PII, dan/atau mempertahankan integritas sistem.

Misalnya, aplikasi Android dengan kemampuan yang dilarang oleh Domain SELinux untrusted_app atau dengan akses ke Izin privileged|signature.
Kernel OS Fungsi yang:
  • merupakan bagian dari {i>kernel<i}
  • berjalan dalam konteks CPU yang sama dengan kernel (misalnya, driver perangkat)
  • memiliki akses langsung ke memori kernel (misalnya, komponen hardware pada perangkat)
  • memiliki kemampuan untuk memuat skrip ke dalam komponen kernel (misalnya, eBPF)
  • adalah salah satu dari beberapa layanan pengguna yang dianggap setara dengan {i>kernel<i} (seperti, apexd, bpfloader, init, ueventd, dan vold).
Basis Hardware Tepercaya (THB) Komponen perangkat keras diskret, umumnya pada SoC, yang menyediakan fungsi penting untuk kasus penggunaan inti perangkat (seperti, baseband seluler, DSP, GPU, dan ML pemroses).
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 {i>kernel<i} OS yang tidak aman (misalnya, TrustZone dan hypervisor, seperti pKVM, yang melindungi Mesin Virtual dari OS {i>kernel<i}).
Enklave Pengaman / Elemen Pengaman (SE) Komponen perangkat keras opsional yang dirancang untuk dilindungi dari semua komponen lain pada 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 {i>bug<i} umumnya mencerminkan potensi bahaya yang dapat terjadi jika {i>bug<i} berhasil dieksploitasi. Gunakan kriteria berikut untuk menentukan tingkat keparahan.

Rating Konsekuensi dari keberhasilan eksploitasi
Penting
  • Eksekusi kode arbitrer di TEE atau SE
  • Pengabaian mekanisme software yang dirancang untuk mencegah software atau hardware terkait keamanan komponen dari malfungsi (misalnya, perlindungan termal)
  • Akses jarak jauh ke kredensial sensitif yang digunakan untuk otentikasi layanan jarak jauh (untuk misalnya, sandi akun atau token pemilik)
  • Eksekusi kode arbitrer jarak jauh dalam konteks baseband seluler tanpa pengguna (misalnya, memanfaatkan bug dalam layanan radio seluler)
  • Eksekusi kode arbitrer jarak jauh dalam konteks hak istimewa, rantai bootloader, THB, atau {i>kernel<i} OS
  • Pengabaian persyaratan interaksi pengguna dari jarak jauh pada penginstalan paket atau yang setara perilaku
  • Pengabaian persyaratan interaksi pengguna dari jarak jauh untuk developer, keamanan, atau pengaturan privasi
  • Denial of service jarak jauh yang persisten (permanen, yang memerlukan flash ulang seluruh layanan) sistem operasi, atau pengaturan ulang pabrik)
  • Pengabaian booting aman jarak jauh
  • Akses tidak sah ke data yang diamankan oleh SE termasuk akses yang diaktifkan oleh kunci yang lemah di SE.
Tinggi
  • Pengabaian lengkap fitur keamanan inti (misalnya, SELinux, FBE, atau seccomp)
  • Pengabaian umum untuk pertahanan mendalam atau mengeksploitasi teknologi mitigasi di rantai bootloader, TEE, atau SE
  • Pengabaian umum untuk perlindungan sistem operasi yang menampilkan isi file atau memori di seluruh batas aplikasi, pengguna, atau profil
  • Serangan terhadap SE yang mengakibatkan downgrade ke implementasi yang kurang aman
  • Beralih dari firmware bare-metal tersusupi yang dapat dijangkau dari jarak jauh (mis. baseband, CP/Communication Processor) ke dalam kernel Application Processor (AP) atau pengabaian mekanisme yang dirancang untuk mengisolasi {i> bare-metal<i} dari {i>kernel<i} AP
  • Pengabaian perlindungan perangkat/perlindungan reset ke setelan pabrik/pembatasan operator
  • Pengabaian persyaratan interaksi pengguna yang dilindungi oleh TEE
  • Kerentanan kriptografi yang memungkinkan serangan terhadap protokol {i>end-to-end<i}, termasuk serangan terhadap Transport Layer Security (TLS) dan Bluetooth (BT).
  • Akses lokal ke kredensial sensitif yang digunakan untuk otentikasi layanan jarak jauh (untuk misalnya, sandi akun atau token pemilik)
  • Eksekusi kode arbitrer lokal dalam konteks hak istimewa, rantai bootloader, THB, atau {i>kernel<i} OS
  • Pengabaian booting aman lokal
  • Pengabaian layar kunci
  • Pengabaian lokal persyaratan interaksi pengguna untuk developer, keamanan, atau privasi inti pengaturan
  • Pengabaian lokal persyaratan interaksi pengguna pada penginstalan paket atau yang setara perilaku
  • Denial of service lokal yang persisten (permanen, yang memerlukan flash ulang seluruh sistem operasi, atau reset ke setelan pabrik)
  • Akses jarak jauh ke data yang dilindungi (yaitu, data yang dibatasi untuk hak istimewa konteks)
  • Eksekusi kode arbitrer jarak jauh dalam konteks yang tidak memiliki hak istimewa
  • Pencegahan jarak jauh terhadap layanan seluler atau Wi-Fi tanpa interaksi pengguna (untuk misalnya, layanan radio seluler error dengan paket yang salah format)
  • Pengabaian persyaratan interaksi pengguna dari jarak jauh (akses ke fungsi atau data yang harus memerlukan inisiasi pengguna atau izin pengguna)
  • Pencegahan akses yang ditargetkan ke layanan darurat
  • Mengirimkan informasi sensitif melalui protokol jaringan yang tidak aman (misalnya, HTTP dan Bluetooth tidak terenkripsi) jika pemohon mengharapkan transmisi yang aman. Catatan 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 tombol yang lemah di TEE
Sedang
  • Pengabaian umum untuk pertahanan mendalam atau mengeksploitasi teknologi mitigasi dalam konteks 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 autentikasi atau enkripsi Wi-Fi
  • Kerentanan kriptografi dalam primitif kriptografi standar yang memungkinkan kebocoran teks biasa (bukan primitif yang digunakan di TLS)
  • Akses lokal ke data yang dilindungi (yaitu, data yang dibatasi untuk konteks hak istimewa)
  • Eksekusi kode arbitrer lokal dalam konteks yang tidak memiliki hak istimewa
  • Pengabaian lokal persyaratan interaksi pengguna (akses ke fungsi atau data yang biasanya akan memerlukan inisiasi pengguna atau izin pengguna)
  • Akses jarak jauh ke data yang tidak dilindungi (yaitu, data yang biasanya dapat diakses oleh server lokal apa pun aplikasi terinstal)
  • Eksekusi kode arbitrer jarak jauh dalam konteks yang dibatasi
  • Denial of service perangkat sementara jarak jauh (menghang dari jarak jauh atau memulai ulang)
Rendah
  • Pengabaian umum untuk pertahanan tingkat pengguna secara mendalam atau mengeksploitasi teknologi mitigasi dalam konteks tanpa hak istimewa
  • Pengabaian normal tingkat perlindungan izin
  • Kerentanan kriptografi dalam penggunaan non-standar
  • Pengabaian umum fitur personalisasi di perangkat seperti Voice Match atau Face Match
  • Dokumentasi salah yang dapat menyebabkan kerentanan keamanan
  • Eksekusi kode arbitrer lokal dalam konteks yang dibatasi
  • Teks yang ditentukan sistem yang mencakup deskripsi menyesatkan yang menghasilkan informasi palsu ekspektasi keamanan
Dampak Keamanan yang Dapat Diabaikan (NSI)
  • Kerentanan yang dampaknya telah dimitigasi oleh satu atau beberapa pengubah rating atau perubahan arsitektur spesifik per versi sehingga tingkat keparahan efektif di bawah Rendah, meskipun masalah kode yang mendasarinya mungkin tetap
  • Kerentanan apa pun yang membutuhkan sistem file yang rusak, jika sistem file itu selalu diadopsi/dienkripsi sebelum digunakan.
  • Denial of service sementara lokal, seperti saat kondisi dapat diselesaikan dengan memulai ulang perangkat atau meng-uninstal aplikasi yang memicu.

Pengubah rating

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

Alasan Efek
Memerlukan dijalankan sebagai konteks hak istimewa untuk menjalankan serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM) -1 Tingkat Keparahan
Detail khusus kerentanan membatasi dampak masalah -1 Tingkat Keparahan
Pengabaian otentikasi biometrik yang membutuhkan informasi biometrik langsung dari pemilik perangkat -1 Tingkat Keparahan
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 -1 Tingkat Keparahan
Memerlukan akses fisik ke internal perangkat saat perangkat aktif dan sebelumnya telah telah dibuka -2 Tingkat Keparahan
Serangan lokal yang mengharuskan rantai bootloader tidak terkunci Tidak lebih tinggi dari Rendah
Serangan lokal yang memerlukan Mode Pengembang atau pengaturan mode pengembang persisten untuk diaktifkan di perangkat (dan bukan 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 yang Sederhana

Lokal versus Proksimal versus Jarak Jauh

Vektor serangan jarak jauh menunjukkan bahwa {i>bug<i} dapat dieksploitasi tanpa menginstal aplikasi atau tanpa memiliki akses fisik ke sebuah perangkat. Ini termasuk bug yang dapat dipicu dengan menjelajah ke laman web, membaca email, menerima pesan SMS, atau menyambungkan ke jaringan yang berbahaya.

Vektor serangan {i>proximal<i} dianggap jarak jauh. Termasuk bug yang hanya dapat dieksploitasi oleh penyerang yang berada di dekat perangkat target secara fisik, misalnya, {i>bug<i} yang membutuhkan mengirim paket Wi-Fi atau Bluetooth dengan format yang salah. Kami menggunakan Ultra-wideband (UWB) dan berbasis NFC serangan sebagai {i>proximal<i} dan karenanya jarak jauh.

Serangan lokal mengharuskan penyerang memiliki akses lebih awal ke korban. Dalam sebuah hipotesis khusus perangkat lunak, ini bisa berupa aplikasi berbahaya yang telah diinstal korban, atau Aplikasi Instan yang mereka miliki setuju untuk dijalankan.

Perangkat yang berhasil disambungkan (seperti perangkat pendamping Bluetooth) dianggap lokal. Rab membuat perbedaan antara perangkat yang disambungkan dan perangkat yang berpartisipasi dalam penyambungan alur kerja.

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

Vektor serangan fisik dianggap lokal. Termasuk bug yang hanya dapat dieksploitasi oleh penyerang yang memiliki akses fisik ke perangkat, misalnya {i>bug<i} di layar kunci atau yang membutuhkan mencolokkan kabel USB. Karena umumnya perangkat yang tidak terkunci saat digunakan dicolokkan ke USB, serangan yang membutuhkan koneksi USB memiliki tingkat keparahan yang sama terlepas dari apakah perangkat perlu dibuka kuncinya atau tidak.

Keamanan jaringan

Android menganggap semua jaringan bersifat berbahaya dan dapat menyuntikkan serangan atau memata-matai kemacetan. Meskipun keamanan lapisan link (misalnya, enkripsi Wi-Fi) mengamankan komunikasi antara perangkat dan Titik Akses yang tersambung, alat ini tidak melakukan apa pun tautan yang tersisa dalam rantai antara perangkat dan server yang berkomunikasi dengannya.

Sebaliknya, HTTPS biasanya melindungi seluruh komunikasi secara menyeluruh, dengan mengenkripsi data sumbernya, lalu mendekripsi dan memverifikasinya hanya setelah mencapai tujuan akhirnya. Oleh karena itu, kerentanan yang menyusupi keamanan jaringan {i>link-layer<i} dinilai lebih rendah lebih parah dibandingkan kerentanan pada HTTPS/TLS: Enkripsi Wi-Fi saja tidak cukup untuk komunikasi di internet.

Autentikasi biometrik

Otentikasi biometrik adalah ruang yang menantang, dan bahkan sistem terbaik pun dapat tertipu oleh kecocokan mendekati (lihat Blog Developer Android: Peningkatan autentikasi dan layar kunci di Android 11). Peringkat tingkat keparahan ini membedakan antara dua kelas serangan dan ditujukan untuk mencerminkan risiko yang sebenarnya kepada pengguna akhir.

Serangan kelas satu memungkinkan pengabaian otentikasi biometrik dengan cara yang dapat digeneralisasi, tanpa data biometrik berkualitas tinggi dari pemiliknya. Misalnya, jika penyerang dapat menempatkan sepotong permen karet di sensor sidik jari, dan memberikan akses ke perangkat berdasarkan residu yang tersisa pada sensor, itu adalah serangan sederhana yang dapat dilakukan pada perangkat apa pun yang rentan. Ini tidak memerlukan informasi tentang pemilik perangkat. Mengingat bahwa {i>metadata <i} dapat digeneralisasi dan berpotensi memengaruhi sejumlah besar pengguna, serangan ini menerima tingkat keparahan penuh (misalnya, Tinggi, untuk pengabaian Layar kunci).

Jenis serangan lainnya umumnya melibatkan instrumen serangan presentasi (spoof) yang berbasis pada pemilik perangkat. Terkadang informasi biometrik ini relatif mudah diperoleh (untuk misalnya, jika foto profil seseorang di media sosial sudah cukup untuk memperdaya upaya otentikasi biometrik, maka pengabaian biometrik akan menerima peringkat tingkat keparahan penuh). Tapi jika seorang penyerang membutuhkan untuk memperoleh data biometrik langsung dari pemilik perangkat (misalnya, pemindaian inframerah wajah mereka), merupakan penghalang yang cukup signifikan sehingga membatasi jumlah orang yang terkena dampak oleh serangan itu, jadi ada pengubah -1.

SYSTEM_ALERT_WINDOW dan Tapjacking

Untuk mengetahui informasi tentang kebijakan kami terkait SYSTEM_ALERT_WINDOW dan tapjacking, lihat "Kerentanan Tapjacking/overlay SYSTEM_ALERT_WINDOW pada layar yang tidak penting bagi keamanan" dari BugHunter University Bug tanpa dampak keamanan kami.

Keamanan multi-pengguna di Android Automotive OS

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

Komponen yang terpengaruh

Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen tempat bug berada. {i>Driver<i} dapat menjadi komponen inti dari platform Android, {i>driver<i} {i>kernel<i} yang disediakan oleh produsen peralatan (OEM), atau salah satu aplikasi bawaan di perangkat Pixel.

Bug dalam kode AOSP telah diperbaiki oleh tim engineer Android. Bug tingkat keparahan rendah, bug dalam komponen tertentu, atau {i>bug<i} yang telah diketahui secara umum dapat diperbaiki secara langsung dalam cabang utama AOSP yang tersedia secara publik; jika tidak, mereka akan diperbaiki di repositori internal kami terlebih dahulu.

Komponen ini juga merupakan faktor dalam cara pengguna mendapatkan update. {i>Bug<i} dalam framework atau {i>kernel<i} memerlukan update firmware over the air (OTA) yang perlu dikirim oleh setiap OEM. {i>Bug<i} di aplikasi atau library yang dipublikasikan di Google Play (misalnya, Gmail, Layanan Google Play, atau WebView) dikirim ke pengguna Android sebagai update dari Google Play.

Memberi tahu partner

Ketika kerentanan keamanan di AOSP telah diperbaiki dalam Buletin Keamanan Android, kami akan memberi tahu Partner Android yang membahas detail masalah dan memberikan patch. Daftar versi yang didukung backport perubahan di setiap rilis Android baru. Hubungi produsen perangkat Anda untuk mendapatkan daftar perangkat yang didukung.

Merilis kode ke AOSP

Jika bug keamanan ada dalam komponen AOSP, perbaikan diteruskan ke AOSP setelah OTA dirilis ke pengguna. Perbaikan untuk masalah tingkat keparahan rendah dapat dikirimkan langsung ke layanan AOSP sebelum perbaikan tersedia untuk perangkat melalui OTA.

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 ke perangkat. Update perangkat Google Pixel datang dari tim Google Pixel setelah pergi melalui prosedur pengujian penerimaan teknis (TA) ekspedisi. Google juga memublikasikan Setelan pabrik Pixel yang dapat di-side-load ke perangkat.

Memperbarui layanan Google

Selain menyediakan patch untuk bug keamanan, tim keamanan Android juga meninjau keamanan {i>bugs<i} 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 di luar Google Play, perangkat dengan Layanan Google Play juga dapat menggunakan Fitur Verifikasi Aplikasi untuk memperingatkan kepada pengguna mengenai aplikasi yang mungkin berpotensi berbahaya.

Referensi lainnya

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

Informasi keamanan ada di seluruh situs Developer dan Open Source Android. Bagus tempat untuk memulai:

Laporan

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