TL; DR. Pada artikel ini, kita mengeksplorasi skema pengerasan yang berhasil pada lima distribusi Linux populer. Untuk masing-masing paket, kami mengambil konfigurasi kernel default, memuat semua paket, dan menganalisis skema keamanan dalam biner terlampir. Distribusi yang dipertimbangkan adalah OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 dan 7, serta Ubuntu 14.04, 12.04 dan 18.04 LTS.

Hasilnya menegaskan bahwa bahkan skema dasar seperti susun kenari dan kode posisi-independen belum diadopsi oleh semua orang. Situasinya bahkan lebih buruk lagi bagi para penyusun dalam hal perlindungan terhadap kerentanan seperti bentrokan tumpukan, yang menjadi sorotan pada bulan Januari setelah publikasi. informasi tentang kerentanan systemd. Tapi tidak semuanya sia-sia. Sejumlah besar biner menerapkan metode perlindungan dasar, dan jumlahnya terus bertambah dari versi ke versi.

Tinjauan tersebut menunjukkan bahwa jumlah metode perlindungan terbesar diterapkan di Ubuntu 18.04 pada tingkat OS dan aplikasi, diikuti oleh Debian 9. Di sisi lain, OpenSUSE 12.4, CentOS 7 dan RHEL 7 juga menerapkan skema perlindungan dasar, dan perlindungan tabrakan tumpukan. digunakan lebih luas lagi dengan kumpulan paket default yang jauh lebih padat.

pengenalan

Sulit untuk memastikan perangkat lunak berkualitas tinggi. Meskipun terdapat banyak alat canggih untuk analisis kode statis dan analisis runtime dinamis, serta kemajuan signifikan dalam pengembangan kompiler dan bahasa pemrograman, perangkat lunak modern masih memiliki kerentanan yang terus-menerus dieksploitasi oleh penyerang. Situasinya bahkan lebih buruk lagi pada ekosistem yang menyertakan kode lama. Dalam kasus seperti ini, kita tidak hanya dihadapkan pada masalah abadi dalam menemukan kemungkinan kesalahan yang dapat dieksploitasi, namun kita juga dibatasi oleh kerangka kerja kompatibilitas mundur yang ketat, yang sering kali mengharuskan kita untuk mempertahankan kode yang terbatas, atau lebih buruk lagi, rentan atau bermasalah.

Di sinilah metode perlindungan atau penguatan program berperan. Kami tidak dapat mencegah beberapa jenis kesalahan, namun kami dapat mempersulit hidup penyerang dan menyelesaikan sebagian masalah dengan mencegah atau mencegahnya. Operasi kesalahan ini. Perlindungan semacam itu digunakan di semua sistem operasi modern, tetapi metodenya sangat berbeda dalam kompleksitas, efisiensi, dan kinerja: dari stack canaries dan ASLR untuk perlindungan penuh CFI и ROP. Pada artikel ini, kita akan melihat metode perlindungan apa yang digunakan di distribusi Linux paling populer dalam konfigurasi default, dan juga memeriksa properti biner yang didistribusikan melalui sistem manajemen paket setiap distribusi.

CVE dan keamanan

Kita semua pernah melihat artikel dengan judul seperti "Aplikasi Paling Rentan Tahun Ini" atau "Sistem Operasi Paling Rentan". Biasanya mereka memberikan statistik jumlah total catatan tentang kerentanan seperti CVE (Kerentanan dan Eksposur Umum), diperoleh dari Basis Data Kerentanan Nasional (NVD) dari NIST dan sumber lainnya. Selanjutnya, aplikasi atau OS ini diberi peringkat berdasarkan jumlah CVE. Sayangnya, meskipun CVE sangat berguna untuk melacak masalah dan memberi informasi kepada vendor dan pengguna, CVE tidak banyak menjelaskan tentang keamanan perangkat lunak yang sebenarnya.

Sebagai contoh, perhatikan jumlah total CVE selama empat tahun terakhir untuk kernel Linux dan lima distribusi server terpopuler, yaitu Ubuntu, Debian, Red Hat Enterprise Linux, dan OpenSUSE.

Gambar. 1

