TL; DR . Pada artikel ini, kami mengeksplorasi skema pengerasan yang bekerja di luar kotak pada lima distribusi Linux populer. Untuk masing-masing, kami mengambil konfigurasi kernel default, mengunduh semua paket, dan menganalisis skema perlindungan dalam file biner yang dilampirkan. Kami mempertimbangkan distribusi OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 dan 7, serta Ubuntu 14.04, 12.04 dan 18.04 LTS.

Hasilnya mengkonfirmasi bahwa skema dasar, seperti stack canaries dan code-independent code, belum digunakan oleh semua orang. Situasi ini bahkan lebih buruk bagi penyusun ketika datang untuk melindungi terhadap kerentanan seperti tumpukan bentrokan, yang menjadi sorotan pada bulan Januari setelah menerbitkan informasi kerentanan di systemd . Tapi tidak semuanya sia-sia. Di sebagian besar binari, metode perlindungan dasar diterapkan, dan jumlahnya bertambah dari versi ke versi.

Verifikasi menunjukkan bahwa jumlah terbesar metode perlindungan diimplementasikan di Ubuntu 18,04 di tingkat OS dan aplikasi, diikuti oleh Debian 9. Di sisi lain, di OpenSUSE 12.4, CentOS 7 dan RHEL 7, skema perlindungan dasar juga diterapkan, dan perlindungan benturan tumpukan diterapkan bahkan lebih luas. dengan paket yang jauh lebih padat secara default.

Pendahuluan

Sulit untuk menyediakan perangkat lunak berkualitas tinggi. Terlepas dari sejumlah besar alat canggih untuk analisis kode statis dan analisis dinamis saat runtime, serta kemajuan yang signifikan dalam pengembangan kompiler dan bahasa pemrograman, perangkat lunak modern masih mengalami kerentanan yang terus-menerus dieksploitasi oleh penjahat cyber. Situasinya bahkan lebih buruk di ekosistem yang memasukkan kode warisan. Dalam kasus seperti itu, kita tidak hanya menghadapi masalah abadi dalam mencari kemungkinan kesalahan yang dieksploitasi, tetapi juga dibatasi oleh kerangka kompatibilitas mundur yang kaku, yang seringkali membutuhkan pemeliharaan kode yang terbatas, dan bahkan lebih buruk lagi, rentan atau bermasalah.

Di sinilah metode pengerasan ikut berperan. Kami tidak dapat mencegah beberapa jenis kesalahan, tetapi kami dapat mempersulit kehidupan penyerang dan menyelesaikan sebagian masalah dengan mencegah atau mencegah operasi kesalahan ini. Perlindungan semacam itu digunakan di semua sistem operasi modern, namun, metode ini sangat bervariasi dalam kompleksitas, efisiensi, dan kinerja: dari stack canaries dan ASLR hingga CFI dan ROP perlindungan penuh. Pada artikel ini, kami akan mempertimbangkan metode perlindungan apa yang digunakan dalam distribusi Linux paling populer dalam konfigurasi default, dan juga mempelajari sifat-sifat binari yang didistribusikan melalui sistem manajemen paket masing-masing distribusi.

CVE dan keamanan

