Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuatTL; DR. Dalam artikel ini, kami meneroka skim pengerasan yang berfungsi di luar kotak pada lima pengedaran Linux yang popular. Untuk setiap satu, kami mengambil konfigurasi kernel lalai, memuatkan semua pakej, dan menganalisis skim keselamatan dalam binari yang dilampirkan. Pengagihan yang dipertimbangkan ialah OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 dan 7, serta Ubuntu 14.04, 12.04 dan 18.04 LTS.

Hasilnya mengesahkan bahawa walaupun skema asas seperti susun kenari dan kod bebas kedudukan masih belum diterima pakai oleh semua orang. Keadaan ini lebih teruk lagi untuk penyusun apabila ia melindungi daripada kelemahan seperti pertembungan timbunan, yang menjadi perhatian pada bulan Januari selepas penerbitan maklumat tentang kelemahan sistemd. Tetapi tidak semuanya begitu putus asa. Sebilangan besar binari melaksanakan kaedah perlindungan asas, dan bilangannya bertambah dari versi ke versi.

Semakan menunjukkan bahawa bilangan terbesar kaedah perlindungan dilaksanakan dalam Ubuntu 18.04 pada tahap OS dan aplikasi, diikuti oleh Debian 9. Sebaliknya, OpenSUSE 12.4, CentOS 7 dan RHEL 7 juga melaksanakan skim perlindungan asas, dan perlindungan perlanggaran timbunan digunakan dengan lebih meluas lagi dengan set pakej lalai yang lebih padat.

Pengenalan

Sukar untuk memastikan perisian berkualiti tinggi. Walaupun terdapat sejumlah besar alat canggih untuk analisis kod statik dan analisis masa jalan dinamik, serta kemajuan ketara dalam pembangunan penyusun dan bahasa pengaturcaraan, perisian moden masih mengalami kelemahan yang sentiasa dieksploitasi oleh penyerang. Keadaan ini lebih teruk lagi dalam ekosistem yang termasuk kod warisan. Dalam kes sedemikian, kami bukan sahaja berhadapan dengan masalah kekal mencari kemungkinan ralat yang boleh dieksploitasi, tetapi kami juga dihadkan oleh rangka kerja keserasian ke belakang yang ketat, yang sering memerlukan kami untuk mengekalkan kod yang terhad, atau lebih teruk lagi, terdedah atau buggy.

Di sinilah kaedah melindungi atau mengeraskan program dimainkan. Kami tidak boleh menghalang beberapa jenis ralat, tetapi kami boleh menjadikan kehidupan penyerang lebih sukar dan menyelesaikan sebahagian masalah dengan menghalang atau menghalang Operasi kesilapan ini. Perlindungan sedemikian digunakan dalam semua sistem pengendalian moden, tetapi kaedahnya sangat berbeza dalam kerumitan, kecekapan dan prestasi: daripada kenari tindanan dan ASLR kepada perlindungan penuh CFI ΠΈ ROP. Dalam artikel ini, kita akan melihat kaedah perlindungan yang digunakan dalam pengedaran Linux yang paling popular dalam konfigurasi lalai, dan juga mengkaji sifat binari yang diedarkan melalui sistem pengurusan pakej setiap pengedaran.

CVE dan keselamatan

Kita semua telah melihat artikel dengan tajuk seperti "Aplikasi Paling Terdedah Tahun Ini" atau "Sistem Operasi Paling Terdedah." Biasanya mereka menyediakan statistik tentang jumlah rekod tentang kelemahan seperti CVE (Kerentanan dan Pendedahan Biasa), diperoleh daripada Pangkalan Data Kerentanan Kebangsaan (NVD) daripada NIST dan sumber lain. Selepas itu, aplikasi atau OS ini disenaraikan mengikut bilangan CVE. Malangnya, walaupun CVE sangat berguna untuk menjejaki isu dan memaklumkan vendor dan pengguna, mereka bercakap sedikit tentang keselamatan sebenar perisian.

Sebagai contoh, pertimbangkan jumlah bilangan CVE sepanjang empat tahun yang lalu untuk kernel Linux dan lima pengedaran pelayan paling popular, iaitu Ubuntu, Debian, Red Hat Enterprise Linux dan OpenSUSE.

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Rajah. Xnumx