Apa yang disampaikan grafik ini kepada kita? Apakah jumlah CVE yang lebih tinggi berarti suatu distribusi lebih rentan dibandingkan distribusi lainnya? Tidak ada Jawaban. Misalnya, dalam artikel ini Anda akan melihat bahwa Debian memiliki mekanisme keamanan yang lebih kuat dibandingkan dengan, katakanlah, OpenSUSE atau RedHat Linux, namun Debian memiliki lebih banyak CVE. Namun, hal ini tidak selalu berarti melemahnya keamanan: bahkan kehadiran CVE tidak menunjukkan apakah suatu kerentanan memang demikian dieksploitasi. Skor tingkat keparahan memberikan indikasi bagaimana caranya mungkin eksploitasi kerentanan, namun pada akhirnya eksploitasi sangat bergantung pada perlindungan yang ada pada sistem yang terkena dampak serta sumber daya dan kemampuan penyerang. Selain itu, tidak adanya laporan CVE tidak menjelaskan apa pun tentang laporan lainnya tidak terdaftar atau tidak diketahui kerentanan. Perbedaan CVE mungkin disebabkan oleh faktor selain kualitas perangkat lunak, termasuk sumber daya yang dialokasikan untuk pengujian atau ukuran basis pengguna. Dalam contoh kita, jumlah CVE Debian yang lebih banyak mungkin mengindikasikan bahwa Debian mengirimkan lebih banyak paket perangkat lunak.

Tentu saja, sistem CVE memberikan informasi berguna yang memungkinkan Anda membuat perlindungan yang sesuai. Semakin baik kita memahami alasan kegagalan program, semakin mudah untuk mengidentifikasi kemungkinan metode eksploitasi dan mengembangkan mekanisme yang tepat deteksi dan respon. Pada Gambar. Gambar 2 menunjukkan kategori kerentanan untuk semua distribusi selama empat tahun terakhir (sumber). Jelas terlihat bahwa sebagian besar CVE masuk dalam kategori berikut: penolakan layanan (DoS), eksekusi kode, overflow, kerusakan memori, kebocoran informasi (eksfiltrasi) dan peningkatan hak istimewa. Meskipun banyak CVE yang dihitung berkali-kali dalam kategori yang berbeda, secara umum permasalahan yang sama tetap terjadi dari tahun ke tahun. Pada bagian artikel selanjutnya, kami akan mengevaluasi penggunaan berbagai skema perlindungan untuk mencegah eksploitasi kerentanan ini.

Gambar. 2

tugas

Pada artikel ini kami bermaksud menjawab pertanyaan-pertanyaan berikut:

• Apa keamanan dari berbagai distribusi Linux? Mekanisme perlindungan apa yang ada di kernel dan aplikasi ruang pengguna?
• Bagaimana penerapan mekanisme keamanan berubah seiring berjalannya waktu di seluruh distribusi?
• Berapa rata-rata ketergantungan paket dan perpustakaan untuk setiap distribusi?
• Perlindungan apa yang diterapkan untuk setiap biner?

Pemilihan distribusi

Ternyata sulit untuk menemukan statistik akurat mengenai instalasi distribusi, karena dalam banyak kasus, jumlah unduhan tidak menunjukkan jumlah instalasi sebenarnya. Namun, varian Unix merupakan mayoritas sistem server (pada server web 69,2%, sebesar statistik W3techs dan sumber lainnya), dan pangsa mereka terus bertambah. Oleh karena itu, untuk penelitian kami, kami fokus pada distribusi yang langsung tersedia di platform Google Cloud. Secara khusus, kami memilih OS berikut:

Distribusi/versi
Intinya
Membangun

OpenSUSE 12.4
4.12.14-95.3-standar
#1 SMP Rabu 5 Des 06:00:48 UTC 2018 (63a8d29)

Debian 9 (peregangan)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

6.10 CentOS
2.6.32-754.10.1.el6.x86_64
#1 SMP Sel 15 Jan 17:07:28 UTC 2019

7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP Jum 1 Februari 14:54:57 UTC 2019

Server Linux Red Hat Enterprise 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Rabu 21 November 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Kam 15 Nov 17:36:42 UTC 2018

