Halaman ini diterjemahkan oleh Cloud Translation API.

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 dipaketkan dengan perangkat Android.

Tim keamanan Android menemukan kerentanan keamanan melalui riset internal dan juga menanggapi bug yang dilaporkan oleh pihak ketiga. Sumber bug eksternal mencakup masalah yang dilaporkan melalui formulir kerentanan , penelitian akademis yang diterbitkan dan diterbitkan sebelumnya, pengelola proyek sumber terbuka hulu, pemberitahuan dari mitra produsen perangkat kami, dan masalah yang diungkapkan secara publik yang diposting di blog atau media sosial.

Melaporkan masalah keamanan

Semua pengembang, 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 untuk mengirimkan patch atau pengujian Compatibility Test Suite (CTS) untuk mengatasi masalah keamanan, lampirkan patch tersebut ke laporan bug dan tunggu tanggapan sebelum mengunggah kode ke AOSP.

Triase 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 tempat data dijalankan. Tidak semua konteks keamanan berlaku untuk semua sistem. Tabel ini diurutkan dari yang paling rendah hingga yang paling diistimewakan.

Jenis konteks	Definisi jenis
Konteks yang dibatasi	Lingkungan eksekusi terbatas yang hanya menyediakan izin paling minimal. Misalnya, aplikasi tepercaya yang memproses data tidak tepercaya dalam lingkungan kotak pasir.
Konteks yang tidak terjangkau	Lingkungan eksekusi tipikal yang diharapkan oleh kode yang tidak memiliki 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 lebih tinggi, menangani beberapa PII pengguna, dan/atau menjaga integritas sistem. Misalnya, aplikasi Android dengan kemampuan yang akan dilarang oleh domain SELinux `untrusted_app` atau dengan akses ke `privileged\|signature` permissions.
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 perangkat keras pada perangkat) memiliki kemampuan untuk memuat skrip ke dalam komponen kernel (misalnya, eBPF) adalah salah satu dari segelintir layanan pengguna yang dianggap setara dengan kernel (seperti, `apexd` , `bpfloader` , `init` , `ueventd` , dan `vold` ).
Basis Perangkat Keras Tepercaya (THB)	Komponen perangkat keras terpisah, umumnya pada SoC, yang menyediakan fungsionalitas penting untuk kasus penggunaan inti perangkat (seperti, pita dasar seluler, DSP, GPU, dan prosesor ML).
Rantai bootloader	Komponen yang mengonfigurasi perangkat saat boot dan kemudian meneruskan kontrol ke OS Android.
Lingkungan Eksekusi Tepercaya (TEE)	Komponen yang dirancang untuk dilindungi bahkan dari Kernel OS yang bermusuhan (misalnya, TrustZone dan hypervisor, seperti pKVM, yang melindungi Mesin Virtual dari Kernel OS).
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 Android.

Kerasnya

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

