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

Tim keamanan Android menemukan kerentanan keamanan melalui penelitian internal dan juga merespons bug yang dilaporkan oleh pihak ketiga. Sumber bug eksternal mencakup masalah yang dilaporkan melalui formulir kerentanan , penelitian akademis yang dipublikasikan dan dipublikasikan 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

Pengembang, pengguna Android, atau peneliti keamanan mana pun dapat memberi tahu tim keamanan Android tentang potensi masalah keamanan melalui formulir kerentanan .

Bug yang ditandai sebagai masalah keamanan tidak terlihat secara eksternal, namun pada akhirnya dapat terlihat setelah masalah dievaluasi atau diselesaikan. Jika Anda berencana mengirimkan patch atau pengujian Compatibility Test Suite (CTS) untuk menyelesaikan masalah keamanan, harap lampirkan ke laporan bug dan tunggu respons sebelum mengunggah kode ke AOSP.

Memprioritaskan 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 kepada pengguna.

Jenis konteks

Tabel ini mencakup definisi konteks keamanan perangkat keras dan perangkat lunak. Konteksnya dapat ditentukan oleh sensitivitas data yang biasanya diproses atau area di mana data tersebut dijalankan. Tidak semua konteks keamanan dapat diterapkan pada semua sistem. Tabel ini diurutkan dari yang paling istimewa hingga yang paling istimewa.

Tipe konteks Definisi tipe
Konteks terbatas Lingkungan eksekusi terbatas yang hanya memberikan izin paling minimal.

Misalnya, aplikasi tepercaya memproses data tidak tepercaya dalam lingkungan sandbox.
Konteks yang tidak memiliki hak istimewa 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 dengan hak istimewa yang mungkin memiliki akses ke izin yang lebih tinggi, menangani banyak PII pengguna, dan/atau menjaga integritas sistem.

