TL; DR. Bu makalede, beş popüler Linux dağıtımında kutudan çıktığı gibi çalışan sağlamlaştırma şemalarını inceliyoruz. Her biri için varsayılan çekirdek konfigürasyonunu aldık, tüm paketleri yükledik ve ekteki ikili dosyalardaki güvenlik şemalarını analiz ettik. Değerlendirilen dağıtımlar OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 ve 7'nin yanı sıra Ubuntu 14.04, 12.04 ve 18.04 LTS'dir.
Sonuçlar, kanaryaları istifleme ve konumdan bağımsız kod gibi temel şemaların bile henüz herkes tarafından benimsenmediğini doğruluyor. Ocak ayında yayınlandıktan sonra gündeme gelen yığın çatışması gibi güvenlik açıklarına karşı koruma söz konusu olduğunda derleyiciler için durum daha da kötü. . Ancak her şey o kadar da umutsuz değil. Önemli sayıda ikili dosya, temel koruma yöntemlerini uygular ve sayıları sürümden sürüme artar.
İnceleme, işletim sistemi ve uygulama düzeylerinde en fazla sayıda koruma yönteminin Ubuntu 18.04'te uygulandığını, ardından Debian 9'un geldiğini gösterdi. Öte yandan OpenSUSE 12.4, CentOS 7 ve RHEL 7 de temel koruma şemaları ve yığın çarpışma korumasını uyguluyor. çok daha yoğun bir varsayılan paket kümesiyle daha da yaygın olarak kullanılır.
Giriş
Yüksek kaliteli yazılım sağlamak zordur. Statik kod analizi ve dinamik çalışma zamanı analizi için çok sayıda gelişmiş aracın yanı sıra derleyicilerin ve programlama dillerinin geliştirilmesindeki önemli ilerlemelere rağmen, modern yazılım hâlâ saldırganlar tarafından sürekli olarak istismar edilen güvenlik açıklarından muzdariptir. Eski kodun bulunduğu ekosistemlerde durum daha da kötü. Bu gibi durumlarda, yalnızca olası istismar edilebilir hataları bulma gibi sonsuz bir sorunla karşı karşıya kalmıyoruz, aynı zamanda sıklıkla sınırlı, hatta daha kötüsü, savunmasız veya hatalı kodu korumamızı gerektiren katı geriye dönük uyumluluk çerçeveleriyle de sınırlanıyoruz.
Programları koruma veya güçlendirme yöntemlerinin devreye girdiği yer burasıdır. Bazı hata türlerini önleyemeyiz ancak saldırganın hayatını zorlaştırabilir ve engelleyerek veya engelleyerek sorunu kısmen çözebiliriz. Çalışma bu hatalar. Bu tür koruma tüm modern işletim sistemlerinde kullanılır, ancak yöntemler karmaşıklık, verimlilik ve performans açısından büyük farklılıklar gösterir: yığın kanaryalarından ve tam korumaya и . Bu yazımızda en popüler Linux dağıtımlarında varsayılan konfigürasyonda hangi koruma yöntemlerinin kullanıldığına bakacağız ve ayrıca her dağıtımın paket yönetim sistemleri aracılığıyla dağıtılan ikili dosyaların özelliklerini de inceleyeceğiz.
CVE ve güvenlik
Hepimiz "Yılın En Savunmasız Uygulamaları" veya "En Savunmasız İşletim Sistemleri" gibi başlıklar taşıyan makaleler görmüşüzdür. Genellikle güvenlik açıklarıyla ilgili toplam kayıt sayısına ilişkin istatistikler sağlarlar: , şuradan alındı itibaren ve diğer kaynaklar. Daha sonra bu uygulamalar veya işletim sistemi, CVE sayısına göre sıralanır. Ne yazık ki, CVE'ler sorunları takip etmek ve satıcıları ve kullanıcıları bilgilendirmek açısından çok faydalı olsa da, yazılımın gerçek güvenliği hakkında çok az şey söylüyorlar.
Örnek olarak, Linux çekirdeği ve en popüler beş sunucu dağıtımı (Ubuntu, Debian, Red Hat Enterprise Linux ve OpenSUSE) için son dört yıldaki toplam CVE sayısını düşünün.
Şek. 1
Bu grafik bize ne anlatıyor? Daha fazla sayıda CVE, bir dağıtımın diğerine göre daha savunmasız olduğu anlamına mı geliyor? Cevapsız. Örneğin, bu makalede Debian'ın, örneğin OpenSUSE veya RedHat Linux'a kıyasla daha güçlü güvenlik mekanizmalarına sahip olduğunu ancak Debian'ın daha fazla CVE'ye sahip olduğunu göreceksiniz. Ancak bunlar mutlaka zayıflamış güvenlik anlamına gelmez: CVE'nin varlığı bile bir güvenlik açığının mevcut olup olmadığını göstermez. sömürülen. Ciddiyet puanları, durumun nasıl olduğuna dair bir gösterge sağlar. muhtemelen Bir güvenlik açığının istismar edilmesi, ancak sonuçta istismar edilebilirlik, büyük ölçüde etkilenen sistemlerde mevcut olan korumalara ve saldırganların kaynaklarına ve yeteneklerine bağlıdır. Üstelik CVE raporlarının yokluğu diğerleri hakkında hiçbir şey söylemiyor kayıtlı değil veya bilinmiyor güvenlik açıkları. CVE'deki fark, teste ayrılan kaynaklar veya kullanıcı tabanının boyutu dahil olmak üzere yazılım kalitesi dışındaki faktörlerden kaynaklanabilir. Örneğimizde, Debian'ın daha fazla sayıda CVE'si, Debian'ın daha fazla yazılım paketi gönderdiğini gösterebilir.
Elbette CVE sistemi uygun korumalar oluşturmanıza olanak tanıyan faydalı bilgiler sağlar. Program başarısızlığının nedenlerini ne kadar iyi anlarsak, olası istismar yöntemlerini belirlemek ve uygun mekanizmaları geliştirmek o kadar kolay olur algılama ve yanıt. İncirde. Şekil 2, son dört yıldaki tüm dağıtımlar için güvenlik açıklarının kategorilerini göstermektedir (). Çoğu CVE'nin şu kategorilere girdiği hemen anlaşılıyor: hizmet reddi (DoS), kod yürütme, taşma, bellek bozulması, bilgi sızıntısı (sızma) ve ayrıcalık yükseltme. Birçok CVE farklı kategorilerde birden çok kez sayılmasına rağmen genel olarak aynı sorunlar her yıl devam etmektedir. Makalenin bir sonraki bölümünde bu güvenlik açıklarından yararlanılmasını önlemek için çeşitli koruma şemalarının kullanımını değerlendireceğiz.
Şek. 2
görevler
Bu yazımızda aşağıdaki sorulara cevap vermeyi amaçlıyoruz:
- Farklı Linux dağıtımlarının güvenliği nedir? Çekirdek ve kullanıcı alanı uygulamalarında hangi koruma mekanizmaları mevcuttur?
- Dağıtımlarda güvenlik mekanizmalarının benimsenmesi zaman içinde nasıl değişti?
- Her dağıtım için paketlerin ve kitaplıkların ortalama bağımlılıkları nelerdir?
- Her ikili dosya için hangi korumalar uygulanır?
Dağıtımların seçimi
Çoğu durumda indirme sayısı gerçek kurulum sayısını göstermediğinden dağıtım kurulumlarıyla ilgili doğru istatistikleri bulmanın zor olduğu ortaya çıktı. Ancak Unix çeşitleri sunucu sistemlerinin çoğunluğunu oluşturur (web sunucularında %69,2, W3tech'ler ve diğer kaynaklar) ve payları sürekli artıyor. Bu nedenle araştırmamız için platformda kullanıma hazır dağıtımlara odaklandık. . Özellikle aşağıdaki işletim sistemini seçtik:
Dağıtım/versiyon
çekirdek
Bild
OpenSUSE 12.4
4.12.14-95.3-varsayılan
#1 SMP Çar 5 Aralık 06:00:48 UTC 2018 (63a8d29)
Debian 9 (uzatılmış)
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 15 Ocak Salı 17:07:28 UTC 2019
7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP Cum 1 Şubat 14:54:57 UTC 2019
Red Hat Kurumsal Linux Sunucusu 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP 21 Kasım Çarşamba 15:08:21 EST 2018
Red Hat Kurumsal Linux Sunucusu 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Per 15 Kasım 17:36:42 UTC 2018
Ubuntu 14.04 (Güvenilir Tahr)
4.4.0–140-genel
#166~14.04.1-Ubuntu SMP 17 Kasım Cumartesi 01:52:43 UTC 20…
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Cum 7 Aralık 09:59:47 UTC 2018
Ubuntu 18.04 (Biyonik Kunduz)
4.15.0–1026-gcp
#27-Ubuntu SMP Per 6 Aralık 18:27:01 UTC 2018
Tablo 1
analizi
Varsayılan çekirdek yapılandırmasının yanı sıra, her dağıtımın paket yöneticisi aracılığıyla kullanıma hazır paketlerin özelliklerini inceleyelim. Bu nedenle, yalnızca her dağıtımın varsayılan aynalarındaki paketleri dikkate alıyoruz; kararsız depolardan gelen paketleri (Debian 'test' aynaları gibi) ve üçüncü taraf paketlerini (standart aynalardan gelen Nvidia paketleri gibi) göz ardı ediyoruz. Ayrıca, özel çekirdek derlemelerini veya güvenliği güçlendirilmiş yapılandırmaları dikkate almıyoruz.
Çekirdek Konfigürasyon Analizi
Aşağıdakileri temel alan bir analiz komut dosyası uyguladık: . Adlandırılmış dağıtımların kullanıma hazır koruma parametrelerine bakalım ve bunları aşağıdaki listeyle karşılaştıralım: (KSPP). Her konfigürasyon seçeneği için Tablo 2'de istenen ayar açıklanmaktadır: onay kutusu, KSSP tavsiyelerine uygun dağıtımlar içindir (terimlerin açıklaması için aşağıya bakın). ; Gelecek yazılarımızda bu güvenlik yöntemlerinden kaç tanesinin ortaya çıktığını ve bunların yokluğunda bir sistemin nasıl hacklenebileceğini açıklayacağız.
Genel olarak, yeni çekirdekler kutudan çıktığı haliyle daha katı ayarlara sahiptir. Örneğin, 6.10 çekirdeğindeki CentOS 6.10 ve RHEL 2.6.32, daha yeni çekirdeklerde uygulanan kritik özelliklerin çoğundan yoksundur: , katı RWX izinleri, rastgele adres seçimi veya copy2usr koruması. Tablodaki yapılandırma seçeneklerinin çoğunun çekirdeğin eski sürümlerinde bulunmadığına ve gerçekte uygulanamayacağına dikkat edilmelidir - bu, tabloda hala uygun koruma eksikliği olarak gösterilmektedir. Benzer şekilde, belirli bir sürümde bir yapılandırma seçeneği mevcut değilse ve güvenlik bu seçeneğin devre dışı bırakılmasını gerektiriyorsa, bu makul bir yapılandırma olarak kabul edilir.
Sonuçları yorumlarken dikkat edilmesi gereken bir diğer nokta ise saldırı yüzeyini artıran bazı çekirdek konfigürasyonlarının güvenlik amacıyla da kullanılabilmesidir. Bu tür örnekler arasında uproblar ve kproblar, çekirdek modülleri ve BPF/eBPF yer alır. Tavsiyemiz, gerçek koruma sağlamak için yukarıdaki mekanizmaların kullanılmasıdır; çünkü bunların kullanımı önemsiz değildir ve bunların kullanılması, kötü niyetli aktörlerin sistemde zaten bir yer edindiğini varsayar. Ancak bu seçenekler etkinleştirilirse sistem yöneticisinin kötüye kullanımı aktif olarak izlemesi gerekir.
Tablo 2'deki girişlere daha ayrıntılı baktığımızda, modern çekirdeklerin bilgi sızıntısı ve yığın/yığın taşmaları gibi güvenlik açıklarından yararlanılmasına karşı koruma sağlamak için çeşitli seçenekler sunduğunu görüyoruz. Ancak, en yeni popüler dağıtımların bile henüz daha karmaşık koruma uygulamadığını görüyoruz (örneğin yamalar ile). ) veya kodun yeniden kullanım saldırılarına karşı modern koruma (ör. ). Daha da kötüsü, bu daha gelişmiş savunmalar bile tüm saldırılara karşı koruma sağlayamıyor. Bu nedenle, sistem yöneticilerinin akıllı yapılandırmaları, çalışma zamanında kötüye kullanımın tespit edilmesini ve önlenmesini sağlayan çözümlerle tamamlaması kritik öneme sahiptir.
Uygulama Analizi
Farklı dağıtımların farklı paket özelliklerine, derleme seçeneklerine, kütüphane bağımlılıklarına vb. sahip olması şaşırtıcı değildir. az sayıda bağımlılığa sahip dağıtımlar ve paketler (örneğin, Ubuntu veya Debian'daki coreutils). Farklılıkları değerlendirmek için mevcut tüm paketleri indirdik, içeriklerini çıkardık ve ikili dosyaları ve bağımlılıkları analiz ettik. Her paket için, bağımlı olduğu diğer paketleri ve her ikili dosya için bağımlılıklarını takip ettik. Bu bölümde sonuçları kısaca özetliyoruz.
dağıtımlar
Toplamda, tüm dağıtımlar için 361 paket indirdik ve yalnızca varsayılan aynalardan paketleri çıkardık. Kaynaklar, yazı tipleri vb. gibi ELF yürütülebilir dosyaları olmayan paketleri göz ardı ettik. Filtrelemeden sonra, toplam 556 ikili dosya içeren 129 paket kaldı. Paketlerin ve dosyaların dağıtımlar arasındaki dağılımı Şekil 569'de gösterilmektedir. 584.
Şek. 3
Dağıtım ne kadar modern olursa, o kadar fazla paket ve ikili dosya içerdiğini fark edebilirsiniz ki bu da mantıklıdır. Bununla birlikte, Ubuntu ve Debian paketleri CentOS, SUSE ve RHEL'den çok daha fazla ikili dosya (hem yürütülebilir dosyalar hem de dinamik modüller ve kütüphaneler) içerir; bu da Ubuntu ve Debian'ın saldırı yüzeyini potansiyel olarak etkiler (sayıların tüm sürümlerin tüm ikili dosyalarını yansıttığı unutulmamalıdır) yani bazı dosyalar birkaç kez analiz edilir). Paketler arasındaki bağımlılıkları düşündüğünüzde bu özellikle önemlidir. Bu nedenle, tek bir ikili paketteki bir güvenlik açığı, tıpkı savunmasız bir kütüphanenin onu içe aktaran tüm ikili dosyaları etkileyebilmesi gibi, ekosistemin birçok bölümünü etkileyebilir. Başlangıç noktası olarak farklı işletim sistemlerindeki paketler arasındaki bağımlılık sayısının dağılımına bakalım:
Şek. 4
Hemen hemen tüm dağıtımlarda paketlerin %60'ının en az 10 bağımlılığı vardır. Ek olarak, bazı paketlerin çok daha fazla sayıda bağımlılığı vardır (100'den fazla). Aynı şey ters paket bağımlılıkları için de geçerlidir: Beklendiği gibi, birkaç paket dağıtımdaki diğer birçok paket tarafından kullanılır, dolayısıyla seçilen birkaç paketteki güvenlik açıkları yüksek risk taşır. Örnek olarak, aşağıdaki tabloda SLES, Centos 20, Debian 7 ve Ubuntu 9'teki maksimum ters bağımlılık sayısına sahip 18.04 paket listelenmektedir (her hücre, paketi ve ters bağımlılık sayısını gösterir).
Tablo 3
İlginç gerçek. Analiz edilen tüm işletim sistemleri x86_64 mimarisi için oluşturulmuş olmasına ve çoğu paketin x86_64 ve x86 olarak tanımlanan mimariye sahip olmasına rağmen, Şekil 5'de gösterildiği gibi paketler genellikle diğer mimarilere yönelik ikili dosyalar içerir. XNUMX.
Şek. 5
Bir sonraki bölümde analiz edilen ikili dosyaların özelliklerini inceleyeceğiz.
İkili dosya koruma istatistikleri
Mutlak minimum düzeyde, mevcut ikili dosyalarınız için temel bir dizi güvenlik seçeneğini keşfetmeniz gerekir. Birçok Linux dağıtımı bu tür kontrolleri gerçekleştiren komut dosyalarıyla birlikte gelir. Mesela Debian/Ubuntu'da böyle bir script var. İşte çalışmalarının bir örneği:
$ 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: yesSenaryo beşini kontrol ediyor :
- Konumdan Bağımsız Yürütülebilir (PIE): Çekirdekte ASLR etkinleştirilmişse, bir programın metin bölümünün rastgeleleştirmeyi sağlamak için belleğe taşınıp taşınamayacağını belirtir.
- Yığın Korumalı: Yığın çarpışma saldırılarına karşı koruma sağlayacak şekilde yığın kanaryalarının etkin olup olmadığı.
- Kaynağı Güçlendir: güvenli olmayan işlevlerin (örneğin, strcpy) daha güvenli benzerleriyle değiştirilip değiştirilmediği ve çalışma zamanında kontrol edilen çağrıların, denetlenmeyen benzerleriyle (örneğin, __memcpy_chk yerine memcpy) değiştirilip değiştirilmediği.
- Salt okunur yer değiştirmeler (RELRO): Yer değiştirme tablosu girişlerinin, yürütme başlamadan önce tetiklenmeleri durumunda salt okunur olarak işaretlenip işaretlenmeyeceği.
- Anında bağlama: Çalışma zamanı bağlayıcının, programın yürütülmesi başlamadan önce tüm hareketlere izin verip vermediği (bu, tam bir RELRO'ya eşdeğerdir).
Yukarıdaki mekanizmalar yeterli mi? Ne yazık ki hayır. Yukarıdaki savunmaların tümünü atlamanın bilinen yolları vardır, ancak savunma ne kadar sert olursa saldırganın çıtası da o kadar yüksek olur. Örneğin, KAYİK ve anında bağlayıcılık mevcutsa uygulanması daha zordur. Benzer şekilde, tam ASLR, çalışan bir istismar oluşturmak için ek çalışma gerektirir. Bununla birlikte, gelişmiş saldırganlar bu tür korumaları karşılamaya zaten hazırdır: bunların yokluğu, esasen hacklemeyi hızlandıracaktır. Bu nedenle bu tedbirlerin gerekli görülmesi esastır. asgari.
Söz konusu dağıtımlardaki kaç ikili dosyanın bu ve diğer üç yöntemle korunduğunu incelemek istedik:
- Çalıştırılamayan bit () yığın yığını vb. gibi yürütülebilir olmaması gereken herhangi bir bölgede yürütmeyi engeller.
- eşleşen kitaplıkları bulmak için dinamik yükleyici tarafından kullanılan yürütme yolunu belirtir. Birincisi zorunlu herhangi bir modern sistem için: bunun yokluğu, saldırganların yükü keyfi olarak belleğe yazmasına ve olduğu gibi yürütmesine olanak tanır. İkincisi, yanlış yürütme yolu yapılandırmaları, bir dizi soruna yol açabilecek güvenilmez kodun tanıtılmasına yardımcı olur (örn. Ve ).
- Yığın çarpışma koruması, yığının belleğin diğer alanlarıyla (yığın gibi) çakışmasına neden olan saldırılara karşı koruma sağlar. Son zamanlardaki suiistimaller göz önüne alındığında , bu mekanizmayı veri setimize dahil etmenin uygun olduğunu düşündük.
Neyse lafı fazla uzatmadan rakamlara geçelim. Tablo 4 ve 5, sırasıyla yürütülebilir dosyaların ve çeşitli dağıtımlardaki kitaplıkların analizinin bir özetini içerir.
- Gördüğünüz gibi NX koruması nadir istisnalar dışında her yerde uygulanmaktadır. Özellikle Ubuntu ve Debian dağıtımlarında CentOS, RHEL ve OpenSUSE ile karşılaştırıldığında biraz daha az kullanıldığı belirtilebilir.
- Yığın kanaryaları birçok yerde, özellikle de eski çekirdeklere sahip dağıtımlarda eksik. Centos, RHEL, Debian ve Ubuntu'nun son dağıtımlarında bazı ilerlemeler görülüyor.
- Debian ve Ubuntu 18.04 dışında çoğu dağıtım zayıf PIE desteğine sahiptir.
- Yığın çarpışma koruması OpenSUSE, Centos 7 ve RHEL 7'de zayıftır ve diğerlerinde neredeyse yoktur.
- Modern çekirdeklere sahip tüm dağıtımlar RELRO'yu bir miktar destekliyor; Ubuntu 18.04 önde, Debian ise ikinci sırada yer alıyor.
Daha önce de belirtildiği gibi, bu tablodaki ölçümler ikili dosyanın tüm sürümlerinin ortalamasıdır. Dosyaların yalnızca en son sürümlerine bakarsanız sayılar farklı olacaktır (örneğin, bkz. ). Üstelik çoğu dağıtım, istatistikleri hesaplarken ikili dosyadaki yalnızca birkaç işlevin güvenliğini test eder, ancak analizimiz, güçlendirilmiş işlevlerin gerçek yüzdesini gösterir. Bu nedenle, eğer bir ikili dosyada 5 fonksiyondan 50'i korunuyorsa, buna 0,1 puan vereceğiz, bu da güçlendirilen fonksiyonların %10'una karşılık geliyor.
Tablo 4. Şekil 3'de gösterilen yürütülebilir dosyalar için güvenlik özellikleri. XNUMX (toplam yürütülebilir dosya sayısının yüzdesi olarak ilgili işlevlerin uygulanması)
Tablo 5. Şekil 3'de gösterilen kütüphanelerin güvenlik özellikleri. XNUMX (toplam kütüphane sayısının yüzdesi olarak ilgili işlevlerin uygulanması)
Peki ilerleme var mı? Kesinlikle var: Bu, bireysel dağılımlara ilişkin istatistiklerden görülebilir (örneğin, ) ve yukarıdaki tablolardan. Örnek olarak Şekil 6'de yer almaktadır. Şekil 5, Ubuntu LTS XNUMX'in birbirini takip eden üç dağıtımında koruma mekanizmalarının uygulanmasını göstermektedir (yığın çarpışma koruma istatistiklerini ihmal ettik). Sürümden sürüme giderek daha fazla dosyanın yığın kanaryalarını desteklediğini ve ayrıca giderek daha fazla ikili dosyanın tam RELRO korumasıyla gönderildiğini fark ettik.
Şek. 6
Ne yazık ki, farklı dağıtımlardaki bir dizi yürütülebilir dosya hala yukarıdaki korumaların hiçbirine sahip değildir. Örneğin, Ubuntu 18.04'e baktığınızda, ngetty ikili dosyasının (getty değişimi) yanı sıra mksh ve lksh kabuklarını, picolisp yorumlayıcısını, nvidia-cuda-toolkit paketlerini (GPU ile hızlandırılmış uygulamalar için popüler bir paket) fark edeceksiniz. makine öğrenimi çerçeveleri gibi) ve klibc -utils. Benzer şekilde, mandos-client ikili dosyası (şifrelenmiş dosya sistemlerine sahip makineleri otomatik olarak yeniden başlatmanıza izin veren bir yönetim aracı) ve rsh-redone-client (rsh ve rlogin'in yeniden uygulanması), SUID haklarına sahip olmalarına rağmen NX koruması olmadan gönderilir: (. Ayrıca, bazı suid ikili dosyaları, yığın kanaryaları gibi temel korumadan yoksundur (örneğin, Xorg paketindeki Xorg.wrap ikili dosyası).
Özet ve Son Açıklamalar
Bu makalede modern Linux dağıtımlarının çeşitli güvenlik özelliklerini vurguladık. Analiz, en son Ubuntu LTS dağıtımının (18.04), Ubuntu 14.04, 12.04 ve Debian 9 gibi nispeten yeni çekirdeklere sahip dağıtımlar arasında ortalama olarak en güçlü işletim sistemi ve uygulama düzeyinde korumayı uyguladığını gösterdi. Ancak incelenen dağıtımlar CentOS, RHEL ve Setimizde bulunan OpenSUSE, varsayılan olarak daha yoğun bir paket seti üretir ve en son sürümlerde (CentOS ve RHEL), Debian tabanlı rakiplere (Debian ve Ubuntu) kıyasla daha yüksek yığın çarpışma koruması yüzdesine sahiptir. CentOS ve RedHat sürümlerini karşılaştırdığımızda, yığın kanaryaları ve RELRO'nun 6'dan 7'ye kadar olan sürümlerinde büyük gelişmeler olduğunu fark ediyoruz, ancak ortalama olarak CentOS, RHEL'den daha fazla özelliğe sahiptir. Genel olarak tüm dağıtımlar, Debian 9 ve Ubuntu 18.04 haricinde veri setimizdeki ikili dosyaların %10'undan daha azında uygulanan PIE korumasına özellikle dikkat etmelidir.
Son olarak, araştırmayı manuel olarak yürütmemize rağmen, birçok güvenlik aracının (örn. , , ), analiz gerçekleştiren ve güvenli olmayan yapılandırmaların önlenmesine yardımcı olan. Ne yazık ki, makul yapılandırmalardaki güçlü koruma bile istismarların bulunmadığını garanti etmez. Bu nedenle, bunu sağlamanın hayati önem taşıdığına kesinlikle inanıyoruz. sömürü kalıplarına odaklanmak ve bunları önlemek.
Kaynak: habr.com