Ubuntu 14.04 (Tahr yang Terpercaya)
4.4.0–140-generik

#166~14.04.1-Ubuntu SMP Sabtu 17 Nov 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Jum 7 Des 09:59:47 UTC 2018

Ubuntu 18.04 (Berang-berang Bionic)
4.15.0–1026-gcp
#27-Ubuntu SMP Kam 6 Des 18:27:01 UTC 2018

Tabel 1

analisis

Mari kita pelajari konfigurasi kernel default, serta properti paket yang tersedia melalui manajer paket setiap distribusi. Oleh karena itu, kami hanya mempertimbangkan paket dari mirror default masing-masing distribusi, mengabaikan paket dari repositori yang tidak stabil (seperti mirror 'pengujian' Debian) dan paket pihak ketiga (seperti paket Nvidia dari mirror standar). Selain itu, kami tidak mempertimbangkan kompilasi kernel khusus atau konfigurasi yang diperkuat keamanannya.

Analisis Konfigurasi Kernel

Kami menerapkan skrip analisis berdasarkan pemeriksa kconfig gratis. Mari kita lihat parameter perlindungan out-of-the-box dari distribusi bernama dan bandingkan dengan daftar dari Proyek Bela Diri Inti (KSPP). Untuk setiap pilihan konfigurasi, Tabel 2 menjelaskan pengaturan yang diinginkan: kotak centang untuk distribusi yang sesuai dengan rekomendasi KSSP (lihat penjelasan istilah berikut). di sini; Di artikel mendatang kami akan menjelaskan berapa banyak metode keamanan ini yang muncul dan cara meretas sistem jika metode tersebut tidak ada).

Secara umum, kernel baru memiliki pengaturan yang lebih ketat. Misalnya, CentOS 6.10 dan RHEL 6.10 pada kernel 2.6.32 tidak memiliki sebagian besar fitur penting yang diterapkan pada kernel baru seperti SMAP, izin RWX yang ketat, pengacakan alamat, atau perlindungan copy2usr. Perlu dicatat bahwa banyak opsi konfigurasi dalam tabel tidak tersedia di versi kernel yang lebih lama dan tidak dapat diterapkan pada kenyataannya - hal ini masih ditunjukkan dalam tabel sebagai kurangnya perlindungan yang tepat. Demikian pula, jika opsi konfigurasi tidak ada dalam versi tertentu, dan keamanan mengharuskan opsi tersebut dinonaktifkan, ini dianggap sebagai konfigurasi yang wajar.

Hal lain yang perlu dipertimbangkan ketika menafsirkan hasil: beberapa konfigurasi kernel yang meningkatkan permukaan serangan juga dapat digunakan untuk keamanan. Contohnya termasuk uprobe dan kprobe, modul kernel, dan BPF/eBPF. Rekomendasi kami adalah menggunakan mekanisme di atas untuk memberikan perlindungan yang nyata, karena mekanisme tersebut tidak mudah digunakan dan eksploitasinya mengasumsikan bahwa pelaku kejahatan telah memiliki pijakan dalam sistem. Namun jika opsi ini diaktifkan, administrator sistem harus secara aktif memantau penyalahgunaan.

Melihat lebih jauh entri pada Tabel 2, kita melihat bahwa kernel modern menyediakan beberapa opsi untuk melindungi terhadap eksploitasi kerentanan seperti kebocoran informasi dan stack/heap overflows. Namun, kami melihat bahwa distribusi populer terbaru pun belum menerapkan perlindungan yang lebih kompleks (misalnya, dengan patch keamanan) atau perlindungan modern terhadap serangan penggunaan kembali kode (mis. kombinasi pengacakan dengan skema seperti R^X untuk kode). Lebih buruk lagi, bahkan pertahanan yang lebih canggih ini tidak mampu melindungi terhadap berbagai serangan. Oleh karena itu, sangat penting bagi administrator sistem untuk melengkapi konfigurasi cerdas dengan solusi yang menawarkan deteksi dan pencegahan eksploitasi runtime.

Analisis Aplikasi