Kita semua pernah melihat artikel dengan judul seperti "Aplikasi Paling Rentan Tahun Ini" atau "Sistem Operasi Paling Rentan". Biasanya, mereka menyediakan statistik pada jumlah total catatan kerentanan seperti CVE (Common Vulnerability and Exposures) yang diperoleh dari National Vulnerability Database (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 menginformasikan vendor dan pengguna, mereka tidak banyak berbicara tentang keamanan nyata dari perangkat lunak.

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


Fig. 1

Apa yang diceritakan bagan ini kepada kita? Apakah lebih banyak CVE berarti bahwa satu distribusi lebih rentan daripada yang lain? Tidak ada jawaban. Misalnya, dalam artikel ini Anda akan melihat bahwa Debian mengimplementasikan mekanisme keamanan yang lebih ketat dibandingkan dengan, katakanlah, OpenSUSE atau RedHat Linux, namun Debian memiliki lebih banyak CVE. Namun, itu tidak berarti keamanan yang melemah: bahkan memiliki CVE tidak mengatakan apakah kerentanan itu dapat dieksploitasi . Skor keparahan memberikan gambaran tentang seberapa besar kemungkinan eksploitasi kerentanan, tetapi pada akhirnya eksploitasinya sebagian besar bergantung pada perlindungan yang ada dalam sistem yang terkena dampak, serta pada sumber daya dan kemampuan para penyerang. Selain itu, kurangnya laporan CVE tidak mengatakan apa-apa tentang kerentanan lain yang tidak terdaftar atau tidak diketahui . Perbedaan dalam CVE dapat dijelaskan bukan oleh kualitas perangkat lunak, tetapi oleh faktor-faktor lain, termasuk sumber daya yang dialokasikan untuk pengujian, atau ukuran basis pengguna. Dalam contoh kami, lebih banyak CVE Debian mungkin mengindikasikan bahwa Debian memberikan 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 metode operasi yang mungkin dan mengembangkan mekanisme deteksi dan respons yang tepat. Dalam gbr. Gambar 2 menunjukkan kategori kerentanan untuk semua distribusi selama empat tahun terakhir ( sumber ). Sangat jelas bahwa sebagian besar CVE masuk dalam kategori berikut: denial of service (DoS), eksekusi kode, overflow, korupsi memori, kebocoran informasi (exfiltration), dan eskalasi privilege. Meskipun banyak CVE yang dibahas beberapa kali dalam kategori yang berbeda, secara umum, masalah yang sama tetap ada dari tahun ke tahun. Pada bagian selanjutnya dari artikel ini, kami akan mengevaluasi penggunaan berbagai skema perlindungan untuk mencegah eksploitasi kerentanan ini.


Fig. 2

Tugasnya

Dalam artikel ini, kami bermaksud menjawab pertanyaan-pertanyaan berikut:

• Apa keamanan berbagai distribusi Linux? Mekanisme pertahanan apa yang ada dalam aplikasi ruang kernel dan pengguna?
  
• Bagaimana adopsi mekanisme perlindungan untuk berbagai distribusi berubah seiring waktu?
  
• Berapa dependensi rata-rata paket dan pustaka untuk setiap distribusi?
  
• Perlindungan apa yang diterapkan untuk setiap biner?

Memilih Distribusi

Ternyata sulit untuk menemukan statistik yang akurat tentang instalasi distribusi, karena dalam kebanyakan kasus jumlah unduhan tidak menunjukkan jumlah instalasi nyata. Namun, varian Unix merupakan mayoritas sistem server (69,2% pada server web, menurut statistik dari W3techs dan sumber lain), dan bagian mereka terus tumbuh. Jadi, untuk penelitian kami, kami fokus pada distribusi yang tersedia di luar platform Google Cloud . Secara khusus, kami memilih OS berikut:

Distribusi / versi	Intinya	Membangun
OpenSUSE 12.4	4.12.14-95.3-default	# 1 SMP Rab 5 Des 06:00:48 UTC 2018 (63a8d29)
Debian 9 (stretch)	4.9.0-8-amd64	# 1 SMP Debian 4.9.130-2 (2018-10-27)
CentOS 6.10	2.6.32-754.10.1.el6.x86_64	# 1 SMP Sel 15 Jan 17:07:28 UTC 2019
CentOS 7	3.10.0-957.5.1.el7.x86_64	# 1 SMP Fri 1 Feb 14:54:57 UTC 2019
Server Red Hat Enterprise Linux 6.10 (Santiago)	2.6.32-754.9.1.el6.x86_64	# 1 SMP Rab 21 Nov 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)	3.10.0-957.1.3.el7.x86_64	# 1 SMP Kamis 15 Nov 17:36:42 UTC 2018
Ubuntu 14.04 (Tahr Trusty)	4.4.0–140-generik	# 166 ~ 04/14/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 Fri 7 Des 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)	4.15.0-1026-gcp	# 27-Ubuntu SMP Kamis 6 Des 18:27:01 UTC 2018

Tabel 1

Analisis

Kami akan memeriksa konfigurasi kernel default, serta properti paket yang tersedia melalui manajer paket dari setiap paket distribusi di luar kotak. Dengan demikian, kami hanya mempertimbangkan paket dari mirror default masing-masing distribusi, mengabaikan paket dari repositori yang tidak stabil (misalnya, mirror testing dalam Debian) dan paket pihak ketiga (misalnya, paket Nvidia dari mirror standar). Selain itu, kami tidak mempertimbangkan kompilasi kernel khusus atau konfigurasi keamanan tingkat lanjut.

Analisis konfigurasi kernel

Kami menggunakan skrip analisis berdasarkan pemeriksa kconfig gratis . Kami mempertimbangkan opsi perlindungan di luar kotak untuk distribusi yang disebutkan dan membandingkannya dengan daftar dari Proyek Bela Diri Kernel (KSPP). Untuk setiap parameter konfigurasi, Tabel 2 menjelaskan pengaturan yang diinginkan: tanda centang adalah untuk distribusi yang sesuai dengan rekomendasi KSSP (untuk penjelasan tentang istilah-istilah tersebut lihat di sini ; dalam artikel mendatang kami akan menjelaskan berapa banyak metode perlindungan ini muncul dan cara meretas sistem jika tidak ada).





Secara umum, kernel yang lebih baru memiliki pengaturan yang lebih ketat di luar kotak. Misalnya, CentOS 6.10 dan RHEL 6.10 pada kernel 2.6.32 tidak memiliki sebagian besar fungsi kritis yang diimplementasikan dalam kernel baru, seperti SMAP , izin RWX yang kuat, pengacakan alamat, atau perlindungan copy2usr. Perlu dicatat bahwa banyak opsi konfigurasi dari tabel tidak ada di versi kernel yang lebih lama dan tidak berlaku pada kenyataannya - ini masih ditunjukkan dalam tabel sebagai kurangnya perlindungan yang tepat. Demikian pula, jika parameter konfigurasi tidak tersedia dalam versi ini, dan untuk keamanan, parameter ini harus dinonaktifkan, ini dianggap sebagai konfigurasi yang masuk akal.

Poin lain ketika menafsirkan hasil: beberapa konfigurasi kernel yang meningkatkan permukaan serangan dapat digunakan secara bersamaan untuk keamanan. Contoh-contoh tersebut termasuk uprob dan kprobes, modul kernel, dan BPF / eBPF. Rekomendasi kami adalah untuk menggunakan mekanisme di atas untuk memberikan perlindungan nyata, karena mereka tidak sepele untuk digunakan, dan operasinya mengasumsikan bahwa aktor jahat sudah mengakar dalam sistem. Tetapi jika opsi ini diaktifkan, administrator sistem harus secara aktif memantau penyalahgunaan.

Mempelajari lebih lanjut entri pada Tabel 2, kita melihat bahwa kernel modern memberikan beberapa opsi untuk melindungi terhadap eksploitasi kerentanan seperti kebocoran informasi dan tumpukan / tumpukan tumpukan. Namun, kami melihat bahwa bahkan distribusi populer terbaru belum menerapkan perlindungan yang lebih canggih (misalnya, dengan patch grsecurity ) atau perlindungan modern terhadap serangan penggunaan kembali kode (misalnya, menggabungkan pengacakan dengan skema seperti R ^ X untuk kode ). Lebih buruk lagi, bahkan pertahanan yang lebih maju ini tidak melindungi terhadap berbagai serangan. Dengan demikian, sangat penting bagi administrator sistem untuk melengkapi konfigurasi cerdas dengan solusi yang menawarkan deteksi dan pencegahan eksploitasi saat runtime.

Analisis aplikasi

Tidak mengherankan bahwa distribusi yang berbeda memiliki karakteristik paket yang berbeda, opsi kompilasi, dependensi pustaka, dll. Perbedaan ada bahkan untuk distribusi dan paket terkait dengan sejumlah kecil dependensi (misalnya, coreutils di Ubuntu atau Debian). Untuk mengevaluasi perbedaan, kami mengunduh semua paket yang tersedia, mengekstrak isinya dan menganalisis file biner dan dependensi. Untuk setiap paket, kami melacak paket-paket lain tempat ia bergantung, dan untuk setiap biner kami melacak dependensinya. Bagian ini merangkum temuan.

Distribusi

Secara total, kami mengunduh 361.556 paket untuk semua distribusi, hanya mengekstraksi paket dari mirror default. Kami mengabaikan paket tanpa ELF file yang dapat dieksekusi, seperti kode sumber, font, dll. Setelah pemfilteran, 129 569 paket dibiarkan berisi total 584 457 file biner. Distribusi paket dan file di antara distribusi ditunjukkan pada gambar. 3.


Fig. 3

Anda mungkin memperhatikan bahwa semakin modern distribusinya, semakin banyak paket dan file biner yang dikandungnya, yang logis. Pada saat yang sama, paket Ubuntu dan Debian menyertakan lebih banyak file biner (baik modul dan pustaka yang dapat dieksekusi maupun dinamis) daripada CentOS, SUSE, dan RHEL, yang berpotensi mempengaruhi permukaan serangan Ubuntu dan Debian (harus dicatat bahwa angka-angka tersebut mencerminkan semua binari dari semua versi paket, yaitu, beberapa file dianalisis beberapa kali). Ini sangat penting ketika mempertimbangkan ketergantungan antar paket. Dengan demikian, kerentanan dalam biner dari satu paket tunggal dapat memengaruhi banyak bagian ekosistem, sama seperti pustaka yang rentan dapat memengaruhi semua file biner yang mengimpornya. Sebagai titik referensi, mari kita lihat distribusi jumlah dependensi antar paket di berbagai OS:


Fig. 4

Di hampir semua distribusi, 60% paket memiliki setidaknya 10 dependensi. Selain itu, beberapa paket memiliki lebih banyak dependensi (lebih dari 100). Hal yang sama berlaku untuk dependensi paket terbalik: seperti yang diharapkan, beberapa paket digunakan oleh banyak paket lain dalam distribusi, sehingga kerentanan dalam beberapa favorit ini 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 kotak menunjukkan paket dan jumlah dependensi terbalik).