Misalnya, aplikasi Android dengan kemampuan yang dilarang oleh domain SELinux untrusted_app atau dengan akses ke privileged|signature .
inti sistem operasi Fungsionalitas yang:
  • adalah 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 tidak bersahabat (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, sebagaimana didefinisikan dalam Pengantar Elemen Aman .

Ini termasuk chip Titan-M yang ada di beberapa perangkat Android.

Kerasnya

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

Peringkat Konsekuensi dari eksploitasi yang berhasil
Kritis
  • Eksekusi kode sewenang-wenang di TEE atau SE
  • Melewati mekanisme perangkat lunak yang dirancang untuk mencegah kegagalan fungsi komponen perangkat lunak atau 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 terhadap persyaratan interaksi pengguna pada instalasi paket atau perilaku yang setara
  • Bypass jarak jauh terhadap persyaratan interaksi pengguna untuk pengembang inti, keamanan, atau pengaturan privasi
  • Penolakan layanan yang terus-menerus dari jarak jauh (permanen, memerlukan flashing ulang seluruh sistem operasi, atau reset pabrik)
  • Bypass boot aman jarak jauh
  • Akses tidak sah terhadap data yang diamankan oleh SE termasuk akses yang diaktifkan oleh kunci lemah di SE.
Tinggi
  • Bypass lengkap fitur keamanan inti (misalnya, SELinux, FBE, atau seccomp )
  • Jalan pintas umum untuk pertahanan mendalam atau memanfaatkan teknologi mitigasi dalam rantai bootloader, TEE, atau SE
  • Jalan pintas umum untuk perlindungan sistem operasi yang mengungkapkan memori atau konten file melintasi batas aplikasi, pengguna, atau profil
  • Serangan terhadap SE yang mengakibatkan penurunan versi ke implementasi yang kurang aman
  • Berputar dari firmware bare-metal terkompromi yang dapat dijangkau dari jarak jauh (misalnya baseband, CP/Prosesor Komunikasi) ke dalam kernel Prosesor Aplikasi (AP) atau mekanisme bypass yang dirancang untuk mengisolasi firmware bare-metal dari kernel AP
  • Lewati perlindungan perangkat/perlindungan reset pabrik/pembatasan operator
  • Lewati persyaratan interaksi pengguna yang diamankan oleh TEE
  • Kerentanan kriptografi yang memungkinkan terjadinya serangan terhadap protokol end-to-end, termasuk serangan terhadap keamanan lapisan transport (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
  • Bypass boot aman lokal
  • Bypass layar kunci
  • Pengabaian lokal terhadap persyaratan interaksi pengguna untuk pengembang inti, keamanan, atau pengaturan privasi
  • Bypass lokal terhadap persyaratan interaksi pengguna pada instalasi paket atau perilaku yang setara
  • Penolakan layanan lokal yang persisten (permanen, memerlukan flashing ulang 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 tanpa hak istimewa
  • Pencegahan jarak jauh terhadap akses ke layanan seluler atau Wi-Fi tanpa interaksi pengguna (misalnya, menghentikan layanan radio seluler dengan paket yang salah format)
  • Bypass jarak jauh terhadap persyaratan interaksi pengguna (akses ke fungsionalitas atau data yang memerlukan inisiasi pengguna atau izin pengguna)
  • Pencegahan yang ditargetkan terhadap akses terhadap layanan darurat
  • Mengirimkan informasi sensitif melalui protokol jaringan yang tidak aman (misalnya, HTTP dan Bluetooth yang tidak terenkripsi) ketika pemohon mengharapkan transmisi yang aman. Perhatikan bahwa ini tidak berlaku untuk enkripsi Wi-Fi (seperti WEP)
  • Akses tidak sah terhadap data yang diamankan oleh TEE termasuk akses yang diaktifkan oleh kunci lemah di TEE
Sedang
  • Jalan pintas umum untuk pertahanan mendalam atau mengeksploitasi teknologi mitigasi dalam konteks istimewa, THB, atau kernel OS
  • Bypass umum untuk perlindungan sistem operasi yang mengungkapkan status proses atau metadata di seluruh batas aplikasi, pengguna, atau profil
  • Melewati enkripsi atau otentikasi Wi-Fi
  • Kerentanan kriptografi dalam kripto primitif standar yang memungkinkan kebocoran teks biasa (bukan primitif yang digunakan di TLS)
  • Akses lokal ke data yang dilindungi (yaitu data yang dibatasi pada konteks istimewa)
  • Eksekusi kode arbitrer lokal dalam konteks tanpa hak istimewa
  • Bypass lokal terhadap 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 memiliki hak istimewa
  • 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 yang salah
Dampak Keamanan yang Dapat Diabaikan (NSI​)
  • Kerentanan yang dampaknya telah dimitigasi oleh satu atau lebih pengubah peringkat atau perubahan arsitektur spesifik versi sedemikian rupa sehingga tingkat keparahan efektif berada di bawah Rendah, meskipun masalah kode yang mendasarinya mungkin tetap ada
  • Kerentanan apa pun yang memerlukan sistem file yang salah format, jika sistem file tersebut selalu diadopsi/dienkripsi sebelum digunakan.
  • Penolakan layanan lokal sementara , misalnya kondisi yang dapat diatasi dengan me-reboot perangkat atau mencopot pemasangan aplikasi yang memicu.

Pengubah peringkat

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

Alasan Memengaruhi
Memerlukan berjalan sebagai konteks istimewa untuk mengeksekusi serangan (tidak berlaku untuk TEE, SE, dan hypervisor seperti pKVM) -1 Tingkat Keparahan
Detail spesifik kerentanan membatasi dampak masalah ini -1 Tingkat Keparahan
Bypass otentikasi biometrik yang memerlukan informasi biometrik langsung dari pemilik perangkat -1 Tingkat Keparahan
Konfigurasi kompiler atau platform mengurangi kerentanan dalam kode sumber Tingkat Keparahan Sedang jika kerentanan yang mendasarinya adalah Sedang atau lebih tinggi
Memerlukan akses fisik ke internal perangkat dan masih dapat dilakukan jika perangkat mati atau belum dibuka kuncinya sejak dihidupkan -1 Tingkat Keparahan
Memerlukan akses fisik ke internal perangkat saat perangkat aktif dan sebelumnya telah dibuka kuncinya -2 Tingkat Keparahan
Serangan lokal yang mengharuskan rantai bootloader dibuka kuncinya Tidak lebih tinggi dari Rendah
Serangan lokal yang memerlukan Mode Pengembang atau pengaturan mode pengembang persisten 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 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 oleh browsing ke halaman web, membaca email, menerima pesan SMS, atau menghubungkan ke jaringan yang tidak bersahabat. Untuk tujuan penilaian tingkat keparahan, kami juga menganggap vektor serangan "proksimal" sebagai vektor serangan 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 formatnya salah. Kami menganggap serangan berbasis Ultra-wideband (UWB) dan NFC sebagai serangan proksimal dan oleh karena itu jarak jauh.

Serangan lokal mengharuskan korban untuk menjalankan aplikasi, baik dengan menginstal dan menjalankan aplikasi atau dengan menyetujui untuk menjalankan Aplikasi Instan . Perangkat pendamping yang dipasangkan akan dianggap sebagai perangkat lokal. Untuk tujuan penilaian tingkat keparahan, tim keamanan Android juga menganggap vektor serangan fisik bersifat 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 kabel USB untuk dicolokkan.

Keamanan jaringan

Android berasumsi bahwa semua jaringan bersifat bermusuhan dan dapat melakukan serangan atau memata-matai lalu lintas. Meskipun keamanan lapisan tautan (misalnya, enkripsi Wi-Fi) mengamankan komunikasi antara perangkat dan Titik Akses yang terhubung dengannya, keamanan ini 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 data 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

Otentikasi biometrik adalah bidang yang menantang, dan bahkan sistem terbaik pun bisa tertipu oleh kecocokan yang hampir sama (lihat Blog Pengembang Android: Layar kunci dan penyempurnaan autentikasi di Android 11 ). Peringkat tingkat keparahan ini membedakan dua kelas serangan dan dimaksudkan untuk mencerminkan risiko sebenarnya bagi pengguna akhir.

Serangan kelas satu memungkinkan melewati otentikasi biometrik dengan cara yang dapat digeneralisasikan, tanpa data biometrik berkualitas tinggi dari pemiliknya. Jika, misalnya, penyerang dapat menempelkan permen karet pada sensor sidik jari, dan hal tersebut memberikan akses ke perangkat berdasarkan residu yang tertinggal pada sensor, maka ini adalah serangan sederhana yang dapat dilakukan pada perangkat mana pun yang rentan. Itu tidak memerlukan pengetahuan apa pun dari pemilik perangkat. Mengingat serangan ini 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 diperoleh (misalnya, jika gambar profil seseorang di media sosial cukup untuk mengelabui autentikasi biometrik, maka bypass biometrik akan menerima peringkat tingkat keparahan penuh). Namun jika penyerang perlu memperoleh data biometrik langsung dari pemilik perangkat (misalnya, pemindaian inframerah pada wajahnya), hal tersebut merupakan penghalang yang cukup signifikan sehingga membatasi jumlah orang yang terkena dampak serangan tersebut, jadi terdapat pengubah -1 .

SYSTEM_ALERT_WINDOW dan Tapjacking

Untuk informasi tentang kebijakan kami mengenai SYSTEM_ALERT_WINDOW dan tapjacking, lihat bagian " Kerentanan Tapjacking/overlay SYSTEM_ALERT_WINDOW pada layar yang tidak kritis terhadap keamanan " di halaman Bugs tanpa dampak keamanan di Universitas BugHunter.

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 mengakomodasi kasus penggunaan seperti ini, pengguna secara default memiliki akses ke komponen penting yang diperlukan untuk menggunakan kendaraan, seperti pengaturan jaringan Wi-Fi dan seluler.

Komponen yang terkena dampak

Tim pengembangan yang bertanggung jawab untuk memperbaiki bug bergantung pada komponen mana yang berisi bug tersebut. Ini bisa 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 teknik Android. Bug dengan tingkat keparahan rendah, bug pada komponen tertentu, atau bug yang sudah diketahui publik dapat diperbaiki langsung di cabang utama AOSP yang tersedia untuk umum; jika tidak, mereka akan 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 perlu dilakukan oleh setiap OEM. Bug pada aplikasi atau pustaka yang dipublikasikan di Google Play (misalnya, Gmail, Layanan Google Play, atau WebView) dapat dikirimkan ke pengguna Android sebagai pembaruan dari Google Play.

Memberi tahu mitra

Ketika kerentanan keamanan di AOSP diperbaiki di Buletin Keamanan Android, kami akan memberi tahu mitra Android mengenai detail masalahnya dan memberikan patch. Daftar versi yang didukung backport berubah 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 diterapkan ke AOSP setelah OTA dirilis ke pengguna. Perbaikan untuk masalah dengan tingkat keparahan rendah dapat dikirimkan langsung ke cabang utama AOSP sebelum perbaikan tersedia untuk perangkat melalui OTA.

Menerima pembaruan Android

Pembaruan pada sistem Android umumnya dikirimkan ke perangkat melalui paket pembaruan OTA. Pembaruan ini mungkin berasal dari OEM yang memproduksi perangkat atau operator yang memberikan layanan pada perangkat tersebut. 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 memberikan 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 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 whitepaper. Lihat Laporan Keamanan untuk detail selengkapnya.