Tidak mengherankan, distribusi yang berbeda memiliki karakteristik paket, opsi kompilasi, ketergantungan perpustakaan, dll yang berbeda. Bahkan ada perbedaan terkait distribusi dan paket dengan sedikit dependensi (misalnya, coreutils di Ubuntu atau Debian). Untuk mengevaluasi perbedaannya, kami mengunduh semua paket yang tersedia, mengekstraksi isinya, dan menganalisis biner dan dependensi. Untuk setiap paket, kami melacak paket-paket lain yang bergantung padanya, dan untuk setiap biner, kami melacak ketergantungannya. Pada bagian ini kami merangkum secara singkat kesimpulannya.

distribusi

Secara total, kami mengunduh 361 paket untuk semua distribusi, hanya mengekstraksi paket dari mirror default. Kami mengabaikan paket tanpa executable ELF, seperti sumber, font, dll. Setelah pemfilteran, tersisa 556 paket, berisi total 129 biner. Distribusi paket dan file di seluruh distribusi ditunjukkan pada Gambar. 569.

Gambar. 3

Anda mungkin memperhatikan bahwa semakin modern distribusinya, semakin banyak paket dan biner yang dikandungnya, dan ini logis. Namun, paket Ubuntu dan Debian menyertakan lebih banyak biner (baik modul dan perpustakaan yang dapat dieksekusi dan dinamis) daripada CentOS, SUSE dan RHEL, yang berpotensi mempengaruhi permukaan serangan Ubuntu dan Debian (perlu dicatat bahwa angka-angka tersebut mencerminkan semua biner dari semua versi paket, yaitu beberapa file dianalisis beberapa kali). Hal ini sangat penting ketika Anda mempertimbangkan ketergantungan antar paket. Oleh karena itu, kerentanan dalam satu paket biner dapat memengaruhi banyak bagian ekosistem, seperti halnya perpustakaan yang rentan dapat memengaruhi semua biner yang mengimpornya. Sebagai titik awal, mari kita lihat distribusi jumlah dependensi antar paket di sistem operasi yang berbeda:

Gambar. 4

Di hampir semua distribusi, 60% paket memiliki setidaknya 10 dependensi. Selain itu, beberapa paket memiliki jumlah ketergantungan yang jauh lebih besar (lebih dari 100). Hal yang sama berlaku untuk ketergantungan paket terbalik: seperti yang diharapkan, beberapa paket digunakan oleh banyak paket lain dalam distribusi, sehingga kerentanan pada beberapa paket tertentu memiliki risiko tinggi. Sebagai contoh, tabel berikut mencantumkan 20 paket dengan jumlah maksimum dependensi terbalik di SLES, Centos 7, Debian 9, dan Ubuntu 18.04 (setiap sel menunjukkan paket dan jumlah dependensi terbalik).

Tabel 3

Fakta yang menarik. Meskipun semua OS yang dianalisis dibuat untuk arsitektur x86_64, dan sebagian besar paket memiliki arsitektur yang didefinisikan sebagai x86_64 dan x86, paket sering kali berisi binari untuk arsitektur lain, seperti yang ditunjukkan pada Gambar 5. XNUMX.

Gambar. 5

Pada bagian selanjutnya, kita akan mempelajari karakteristik biner yang dianalisis.

Statistik perlindungan file biner

Minimal, Anda perlu menjelajahi serangkaian opsi keamanan dasar untuk biner yang ada. Beberapa distribusi Linux dilengkapi dengan skrip yang melakukan pemeriksaan tersebut. Misalnya, Debian/Ubuntu memiliki skrip seperti itu. Berikut ini contoh karyanya:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

Script memeriksa lima fungsi perlindungan:

• Position Independent Executable (PIE): Menunjukkan apakah bagian teks suatu program dapat dipindahkan dalam memori untuk mencapai pengacakan jika ASLR diaktifkan di kernel.
• Stack Protected: Apakah stack canary diaktifkan untuk melindungi dari serangan tabrakan tumpukan.
• Fortify Source: apakah fungsi yang tidak aman (misalnya, strcpy) diganti dengan fungsi yang lebih aman, dan panggilan yang dicentang saat runtime diganti dengan fungsi yang tidak dicentang (misalnya, memcpy, bukan __memcpy_chk).
• Relokasi baca-saja (RELRO): Apakah entri tabel relokasi ditandai hanya-baca jika dipicu sebelum eksekusi dimulai.
• Pengikatan segera: Apakah runtime linker mengizinkan semua pergerakan sebelum eksekusi program dimulai (ini setara dengan RELRO penuh).