Apakah yang diberitahu oleh graf ini kepada kita? Adakah bilangan CVE yang lebih tinggi bermakna satu pengedaran lebih terdedah daripada yang lain? Tiada jawapan. Sebagai contoh, dalam artikel ini anda akan melihat bahawa Debian mempunyai mekanisme keselamatan yang lebih kukuh berbanding dengan, katakan, OpenSUSE atau RedHat Linux, namun Debian mempunyai lebih banyak CVE. Walau bagaimanapun, ia tidak semestinya bermaksud keselamatan yang lemah: malah kehadiran CVE tidak menunjukkan sama ada kelemahan itu dieksploitasi. Skor keterukan memberikan petunjuk bagaimana mungkin eksploitasi kelemahan, tetapi akhirnya eksploitasi bergantung pada perlindungan yang terdapat dalam sistem yang terjejas dan sumber serta keupayaan penyerang. Selain itu, ketiadaan laporan CVE tidak mengatakan apa-apa tentang orang lain tidak berdaftar atau tidak diketahui kelemahan. Perbezaan dalam CVE mungkin disebabkan oleh faktor selain kualiti perisian, termasuk sumber yang diperuntukkan untuk ujian atau saiz pangkalan pengguna. Dalam contoh kami, bilangan CVE Debian yang lebih tinggi mungkin hanya menunjukkan bahawa Debian menghantar lebih banyak pakej perisian.

Sudah tentu, sistem CVE menyediakan maklumat berguna yang membolehkan anda mencipta perlindungan yang sesuai. Lebih baik kita memahami sebab kegagalan program, lebih mudah untuk mengenal pasti kaedah eksploitasi yang mungkin dan membangunkan mekanisme yang sesuai pengesanan dan tindak balas. Dalam Rajah. 2 menunjukkan kategori kelemahan untuk semua pengedaran sepanjang empat tahun lepas (sumber). Jelas sekali bahawa kebanyakan CVE jatuh ke dalam kategori berikut: penafian perkhidmatan (DoS), pelaksanaan kod, limpahan, rasuah memori, kebocoran maklumat (exfiltration) dan peningkatan keistimewaan. Walaupun banyak CVE dikira berbilang kali dalam kategori yang berbeza, secara amnya isu yang sama berterusan tahun demi tahun. Dalam bahagian seterusnya artikel, kami akan menilai penggunaan pelbagai skim perlindungan untuk mencegah eksploitasi kelemahan ini.

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Rajah. Xnumx

tugas-tugas

Dalam artikel ini kami berhasrat untuk menjawab soalan berikut:

  • Apakah keselamatan pengedaran Linux yang berbeza? Apakah mekanisme perlindungan yang wujud dalam kernel dan aplikasi ruang pengguna?
  • Bagaimanakah penerimaan mekanisme keselamatan berubah dari semasa ke semasa merentas pengedaran?
  • Apakah kebergantungan purata pakej dan perpustakaan untuk setiap pengedaran?
  • Apakah perlindungan yang dilaksanakan untuk setiap binari?

Pemilihan pengedaran

Ternyata sukar untuk mencari statistik yang tepat mengenai pemasangan pengedaran, kerana dalam kebanyakan kes bilangan muat turun tidak menunjukkan bilangan pemasangan sebenar. Walau bagaimanapun, varian Unix membentuk sebahagian besar sistem pelayan (pada pelayan web 69,2%, oleh statistik W3techs dan sumber lain), dan bahagian mereka sentiasa berkembang. Oleh itu, untuk penyelidikan kami, kami memberi tumpuan kepada pengedaran yang tersedia di luar kotak pada platform Awan Google. Khususnya, kami memilih OS berikut:

Pengedaran/versi
Inti
bina

OpenSUSE 12.4
4.12.14-95.3-lalai
#1 SMP Rab 5 Dis 06:00:48 UTC 2018 (63a8d29)

Debian 9 (regangan)
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 Jum 1 Feb 14:54:57 UTC 2019

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

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

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generik

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

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

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Kha 6 Dis 18:27:01 UTC 2018

Jadual 1

Analisis