Tabel 3

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


Fig. 5

Pada bagian selanjutnya, kita akan mempelajari karakteristik dari binari yang dianalisis.

Statistik Perlindungan Biner

Sebagai minimum absolut, Anda perlu mempelajari serangkaian opsi perlindungan dasar untuk file biner yang ada. Beberapa distribusi Linux dilengkapi dengan skrip yang melakukan pemeriksaan tersebut. Misalnya, di Debian / Ubuntu ada 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 program dapat dipindahkan dalam memori untuk mencapai pengacakan jika ASLR diaktifkan di kernel.
  
• Stack Protected: apakah stack canary dimasukkan untuk melindungi dari serangan collision stack.
  
• Fortify Source: apakah fungsi yang tidak aman (mis. Strcpy) digantikan oleh rekanan yang lebih aman, dan panggilan yang dicentang dalam runtime diganti oleh rekanan yang tidak diverifikasi (mis. Memcpy alih-alih __memcpy_chk).
  
• Relokasi baca-saja (RELRO): Apakah entri dalam tabel gerakan ditandai sebagai hanya-baca jika berfungsi sebelum eksekusi dimulai.
  
• Pengikatan langsung: apakah runtime linker memungkinkan semua gerakan sebelum memulai program (ini setara dengan RELRO penuh).