Apakah mekanisme di atas cukup? Sayangnya tidak ada. Ada cara yang diketahui untuk melewati semua pertahanan di atas, tetapi semakin kuat pertahanannya, semakin tinggi batasan bagi penyerang. Misalnya, Metode bypass RELRO lebih sulit untuk diterapkan jika PIE dan pengikatan segera berlaku. Demikian pula, ASLR penuh memerlukan kerja tambahan untuk membuat eksploitasi yang berfungsi. Namun, penyerang yang canggih sudah siap untuk memenuhi perlindungan tersebut: ketidakhadiran mereka akan mempercepat peretasan. Oleh karena itu, langkah-langkah ini dianggap perlu minimum.

Kami ingin mempelajari berapa banyak file biner dalam distribusi tersebut yang dilindungi oleh metode ini dan tiga metode lainnya:

• Bit yang tidak dapat dieksekusi (NX) mencegah eksekusi di wilayah mana pun yang tidak boleh dieksekusi, seperti tumpukan tumpukan, dll.
• RPATH/JALAN JALAN menunjukkan jalur eksekusi yang digunakan oleh pemuat dinamis untuk menemukan perpustakaan yang cocok. Yang pertama adalah wajib untuk sistem modern mana pun: ketidakhadirannya memungkinkan penyerang untuk secara sewenang-wenang menulis payload ke dalam memori dan mengeksekusinya sebagaimana adanya. Yang kedua, konfigurasi jalur eksekusi yang salah membantu memasukkan kode yang tidak dapat diandalkan yang dapat menyebabkan sejumlah masalah (mis. peningkatan hak istimewaDan masalah lain).
• Perlindungan tabrakan tumpukan memberikan perlindungan terhadap serangan yang menyebabkan tumpukan tumpang tindih dengan area memori lainnya (seperti heap). Mengingat penyalahgunaan eksploitasi baru-baru ini kerentanan tabrakan tumpukan systemd, kami merasa pantas untuk memasukkan mekanisme ini ke dalam kumpulan data kami.

Jadi, tanpa basa-basi lagi, mari kita langsung ke angka-angkanya. Tabel 4 dan 5 masing-masing berisi ringkasan analisis file yang dapat dieksekusi dan pustaka dari berbagai distribusi.

• Seperti yang Anda lihat, perlindungan NX diterapkan di mana saja, dengan pengecualian yang jarang terjadi. Secara khusus, kita dapat mencatat penggunaannya sedikit lebih rendah di distribusi Ubuntu dan Debian dibandingkan dengan CentOS, RHEL dan OpenSUSE.
• Stack canary hilang di banyak tempat, terutama di distribusi dengan kernel yang lebih lama. Beberapa kemajuan terlihat pada distribusi terbaru Centos, RHEL, Debian dan Ubuntu.
• Kecuali Debian dan Ubuntu 18.04, sebagian besar distribusi memiliki dukungan PIE yang buruk.
• Perlindungan tabrakan tumpukan lemah di OpenSUSE, Centos 7 dan RHEL 7, dan hampir tidak ada di yang lain.
• Semua distribusi dengan kernel modern memiliki dukungan untuk RELRO, dengan Ubuntu 18.04 memimpin dan Debian berada di urutan kedua.

Seperti yang telah disebutkan, metrik dalam tabel ini adalah rata-rata untuk semua versi file biner. Jika Anda hanya melihat file versi terbaru, jumlahnya akan berbeda (misalnya, lihat Kemajuan Debian dengan implementasi PIE). Selain itu, sebagian besar distribusi biasanya hanya menguji keamanan beberapa fungsi dalam biner saat menghitung statistik, namun analisis kami menunjukkan persentase sebenarnya dari fungsi yang diperkeras. Oleh karena itu, jika 5 dari 50 fungsi dilindungi dalam biner, kami akan memberikan skor 0,1, yang setara dengan 10% dari fungsi yang diperkuat.