Mari kita kaji konfigurasi kernel lalai, serta sifat pakej yang tersedia melalui pengurus pakej setiap pengedaran di luar kotak. Oleh itu, kami hanya mempertimbangkan pakej daripada setiap cermin lalai pengedaran, mengabaikan pakej daripada repositori yang tidak stabil (seperti cermin 'ujian' Debian) dan pakej pihak ketiga (seperti pakej Nvidia daripada cermin standard). Selain itu, kami tidak menganggap kompilasi kernel tersuai atau konfigurasi yang diperkukuhkan keselamatan.

Analisis Konfigurasi Kernel

Kami menggunakan skrip analisis berdasarkan pemeriksa kconfig percuma. Mari kita lihat parameter perlindungan luar kotak bagi pengedaran yang dinamakan dan bandingkannya dengan senarai daripada Projek Pertahanan Diri Teras (KSPP). Untuk setiap pilihan konfigurasi, Jadual 2 menerangkan tetapan yang diingini: kotak semak adalah untuk pengedaran yang mematuhi pengesyoran KSSP (lihat yang berikut untuk penjelasan istilah). di sini; Dalam artikel akan datang kami akan menerangkan berapa banyak kaedah keselamatan ini wujud dan cara menggodam sistem semasa ketiadaannya).

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat

Secara umum, kernel baharu mempunyai tetapan yang lebih ketat di luar kotak. Contohnya, CentOS 6.10 dan RHEL 6.10 pada kernel 2.6.32 kekurangan kebanyakan ciri kritikal yang dilaksanakan dalam kernel yang lebih baru seperti SMAP, kebenaran RWX yang ketat, rawak alamat atau perlindungan copy2usr. Perlu diingatkan bahawa banyak pilihan konfigurasi dalam jadual tidak tersedia dalam versi kernel yang lebih lama dan tidak boleh digunakan dalam realiti - ini masih ditunjukkan dalam jadual sebagai kekurangan perlindungan yang betul. Begitu juga, jika pilihan konfigurasi tidak terdapat dalam versi tertentu, dan keselamatan memerlukan pilihan itu dilumpuhkan, ini dianggap sebagai konfigurasi yang munasabah.

Perkara lain yang perlu dipertimbangkan semasa mentafsir keputusan: beberapa konfigurasi kernel yang meningkatkan permukaan serangan juga boleh digunakan untuk keselamatan. Contoh sedemikian termasuk uprobes dan kprobes, modul kernel dan BPF/eBPF. Syor kami adalah untuk menggunakan mekanisme di atas untuk memberikan perlindungan sebenar, kerana ia bukan remeh untuk digunakan dan eksploitasinya mengandaikan bahawa pelaku berniat jahat telah pun bertapak dalam sistem. Tetapi jika pilihan ini didayakan, pentadbir sistem mesti memantau secara aktif untuk penyalahgunaan.

Melihat lebih lanjut pada entri dalam Jadual 2, kita melihat bahawa kernel moden menyediakan beberapa pilihan untuk melindungi daripada eksploitasi kelemahan seperti kebocoran maklumat dan limpahan tindanan/timbunan. Walau bagaimanapun, kami mendapati bahawa walaupun pengedaran popular yang paling terkini belum lagi melaksanakan perlindungan yang lebih kompleks (contohnya, dengan patch grsecurity) atau perlindungan moden terhadap serangan penggunaan semula kod (cth. gabungan rawak dengan skema seperti R^X untuk kod). Lebih teruk lagi, pertahanan yang lebih maju ini tidak melindungi daripada pelbagai serangan. Oleh itu, pentadbir sistem adalah penting untuk melengkapkan konfigurasi pintar dengan penyelesaian yang menawarkan pengesanan dan pencegahan eksploitasi masa jalan.

Analisis Aplikasi

Tidak menghairankan, pengedaran yang berbeza mempunyai ciri pakej yang berbeza, pilihan kompilasi, kebergantungan perpustakaan, dll. Perbezaan wujud walaupun untuk berkaitan pengedaran dan pakej dengan sebilangan kecil kebergantungan (contohnya, coreutils pada Ubuntu atau Debian). Untuk menilai perbezaan, kami memuat turun semua pakej yang tersedia, mengekstrak kandungannya dan menganalisis binari dan kebergantungan. Untuk setiap pakej, kami menjejaki pakej lain yang bergantung padanya, dan untuk setiap binari, kami menjejaki kebergantungannya. Dalam bahagian ini kami meringkaskan kesimpulan secara ringkas.

