Kami melakukan segalanya untuk menjaga platform Android tetap aman untuk semua pengguna di semua perangkat. Pembaruan keamanan dirilis setiap bulan dengan perbaikan untuk kerentanan yang ditemukan oleh anggota Vulnerability Rewards Program (VRP) . Namun, kami juga mencoba melindungi platform dari potensi kerentanan lainnya, misalnya dengan menggunakan kompiler dan meningkatkan lingkungan pengujian. Ekosistem Android mencakup perangkat dengan berbagai macam kemampuan, sehingga semua keputusan harus seimbang dan harus memperhitungkan data yang tersedia.
Artikel ini menjelaskan cara kami memilih kontrol keamanan untuk keadaan tertentu dan cara penerapannya.
Menjaga keamanan Android membutuhkan pendekatan holistik. Untuk mempersulit potensi kerentanan dieksploitasi, kami membuat keputusan berdasarkan data menggunakan berbagai prinsip dan teknik. Dalam hal pengerasan platform, pertanyaan-pertanyaan berikut perlu dijawab:
- Data apa yang kita miliki dan bagaimana mereka dapat membantu kita membuat keputusan?
- Alat pencegahan serangan apa yang tersedia? Bagaimana cara memperbaikinya? Dalam situasi apa mereka harus diterapkan?
- Masalah apa yang bisa muncul saat menggunakan alat keamanan tertentu? Tata letak apa yang mungkin harus dipertimbangkan?
Prinsip yang kami gunakan dalam pilihan keamanan kami mencerminkan pendekatan keseluruhan kami untuk melindungi pengguna platform Android.
Buat keputusan keamanan berdasarkan data
Untuk mengetahui komponen platform mana solusi tertentu akan efektif, kami beralih ke berbagai sumber. The Kerentanan Android Imbalan Program (VRP) mungkin adalah informatif sebagian besar dari mereka semua. Teknisi keamanan kami menganalisis semua kerentanan yang ditemukan oleh peserta program, menentukan akar penyebab dan tingkat keparahan mereka (berdasarkan rekomendasi ini ). Selain itu, ada laporan bug internal dan eksternal. Mereka membantu mengidentifikasi komponen yang rentan serta cuplikan kode yang sering menyebabkan kegagalan. Mengetahui seperti apa bentuk fragmen tersebut dan memahami tingkat keparahan dan frekuensi kesalahan yang diakibatkannya, kami dapat membuat keputusan berdasarkan informasi tentang tindakan keamanan mana yang paling efektif.
Kerentanan Tingkat Keparahan Tinggi dan Kritis yang Diperbaiki di Buletin Keamanan Android 2019.
Namun, jangan hanya mengandalkan laporan kerentanan. Mereka awalnya memberikan gambaran yang terdistorsi, karena profesional keamanan sering memperhatikan zona "panas", yaitu area di mana kerentanan telah ditemukan (misalnya, Stagefright ). Atau, mereka dapat mencari kerentanan yang lebih mudah dideteksi menggunakan solusi yang siap pakai. Misalnya, jika alat analisis keamanan diterbitkan di platform GitHub, banyak profesional yang akan menggunakannya.
Kami mencoba mendistribusikan upaya kami untuk meningkatkan keamanan secara merata. Tim kami memperhatikan komponen platform yang kurang dieksplorasi dan lebih kompleks. Selain itu, pengujian fuzzing otomatis terus dilakukan pada mesin virtual dan perangkat Android fisik, yang memungkinkan Anda menemukan dan memperbaiki bug di tahap pengembangan paling awal. Saat memutuskan alat mana yang akan digunakan, kami juga menganalisis akar penyebab dan tingkat keparahan masalah yang kami temukan.
Sebagai bagian dari program Android VRP, kami mendorong pengembang untuk menambahkan rantai kerentanan penuhmemungkinkan Anda melacak seluruh proses serangan dari awal hingga akhir. Biasanya, penjahat dunia maya mengeksploitasi beberapa kerentanan sekaligus, dan dalam rantai seperti itu "bundel" ini terlihat jelas, jadi sangat informatif. Teknisi keamanan kami menganalisis seluruh rantai dan tautan individualnya serta mencoba menemukan strategi serangan baru di dalamnya. Analisis ini membantu menentukan strategi untuk membantu mencegah eksploitasi kerentanan secara berurutan (misalnya, alokasi ruang alamat acak dan metode Integritas Aliran Kontrol ), dan juga memahami apakah serangan dapat dikurangi jika proses mendapatkan akses yang tidak diinginkan ke sumber daya.
Jelas, beberapa kerentanan dapat dimasukkan ke dalam beberapa rantai sekaligus dan berada dalam urutan yang berbeda. Oleh karena itu, lebih baik menggunakan "pertahanan mendalam", mengurangi efektivitas kerentanan individu dan memperpanjang rantai eksploitasi. Dalam kasus ini, akan lebih sulit bagi penyerang untuk membangun rantai yang efektif dan melakukan serangan.
Untuk memahami ancaman keamanan saat ini dan memprediksi tren masa depan, Anda harus terus memantau komunitas keamanan, khususnya:
- bekerja sama dengan pakar keamanan pihak ketiga;
- membaca publikasi tematik dan menghadiri konferensi;
- mempelajari teknologi yang digunakan oleh malware;
- melacak perkembangan terbaru di bidang keamanan;
- berpartisipasi dalam proyek sampingan seperti KSPP , syzbot, LLVM, Rust, dll.
Hasilnya, Anda akan memiliki pemahaman yang lebih baik tentang strategi keamanan Anda secara keseluruhan, keefektifan solusi yang ada, dan peluang untuk peningkatan.
Mengapa perlindungan yang lebih kuat diperlukan
Memperkuat perlindungan dan mencegah serangan
Menganalisis data membantu mengidentifikasi area di mana mitigasi serangan yang efektif dapat mengatasi seluruh kelas kerentanan. Misalnya, jika beberapa komponen platform mengembangkan banyak kerentanan karena kesalahan bilangan bulat overflow, Anda harus menggunakan pembersih perilaku yang tidak ditentukan ( UBSan ), seperti Integer Overflow Sanitizer. Jika kerentanan akses memori umum terjadi, Anda harus menggunakan pengalokasi memori yang diperkuat ( diaktifkan secara default di Android 11 ) dan alat pencegahan serangan (seperti Control Flow Integrity ) yang tahan terhadap luapan memori dan kerentanan Gunakan-Setelah. Gratis.
Sebelum kita berbicara tentang penggunaan data, kami mengusulkan klasifikasi alat untuk memperkuat keamanan platform. Berikut adalah segmen utama tempat semua alat ini dapat dipecah (meskipun beberapa alat dan metode mungkin berlaku untuk beberapa di antaranya sekaligus):
- Manfaatkan alat eliminasi
- Alat remediasi runtime deterministik mendeteksi perilaku yang tidak ditentukan atau tidak diinginkan dan mengganggu eksekusi program. Ini menghilangkan kerusakan data dalam memori, sambil mempertahankan kemungkinan hanya kegagalan kecil. Seringkali alat semacam itu dapat diterapkan secara tepat, dan alat tersebut masih akan efektif, karena dirancang untuk kesalahan individu. Contoh: integer overflow sanitizer dan BoundsSanitizer .
- . . . . , . : , Control Flow Integrity (CFI), , .
- , . , . : .
-
- . , . , .
Bergantung pada masalah spesifiknya, kami memutuskan alat yang dijelaskan mana yang harus digunakan dan bagaimana. Misalnya, masing-masing cocok jika kita berurusan dengan proses besar yang melibatkan pemrosesan data yang tidak dapat diandalkan dan penguraian yang kompleks. Platform multimedia telah menjadi demonstrasi hebat tentang bagaimana dekomposisi arsitektur dapat digunakan untuk mengurangi eksploitasi secara lebih efektif dan mencegah peningkatan hak istimewa.
Dekomposisi arsitektur dan isolasi kerangka media dalam konteks sejarah
Target serangan jarak jauh (NFC, Bluetooth, Wi-Fi, dan konten media) secara tradisional dikaitkan dengan kerentanan paling serius, sehingga memperkuat keamanan mereka harus menjadi prioritas. Biasanya, kerentanan ini disebabkan oleh akar penyebab paling umum yang ditemukan di program VRP, dan kami baru-baru ini menambahkan pembersih untuk semuanya.
Alat pencegahan serangan berguna untuk perpustakaan dan proses yang mengatur atau berada dalam batas keamanan (misalnya, libbinder , serta perpustakaan standar libui , libcore, dan libcutils.), karena tidak terikat pada proses tertentu. Namun, pustaka ini bertanggung jawab atas operasi sistem yang efisien dan stabil, jadi sebelum menggunakan metode tertentu, Anda memerlukan jaminan serius bahwa itu akan meningkatkan keamanan.
Terakhir, penting untuk melindungi kernel, mengingat tingkat hak istimewanya yang tinggi. Semua basis kode memiliki karakteristik dan fungsionalitas yang berbeda, sehingga kemungkinan kerentanan di dalamnya juga berbeda. Kriteria utama di sini adalah stabilitas dan kinerja. Gunakan hanya langkah-langkah keamanan efektif yang tidak akan mengganggu pekerjaan pengguna. Oleh karena itu, sebelum memilih strategi optimal untuk perlindungan pengerasan, kami menganalisis dengan cermat semua data yang tersedia terkait dengan kernel.
Pendekatan berbasis data telah membuahkan hasil yang nyata. Setelah kerentanan Stagefright ditemukan pada tahun 2015, kami mulai menerima laporan tentang sejumlah besar kerentanan kritis lainnya di platform media Android. Untuk memperumit masalah, banyak dari mereka dapat diakses dari jarak jauh. Kami telah melakukan dekomposisi besar - besaran pada sistem Android Nougat dan mempercepat perbaikan kerentanan pada komponen multimedia . Berkat perubahan tersebut, pada tahun 2020 tidak ada laporan kerentanan kritis pada platform multimedia yang dapat diakses melalui Internet.
Bagaimana keputusan penerapan dibuat
Secara alami, masuk akal untuk fokus pada alat pencegahan serangan yang bekerja paling baik. Untuk mengidentifikasinya, kami melihat bagaimana setiap alat memengaruhi kinerja, berapa banyak pekerjaan yang diperlukan untuk menyebarkan dan mendukungnya, dan apakah itu akan berdampak negatif pada stabilitas sistem.
Performa
Saat memilih alat pencegahan serangan, Anda perlu memahami bagaimana pengaruhnya terhadap kinerja perangkat. Jika beberapa komponen atau sistem secara keseluruhan tidak dapat menangani beban, masa pakai baterai dan kinerja keseluruhan dapat berkurang. Hal ini terutama berlaku untuk perangkat level awal yang juga membutuhkan peningkatan keamanan. Karenanya, kami mengutamakan solusi paling efektif yang tidak memengaruhi kinerja perangkat.
Saat mengevaluasi kinerja, kami memperhatikan tidak hanya waktu prosesor, tetapi juga penggunaan memori, panjang kode, masa pakai baterai, dan kasus pembekuan antarmuka.... Untuk memastikan bahwa suatu alat berperforma baik di seluruh ekosistem Android, sangat penting untuk menguji parameter yang terdaftar di perangkat level awal.
Sangat penting untuk komponen mana tindakan perlindungan diterapkan. Misalnya, penjilidan paling sering digunakan untuk komunikasi antarproses. Oleh karena itu, beban berlebih apa pun akan langsung memengaruhi pengoperasian perangkat. Dalam kasus pemutar media yang hanya memproses bingkai pada kecepatan aslinya, situasinya berbeda. Jika kecepatan video jauh lebih tinggi dari kecepatan tampilan, beban tambahan tidak akan terlalu penting.
Kami menggunakan tolok ukur untuk menentukan dampak kinerja dari solusi tertentu. Jika tidak ada hasil benchmark untuk sebuah komponen, Anda perlu mendapatkannya, misalnya, dengan memanggil codec yang terpengaruh untuk mendekode file media. Jika pengujian menunjukkan beban yang tidak dapat diterima, ada beberapa opsi:
- Nonaktifkan pencegahan serangan secara selektif untuk fitur yang berdampak signifikan pada kinerja. Biasanya, hanya beberapa fungsi yang menggunakan resource pada waktu proses. Dengan tidak menerapkan mitigasi serangan kepada mereka, Anda dapat mempertahankan kinerja dan memaksimalkan dampak keamanan Anda. Berikut adalah contoh pendekatan ini untuk salah satu codec media. Untuk menghilangkan risiko, fungsi yang disebutkan harus diperiksa kesalahannya terlebih dahulu.
- Mengoptimalkan penggunaan pencegahan serangan. Seringkali ini membutuhkan perubahan pada kompiler. Misalnya, tim kami beralih menggunakan Integer Overflow Sanitizer dan Bounds Sanitizer.
- Beberapa opsi mitigasi serangan, seperti ketahanan heap bawaan Scudo, dapat disetel untuk meningkatkan kinerja.
Banyak dari peningkatan ini memerlukan perubahan pada desain LLVM. Hasilnya, tidak hanya platform Android yang menang, tetapi juga anggota komunitas LLVM lainnya.
Penerapan dan dukungan
Saat memilih alat pencegahan serangan, Anda tidak hanya perlu mempertimbangkan pertimbangan keamanan dan kinerja, tetapi juga biaya penyebaran dan dukungan jangka panjang.
Dampak tindakan keamanan pada operasi sistem yang stabil
Penting untuk dipahami apakah mungkin memicu alat pencegahan serangan tertentu secara tidak benar. Misalnya, jika Bounds sanitizer membuat kesalahan, itu pasti akses yang ditolak (meskipun mungkin tidak digunakan). Dalam kasus pembersih Integer Overflow, positif palsu dimungkinkan, karena overflow integer seringkali merupakan proses yang benar-benar normal dan tidak berbahaya.
Oleh karena itu, penting untuk mempertimbangkan dampak alat pencegahan serangan terhadap stabilitas sistem. Tidak masalah jika ada positif palsu atau ada ancaman keamanan nyata - bagaimanapun, pengguna mengalami ketidaknyamanan. Di sini sekali lagi, kami mencatat bahwa perlu untuk memahami dengan jelas untuk komponen mana satu atau beberapa tindakan keamanan lainnya harus digunakan. Karena kegagalan pada beberapa komponen berdampak lebih besar pada kestabilan sistem. Jika Pencegahan Serangan merusak codec media, video hanya akan berhenti diputar. Namun, jika terjadi kesalahan dalam prosesnya
netd
saat menginstal pembaruan, perangkat mungkin tidak lagi menyala. Meskipun positif palsu tidak menyebabkan masalah untuk beberapa alat anti-serangan (misalnya, seperti halnya dengan pembersih Bounds), kami masih melakukan pengujian ekstensif untuk memastikan bahwa perangkat tersebut stabil. Misalnya, kesalahan bias oleh satu orang mungkin tidak crash secara normal, dan Bounds sanitizer mengganggu proses dan mengganggu stabilitas sistem.
Penting juga untuk memahami apakah mungkin untuk mengidentifikasi terlebih dahulu semua komponen yang dapat dinonaktifkan oleh alat pencegahan serangan. Misalnya, dalam kasus Integer Overflow sanitizer, sangat sulit untuk memprediksi risiko tanpa melakukan pengujian ekstensif, karena sulit untuk menentukan luapan integer mana yang disengaja (diizinkan) dan mana yang dapat menyebabkan kerentanan.
Dukung
Penting untuk mempertimbangkan tidak hanya masalah yang mungkin terjadi dalam penyebaran alat pencegahan serangan, tetapi juga spesifikasi dukungan mereka dalam jangka panjang. Kami memperkirakan waktu yang diperlukan untuk mengintegrasikan alat dengan sistem yang ada, mengaktifkan dan men-debugnya, menerapkannya ke perangkat, lalu melakukan servis setelah peluncuran. Teknologi SELinux adalah contoh yang bagus. Butuh banyak waktu dan tenaga untuk membuat seperangkat aturan. Dan set ini perlu dipertahankan selama bertahun-tahun, terlepas dari perubahan kode, serta penambahan atau penghapusan fitur individu.
Kami berusaha keras untuk memastikan bahwa alat pencegahan serangan berdampak minimal pada stabilitas dan bahwa pengembang memiliki semua informasi yang mereka butuhkan. Untuk mencapai tujuan ini, kami menyempurnakan algoritme kami saat ini untuk mengurangi jumlah positif palsu, dan kami memublikasikan dokumentasi di source.android.com . Dengan mempermudah proses debug jika terjadi kegagalan, Anda dapat mengurangi beban pemeliharaan pada pengembang. Misalnya, untuk mempermudah menemukan bug di pembersih UBSan, kami telah menambahkan dukungan waktu proses minimum UBSan ke sistem build Android secara default. Awalnya waktu eksekusi minimum ditambahkan pengembang Google lainnya khusus untuk tujuan ini. Jika program macet karena pembersih Integer Overflow, potongan berikut ditambahkan ke pesan kesalahan SIGABRT:
Abort message: 'ubsan: sub-overflow'
Setelah melihat pesan ini, pengembang akan memahami bahwa perlu mengaktifkan mode diagnostik untuk mencetak informasi tentang kegagalan:
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:2188:32: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
Pada saat yang sama, SELinux memiliki alat audit2allow yang memungkinkan Anda mengusulkan aturan yang memungkinkan operasi tertentu yang diblokir:
adb logcat -d | audit2allow -p policy
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };
Meskipun audit2allow mungkin tidak selalu menyarankan opsi yang tepat, ini sangat membantu pengembang yang baru mengenal SELinux.
Kesimpulan
Dengan setiap rilis Android, kami menghadirkan alat baru yang melindungi seluruh ekosistem, memastikan kinerja dan stabilitas yang Anda butuhkan. Analisis data memainkan peran penting dalam hal ini. Kami harap artikel ini membantu Anda lebih memahami tantangan dalam menerapkan alat pencegahan serangan baru dan cara kami menanganinya.
Terima kasih kepada kolega dan penulis kami: Kevin Deus, Joel Galenson, Billy Lau, Ivan Lozano - Pakar keamanan dan privasi Android. Terima kasih khusus kepada Zviad Kardava dan Jeff Van Der Stup atas bantuannya dalam mempersiapkan artikel ini.