Tabel 4. Karakteristik keamanan untuk file yang dapat dieksekusi ditunjukkan pada Gambar. 3 (implementasi fungsi yang relevan sebagai persentase dari jumlah total file yang dapat dieksekusi)

Tabel 5. Karakteristik keamanan perpustakaan ditunjukkan pada Gambar. 3 (implementasi fungsi-fungsi yang relevan sebagai persentase dari jumlah total perpustakaan)

Jadi, apakah ada kemajuan? Pasti ada: hal ini dapat dilihat dari statistik distribusi individu (misalnya, Debian), serta dari tabel di atas. Sebagai contoh pada Gambar. Gambar 6 menunjukkan implementasi mekanisme perlindungan di tiga distribusi Ubuntu LTS 5 yang berurutan (kami telah menghilangkan statistik perlindungan tabrakan tumpukan). Kami memperhatikan bahwa dari versi ke versi semakin banyak file yang mendukung stack canaries, dan juga semakin banyak biner yang dikirimkan dengan perlindungan RELRO penuh.

Gambar. 6

Sayangnya, sejumlah file yang dapat dieksekusi di distribusi berbeda masih belum memiliki perlindungan di atas. Misalnya, ketika melihat Ubuntu 18.04, Anda akan melihat biner ngetty (pengganti getty), serta shell mksh dan lksh, interpreter picolisp, paket nvidia-cuda-toolkit (paket populer untuk aplikasi akselerasi GPU seperti kerangka pembelajaran mesin), dan klibc -utils. Demikian pula, biner mandos-client (alat administratif yang memungkinkan Anda me-reboot mesin secara otomatis dengan sistem file terenkripsi) serta rsh-redone-client (implementasi ulang rsh dan rlogin) dikirimkan tanpa perlindungan NX, meskipun mereka memiliki hak SUID : (. Selain itu, beberapa biner suid tidak memiliki perlindungan dasar seperti stack canaries (misalnya, biner Xorg.wrap dari paket Xorg).

Ringkasan dan Catatan Penutup

Pada artikel ini, kami telah menyoroti beberapa fitur keamanan distribusi Linux modern. Analisis menunjukkan bahwa distribusi Ubuntu LTS terbaru (18.04) mengimplementasikan, rata-rata, perlindungan tingkat OS dan aplikasi terkuat di antara distribusi dengan kernel yang relatif baru, seperti Ubuntu 14.04, 12.04 dan Debian 9. Namun, distribusi yang diperiksa CentOS, RHEL dan OpenSUSE di set kami secara default menghasilkan kumpulan paket yang lebih padat, dan di versi terbaru (CentOS dan RHEL) mereka memiliki persentase perlindungan tabrakan tumpukan yang lebih tinggi dibandingkan dengan pesaing berbasis Debian (Debian dan Ubuntu). Membandingkan versi CentOS dan RedHat, kami melihat peningkatan besar dalam implementasi stack canaries dan RELRO dari versi 6 hingga 7, namun rata-rata CentOS memiliki lebih banyak fitur yang diimplementasikan daripada RHEL. Secara umum, semua distribusi harus memberikan perhatian khusus pada perlindungan PIE, yang, kecuali Debian 9 dan Ubuntu 18.04, diterapkan di kurang dari 10% biner dalam kumpulan data kami.

Terakhir, perlu dicatat bahwa meskipun kami melakukan penelitian secara manual, ada banyak alat keamanan yang tersedia (mis. Lynis, Harimau, Hubble), yang melakukan analisis dan membantu menghindari konfigurasi yang tidak aman. Sayangnya, bahkan perlindungan yang kuat dalam konfigurasi yang wajar tidak menjamin tidak adanya eksploitasi. Itu sebabnya kami sangat yakin bahwa hal ini penting untuk dipastikan pemantauan dan pencegahan serangan yang andal secara real time, dengan fokus pada pola eksploitasi dan pencegahannya.

Sumber: www.habr.com