Pengagihan

Secara keseluruhan, kami memuat turun 361 pakej untuk semua pengedaran, mengekstrak hanya pakej daripada cermin lalai. Kami mengabaikan pakej tanpa boleh laku ELF, seperti sumber, fon, dsb. Selepas penapisan, 556 pakej kekal, mengandungi sejumlah 129 binari. Pengedaran pakej dan fail merentasi pengedaran ditunjukkan dalam Rajah. 569.

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Rajah. Xnumx

Anda mungkin perasan bahawa lebih moden pengedaran, lebih banyak pakej dan binari yang terkandung di dalamnya, yang logik. Walau bagaimanapun, pakej Ubuntu dan Debian termasuk lebih banyak perduaan (kedua-dua boleh laku dan modul dinamik dan perpustakaan) daripada CentOS, SUSE dan RHEL, yang berpotensi menjejaskan permukaan serangan Ubuntu dan Debian (perlu diperhatikan bahawa nombor mencerminkan semua binari semua versi pakej, iaitu beberapa fail dianalisis beberapa kali). Ini amat penting apabila anda mempertimbangkan kebergantungan antara pakej. Oleh itu, kelemahan dalam binari pakej tunggal boleh menjejaskan banyak bahagian ekosistem, sama seperti perpustakaan yang terdedah boleh menjejaskan semua binari yang mengimportnya. Sebagai titik permulaan, mari kita lihat pengedaran bilangan kebergantungan antara pakej dalam sistem pengendalian yang berbeza:

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Rajah. Xnumx

Dalam hampir semua pengedaran, 60% daripada pakej mempunyai sekurang-kurangnya 10 kebergantungan. Selain itu, sesetengah pakej mempunyai bilangan kebergantungan yang jauh lebih besar (lebih daripada 100). Perkara yang sama berlaku untuk kebergantungan pakej terbalik: seperti yang dijangkakan, beberapa pakej digunakan oleh banyak pakej lain dalam pengedaran, jadi kelemahan dalam beberapa pakej terpilih adalah berisiko tinggi. Sebagai contoh, jadual berikut menyenaraikan 20 pakej dengan bilangan maksimum kebergantungan terbalik dalam SLES, Centos 7, Debian 9 dan Ubuntu 18.04 (setiap sel menunjukkan pakej dan bilangan ketergantungan terbalik).

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Jadual 3

Fakta menarik. Walaupun semua OS yang dianalisis dibina untuk seni bina x86_64, dan kebanyakan pakej mempunyai seni bina yang ditakrifkan sebagai x86_64 dan x86, pakej sering mengandungi binari untuk seni bina lain, seperti yang ditunjukkan dalam Rajah 5. XNUMX.

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Rajah. Xnumx

Dalam bahagian seterusnya, kita akan menyelidiki ciri-ciri binari yang dianalisis.

Perangkaan perlindungan fail binari

Pada minimum mutlak, anda perlu meneroka set asas pilihan keselamatan untuk binari sedia ada anda. Beberapa pengedaran Linux disertakan dengan skrip yang melakukan pemeriksaan sedemikian. Sebagai contoh, Debian/Ubuntu mempunyai skrip sedemikian. Berikut adalah contoh karya beliau:

$ 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

Skrip menyemak lima fungsi perlindungan:

  • Position Independent Executable (PIE): Menunjukkan sama ada bahagian teks program boleh dialihkan dalam ingatan untuk mencapai rawak jika ASLR didayakan dalam kernel.
  • Dilindungi Tindanan: Sama ada kenari tindanan didayakan untuk melindungi daripada serangan perlanggaran tindanan.
  • Fortify Source: sama ada fungsi tidak selamat (contohnya, strcpy) digantikan dengan rakan sejawatannya yang lebih selamat dan panggilan yang disemak semasa masa jalan digantikan dengan rakan sejawatannya yang tidak disemak (contohnya, memcpy dan bukannya __memcpy_chk).
  • Penempatan semula baca sahaja (RELRO): Sama ada entri jadual penempatan semula ditanda baca sahaja jika ia dicetuskan sebelum pelaksanaan bermula.
  • Pengikatan segera: Sama ada pemaut masa jalan membenarkan semua pergerakan sebelum pelaksanaan program bermula (ini bersamaan dengan RELRO penuh).