Peringkat	Konsekuensi eksploitasi yang berhasil
Kritis	Eksekusi kode arbitrer di TEE atau SE Melewati mekanisme perangkat lunak yang dirancang untuk mencegah kerusakan perangkat lunak atau komponen perangkat keras terkait keselamatan (misalnya, perlindungan termal) Akses jarak jauh ke kredensial sensitif yang digunakan untuk autentikasi layanan jarak jauh (misalnya, kata sandi akun atau token pembawa) Eksekusi kode arbitrer jarak jauh dalam konteks pita dasar seluler tanpa interaksi pengguna (misalnya, mengeksploitasi bug di layanan radio seluler) Eksekusi kode arbitrer jarak jauh dalam konteks istimewa, rantai bootloader, THB, atau Kernel OS Bypass jarak jauh dari persyaratan interaksi pengguna pada penginstalan paket atau perilaku yang setara Pintasan jarak jauh dari persyaratan interaksi pengguna untuk pengembang inti, keamanan, atau setelan privasi Penolakan layanan terus-menerus jarak jauh (permanen, membutuhkan reflashing seluruh sistem operasi, atau reset pabrik) Pintasan boot aman jarak jauh Akses tidak sah ke data yang diamankan oleh SE termasuk akses yang diaktifkan oleh kunci lemah di SE.
Tinggi	Sebuah bypass lengkap dari fitur keamanan inti (misalnya, SELinux, FBE, atau `seccomp` ) Jalan pintas umum untuk pertahanan secara mendalam atau mengeksploitasi teknologi mitigasi dalam rantai bootloader, TEE, atau SE Pintasan umum untuk perlindungan sistem operasi yang menampilkan memori atau konten file lintas batas aplikasi, pengguna, atau profil Serangan terhadap SE yang mengakibatkan downgrade ke penerapan yang kurang aman Lewati perlindungan perangkat/perlindungan pengaturan ulang pabrik/pembatasan operator Lewati 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, kata sandi akun atau token pembawa) Eksekusi kode arbitrer lokal dalam konteks istimewa, rantai bootloader, THB, atau Kernel OS Pintasan boot aman lokal Pintasan layar kunci Bypass lokal dari persyaratan interaksi pengguna untuk pengembang inti, keamanan, atau pengaturan privasi Bypass lokal dari persyaratan interaksi pengguna pada penginstalan paket atau perilaku yang setara Penolakan layanan terus-menerus lokal (permanen, membutuhkan reflashing seluruh sistem operasi, atau reset pabrik) Akses jarak jauh ke data yang dilindungi (yaitu, data yang dibatasi pada konteks istimewa) Eksekusi kode arbitrer jarak jauh dalam konteks yang tidak terjangkau Pencegahan akses jarak jauh ke layanan seluler atau Wi-Fi tanpa interaksi pengguna (misalnya, menghentikan layanan radio seluler dengan paket yang salah bentuk) Bypass jarak jauh dari persyaratan interaksi pengguna (akses ke fungsionalitas 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 yang tidak dienkripsi) saat pemohon mengharapkan transmisi yang aman. Perhatikan bahwa 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	Jalan pintas umum untuk pertahanan secara mendalam atau mengeksploitasi teknologi mitigasi dalam konteks istimewa, THB, atau Kernel OS Pintasan umum untuk perlindungan sistem operasi yang mengungkapkan status proses atau metadata di seluruh batas aplikasi, pengguna, atau profil Melewati enkripsi atau autentikasi Wi-Fi Kerentanan kriptografi dalam primitif kripto standar yang memungkinkan kebocoran teks biasa (bukan primitif yang digunakan dalam TLS) Akses lokal ke data yang dilindungi (yaitu, data yang terbatas pada konteks istimewa) Eksekusi kode arbitrer lokal dalam konteks yang tidak terjangkau Bypass lokal dari persyaratan interaksi pengguna (akses ke fungsionalitas 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 terbatas Penolakan layanan perangkat sementara jarak jauh (hang atau reboot jarak jauh)
Rendah	Jalan pintas umum untuk pertahanan tingkat pengguna secara mendalam atau mengeksploitasi teknologi mitigasi dalam konteks yang tidak terjangkau Lewati izin tingkat perlindungan normal Kerentanan kriptografi dalam penggunaan non-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 terbatas Teks yang ditentukan sistem yang menyertakan deskripsi menyesatkan yang menciptakan ekspektasi keamanan palsu
Dampak Keamanan yang Dapat Diabaikan (NSI)	Kerentanan yang dampaknya telah dikurangi oleh satu atau beberapa pengubah peringkat atau perubahan arsitektur khusus versi sedemikian rupa sehingga tingkat keparahan efektifnya di bawah Rendah, meskipun masalah kode yang mendasari mungkin tetap ada Kerentanan apa pun yang memerlukan sistem file yang cacat, jika sistem file itu selalu diadopsi/dienkripsi sebelum digunakan.

Pengubah peringkat

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

Alasan	Memengaruhi
Membutuhkan menjalankan sebagai konteks istimewa untuk mengeksekusi serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM)	-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
Membutuhkan akses fisik ke internal perangkat dan masih memungkinkan jika perangkat mati atau belum dibuka kuncinya sejak dihidupkan	-1 Keparahan
Membutuhkan akses fisik ke internal perangkat saat perangkat aktif dan sebelumnya telah dibuka kuncinya	-2 Keparahan
Serangan lokal yang mengharuskan rantai bootloader dibuka kuncinya	Tidak lebih tinggi dari Rendah
Serangan lokal yang membutuhkan Mode Pengembang atau pengaturan mode pengembang tetap apa pun untuk saat ini diaktifkan pada perangkat (dan bukan merupakan 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 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 menjelajah ke halaman web, membaca email, menerima pesan SMS, atau menghubungkan 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 memerlukan pengiriman paket Wi-Fi atau Bluetooth yang cacat. Kami menganggap serangan berbasis Ultra-wideband (UWB) dan NFC sebagai proksimal dan karenanya jarak jauh.

Serangan lokal mengharuskan korban untuk menjalankan aplikasi, baik dengan memasang dan menjalankan aplikasi atau dengan menyetujui untuk menjalankan Aplikasi Instan . Perangkat pendamping yang dipasangkan akan dianggap sebagai perangkat lokal. Untuk tujuan pemeringkatan tingkat keparahan, tim keamanan Android juga mempertimbangkan 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 bug yang memerlukan mencolokkan kabel USB.

Keamanan jaringan

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

Otentikasi biometrik

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

Kelas serangan pertama memungkinkan melewati otentikasi biometrik dengan cara yang dapat digeneralisasikan, tanpa data biometrik berkualitas tinggi dari pemiliknya. Jika, misalnya, seorang penyerang dapat menempatkan permen karet pada sensor sidik jari, dan memberikan akses ke perangkat berdasarkan residu yang tertinggal di sensor, itu adalah serangan sederhana yang dapat dilakukan pada perangkat yang rentan. Itu tidak memerlukan pengetahuan apa pun dari pemilik perangkat. Karena dapat digeneralisasikan dan berpotensi memengaruhi lebih banyak pengguna, serangan ini menerima peringkat keparahan penuh (misalnya, Tinggi, untuk pintasan Layar Kunci).

Kelas serangan lain umumnya melibatkan instrumen serangan presentasi (spoof) berdasarkan pemilik perangkat. Terkadang informasi biometrik ini relatif mudah didapat (misalnya, jika foto profil seseorang di media sosial cukup untuk mengelabui autentikasi biometrik, maka bypass biometrik akan menerima peringkat keparahan penuh). Namun 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 tentang SYSTEM_ALERT_WINDOW dan tapjacking, lihat bagian " Tapjacking/overlay SYSTEM_ALERT_WINDOW kerentanan pada layar non-keamanan-kritis " BugHunter University's Bugs with no security impact page.

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 ditugaskan ke teman yang meminjam kendaraan dari pemilik mobil. Untuk mengakomodir kasus penggunaan seperti ini, pengguna secara default memiliki akses ke komponen yang diperlukan untuk menggunakan kendaraan, seperti Wi-Fi dan pengaturan jaringan seluler.

Komponen yang terpengaruh

Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen 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 bawaan pada perangkat Pixel .

Bug dalam kode AOSP diperbaiki oleh tim teknisi Android. Bug dengan tingkat keparahan rendah, bug pada komponen tertentu, atau bug yang sudah diketahui publik dapat diperbaiki langsung di cabang master AOSP yang tersedia untuk umum; jika tidak, mereka diperbaiki di repositori internal kami terlebih dahulu.

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

Memberitahu mitra

Saat kerentanan keamanan di AOSP diperbaiki di Buletin Keamanan Android, kami akan memberi tahu partner Android tentang detail masalah dan memberikan tambalan. 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 didorong ke AOSP setelah OTA dirilis ke pengguna. Perbaikan untuk masalah 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 tersebut. Pembaruan perangkat Google Pixel berasal dari tim Google Pixel setelah melalui prosedur pengujian penerimaan teknis (TA) operator. Google juga menerbitkan gambar pabrik Pixel yang dapat dimuat ke perangkat.

Memperbarui layanan Google

Selain menyediakan tambalan 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.

Sumber daya lainnya

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

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

Laporan

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