Apakah mekanisme di atas cukup? Sayangnya tidak. Ada cara yang dikenal untuk menghindari semua pertahanan di atas, tetapi semakin ketat pertahanannya, semakin tinggi mistar bagi penyerang. Misalnya, solusi RELRO lebih sulit diterapkan jika PIE dan pengikatan langsung berlaku. Demikian juga, ASLR penuh membutuhkan pekerjaan tambahan untuk membuat exploit yang berfungsi. Namun, penyerang canggih siap untuk memenuhi pertahanan seperti itu: ketidakhadiran mereka pada dasarnya akan mempercepat peretasan. Karena itu, sangat penting bahwa langkah-langkah ini dianggap minimum yang diperlukan.

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

• Bit yang tidak dapat dieksekusi ( NX ) mencegah eksekusi di wilayah mana pun yang tidak dapat dieksekusi, seperti tumpukan tumpukan, dll.
• RPATH / RUNPATH menunjukkan jalur eksekusi yang digunakan oleh loader dinamis untuk menemukan perpustakaan yang sesuai. Yang pertama wajib untuk setiap sistem modern: ketidakhadirannya memungkinkan penyerang untuk secara sewenang-wenang menulis muatan ke dalam memori dan menjalankannya apa adanya. Untuk yang kedua, konfigurasi jalur eksekusi yang salah membantu dalam memperkenalkan kode yang tidak dipercaya, yang dapat menyebabkan sejumlah masalah (misalnya, peningkatan privilege , serta masalah lainnya ).
• Stack collision protection memberikan perlindungan terhadap serangan yang menyebabkan stack tumpang tindih dengan area memori lain (seperti heap). Mengingat eksploitasi baru-baru ini menyalahgunakan kerentanan tumpukan tabrakan di systemd , kami merasa pantas untuk memasukkan mekanisme ini dalam kumpulan data kami.

Jadi, tanpa basa-basi, mari beralih ke angka. Tabel 4 dan 5 masing-masing berisi analisis terhadap file yang dapat dieksekusi dan perpustakaan dari berbagai distribusi.