Adakah mekanisme di atas mencukupi? Malangnya tidak. Terdapat cara yang diketahui untuk memintas semua pertahanan di atas, tetapi semakin keras pertahanan, semakin tinggi palang untuk penyerang. Sebagai contoh, Kaedah pintasan RELRO lebih sukar untuk digunakan jika PIE dan pengikatan segera berkuat kuasa. Begitu juga, ASLR penuh memerlukan kerja tambahan untuk mencipta eksploitasi kerja. Walau bagaimanapun, penyerang canggih sudah bersedia untuk memenuhi perlindungan sedemikian: ketiadaan mereka pada dasarnya akan mempercepatkan penggodaman. Oleh itu adalah penting bahawa langkah-langkah ini dianggap perlu minimum.

Kami ingin mengkaji berapa banyak fail binari dalam pengedaran yang dipersoalkan dilindungi oleh ini dan tiga kaedah lain:

  • Bit tidak boleh laksana (NX) menghalang pelaksanaan di mana-mana rantau yang tidak sepatutnya boleh dilaksanakan, seperti timbunan tindanan, dsb.
  • RPATH/RUNPATH menandakan laluan pelaksanaan yang digunakan oleh pemuat dinamik untuk mencari perpustakaan yang sepadan. Yang pertama ialah wajib untuk mana-mana sistem moden: ketiadaannya membolehkan penyerang menulis muatan secara sewenang-wenangnya ke dalam ingatan dan melaksanakannya sebagaimana adanya. Untuk yang kedua, konfigurasi laluan pelaksanaan yang salah membantu dalam memperkenalkan kod yang tidak boleh dipercayai yang boleh membawa kepada beberapa masalah (cth. peningkatan keistimewaanDan masalah lain).
  • Perlindungan perlanggaran tindanan memberikan perlindungan terhadap serangan yang menyebabkan tindanan bertindih dengan kawasan ingatan yang lain (seperti timbunan). Memandangkan eksploitasi baru-baru ini menyalahgunakan kelemahan perlanggaran timbunan sistemd, kami merasakan adalah wajar untuk memasukkan mekanisme ini dalam set data kami.

Jadi, tanpa berlengah lagi, mari kita turun ke nombor. Jadual 4 dan 5 mengandungi ringkasan analisis fail boleh laku dan perpustakaan pelbagai pengedaran, masing-masing.

  • Seperti yang anda lihat, perlindungan NX dilaksanakan di mana-mana, dengan pengecualian yang jarang berlaku. Khususnya, seseorang boleh perhatikan penggunaannya yang sedikit lebih rendah dalam pengedaran Ubuntu dan Debian berbanding CentOS, RHEL dan OpenSUSE.
  • Burung kenari timbunan tiada di banyak tempat, terutamanya dalam pengedaran dengan biji yang lebih tua. Beberapa kemajuan dilihat dalam pengedaran terkini Centos, RHEL, Debian dan Ubuntu.
  • Dengan pengecualian Debian dan Ubuntu 18.04, kebanyakan pengedaran mempunyai sokongan PIE yang lemah.
  • Perlindungan perlanggaran tindanan adalah lemah dalam OpenSUSE, Centos 7 dan RHEL 7, dan hampir tidak wujud pada orang lain.
  • Semua pengedaran dengan kernel moden mempunyai beberapa sokongan untuk RELRO, dengan Ubuntu 18.04 mendahului dan Debian berada di tempat kedua.

Seperti yang telah disebutkan, metrik dalam jadual ini adalah purata untuk semua versi fail binari. Jika anda hanya melihat versi terkini fail, nombornya akan berbeza (contohnya, lihat Kemajuan Debian dengan pelaksanaan PIE). Selain itu, kebanyakan pengedaran biasanya hanya menguji keselamatan beberapa fungsi dalam binari apabila mengira statistik, tetapi analisis kami menunjukkan peratusan sebenar fungsi yang dikeraskan. Oleh itu, jika 5 daripada 50 fungsi dilindungi dalam binari, kami akan memberikannya skor 0,1, yang sepadan dengan 10% daripada fungsi yang diperkukuh.

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Jadual 4. Ciri-ciri keselamatan untuk fail boleh laku yang ditunjukkan dalam Rajah. 3 (pelaksanaan fungsi yang berkaitan sebagai peratusan daripada jumlah bilangan fail boleh laku)

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Jadual 5. Ciri-ciri keselamatan untuk perpustakaan yang ditunjukkan dalam Rajah. 3 (pelaksanaan fungsi yang berkaitan sebagai peratusan daripada jumlah bilangan perpustakaan)

Jadi adakah kemajuan? Pasti ada: ini boleh dilihat daripada statistik untuk pengedaran individu (contohnya, Debian), serta daripada jadual di atas. Sebagai contoh dalam Rajah. Rajah 6 menunjukkan pelaksanaan mekanisme perlindungan dalam tiga pengedaran berturut-turut Ubuntu LTS 5 (kami telah meninggalkan statistik perlindungan perlanggaran tindanan). Kami mendapati bahawa dari versi ke versi semakin banyak fail menyokong kenari tindanan, dan juga semakin banyak binari dihantar dengan perlindungan RELRO penuh.

Berjuta-juta binari kemudian. Bagaimana Linux menjadi lebih kuat
Rajah. Xnumx

Malangnya, beberapa fail boleh laku dalam pengedaran berbeza masih tidak mempunyai sebarang perlindungan di atas. Sebagai contoh, melihat Ubuntu 18.04, anda akan melihat binari ngetty (penggantian getty), serta cengkerang mksh dan lksh, penterjemah picolisp, pakej nvidia-cuda-toolkit (pakej popular untuk aplikasi dipercepatkan GPU seperti rangka kerja pembelajaran mesin), dan klibc -utils. Begitu juga, binari mandos-client (alat pentadbiran yang membolehkan anda but semula mesin secara automatik dengan sistem fail yang disulitkan) serta rsh-redone-client (pelaksanaan semula rsh dan rlogin) dihantar tanpa perlindungan NX, walaupun mereka mempunyai hak SUID : (. Selain itu, Beberapa binari suid tidak mempunyai perlindungan asas seperti kenari tindanan (contohnya, binari Xorg.wrap daripada pakej Xorg).

Rumusan dan Penutup

Dalam artikel ini, kami telah menyerlahkan beberapa ciri keselamatan pengedaran Linux moden. Analisis menunjukkan bahawa pengedaran Ubuntu LTS (18.04) terkini melaksanakan, secara purata, perlindungan tahap OS dan aplikasi terkuat di kalangan pengedaran dengan kernel yang agak baharu, seperti Ubuntu 14.04, 12.04 dan Debian 9. Walau bagaimanapun, pengedaran yang diperiksa CentOS, RHEL dan OpenSUSE dalam set kami secara lalai mereka menghasilkan set pakej yang lebih padat, dan dalam versi terkini (CentOS dan RHEL) mereka mempunyai peratusan perlindungan perlanggaran tindanan yang lebih tinggi berbanding pesaing berasaskan Debian (Debian dan Ubuntu). Membandingkan versi CentOS dan RedHat, kami melihat peningkatan besar dalam pelaksanaan kenari tindanan dan RELRO daripada versi 6 hingga 7, tetapi secara purata CentOS mempunyai lebih banyak ciri yang dilaksanakan daripada RHEL. Secara umum, semua pengedaran harus memberi perhatian khusus kepada perlindungan PIE, yang, kecuali Debian 9 dan Ubuntu 18.04, dilaksanakan dalam kurang daripada 10% perduaan dalam set data kami.

Akhir sekali, perlu diingatkan bahawa walaupun kami menjalankan penyelidikan secara manual, terdapat banyak alat keselamatan yang tersedia (cth. Lynis, Harimau, Hubble), yang menjalankan analisis dan membantu mengelakkan konfigurasi yang tidak selamat. Malangnya, walaupun perlindungan yang kuat dalam konfigurasi yang munasabah tidak menjamin ketiadaan eksploitasi. Itulah sebabnya kami yakin bahawa ia adalah penting untuk memastikan pemantauan dan pencegahan serangan yang boleh dipercayai dalam masa nyata, memberi tumpuan kepada corak eksploitasi dan mencegahnya.

Sumber: www.habr.com

Tambah komen