• Seperti yang Anda lihat, perlindungan NX diterapkan di mana-mana, dengan pengecualian langka. Secara khusus, penggunaannya yang lebih rendah di distribusi Ubuntu dan Debian dapat dicatat dibandingkan dengan CentOS, RHEL dan OpenSUSE.
  
• Canary tumpukan tidak tersedia di banyak tempat, terutama di distribusi dengan kernel lama. Beberapa kemajuan telah terlihat dalam distribusi Centos, RHEL, Debian, dan Ubuntu baru-baru ini.
  
• Dengan pengecualian Debian dan Ubuntu 18.04, sebagian besar distribusi memiliki dukungan PIE yang buruk.
  
• Perlindungan tabrakan tumpukan diimplementasikan dengan buruk di OpenSUSE, Centos 7 dan RHEL 7 dan praktis tidak ada di tempat lain.
  
• Semua distribusi dengan kernel modern memiliki beberapa dukungan RELRO, dengan Ubuntu 18,04 memimpin, dengan Debian menempati posisi kedua.

Seperti yang telah disebutkan, metrik dalam tabel ini adalah rata-rata di atas semua versi file biner. Jika Anda hanya melihat versi file terbaru, angkanya akan berbeda (misalnya, lihat kemajuan Debian dengan implementasi PIE ). Selain itu, sebagian besar distribusi biasanya ketika menghitung statistik memeriksa perlindungan hanya beberapa fungsi dalam kode biner, dan dalam analisis kami persentase sebenarnya dari fungsi yang diperkuat ditunjukkan. Oleh karena itu, jika 5 dari 50 fungsi dilindungi dalam biner, kami akan memberinya peringkat 0,1, yang sesuai dengan 10% dari fungsi yang diperkuat.


Tabel 4. Karakteristik perlindungan untuk file yang dapat dieksekusi yang ditunjukkan pada gambar. 3 (implementasi fungsi yang sesuai sebagai persentase dari jumlah total file yang dapat dieksekusi)


Tabel 5. Karakteristik perlindungan untuk perpustakaan yang ditunjukkan pada Gambar. 3 (implementasi fungsi yang sesuai sebagai persentase dari jumlah perpustakaan)

Jadi, apakah ada kemajuan? Pasti ada: itu bisa dilihat dari statistik untuk distribusi individu (misalnya, Debian ), serta dari tabel di atas. Sebagai contoh dalam gambar. Gambar 6 menunjukkan implementasi mekanisme pertahanan dalam tiga distribusi Ubuntu LTS 5 berturut-turut (kami telah menghilangkan statistik stack collision protection). Kami memperhatikan bahwa dari versi ke versi semakin banyak file yang mendukung kenari bertumpuk, dan juga secara berurutan semakin banyak file biner datang dengan perlindungan RELRO penuh.


Fig. 6

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

Ringkasan dan kata penutup

Pada artikel ini, kami menyoroti beberapa fitur keamanan distribusi Linux modern. Analisis menunjukkan bahwa distribusi Ubuntu LTS terbaru (18,04) menerapkan rata-rata OS terkuat dan perlindungan tingkat aplikasi di antara distribusi dengan kernel yang relatif baru, seperti Ubuntu 14.04, 12.04, dan Debian 9. Namun, distribusi CentOS, RHEL, dan OpenSUSE dibahas dalam kit kami. secara default, seperangkat paket yang lebih padat dikeluarkan, dan versi terbaru (CentOS dan RHEL) memiliki persentase perlindungan tabrakan tumpukan yang lebih tinggi dibandingkan dengan pesaing yang berbasis pada Debian (Debian dan Ubuntu). Membandingkan versi CentOS dan RedHat, kami melihat peningkatan besar dalam implementasi stack canaries dan RELRO dari versi 6 hingga 7, tetapi rata-rata CentOS memiliki lebih banyak fitur daripada RHEL. Secara umum, semua distribusi harus memperhatikan perlindungan PIE, yang, dengan pengecualian Debian 9 dan Ubuntu 18.04, diimplementasikan dalam kurang dari 10% file biner dari dataset kami.

Akhirnya, perlu dicatat: meskipun kami melakukan penelitian secara manual, ada banyak alat keamanan (misalnya, Lynis , Tiger , 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. Itulah sebabnya kami sangat yakin bahwa sangat penting untuk memastikan pemantauan dan pencegahan serangan yang andal dalam waktu nyata , dengan fokus pada model operasional dan mencegahnya.