TL; DR. Bu yazıda biz beş məşhur Linux paylamasında qutudan kənar işləyən sərtləşdirmə sxemlərini araşdırırıq. Hər biri üçün standart kernel konfiqurasiyasını götürdük, bütün paketləri yüklədik və əlavə edilmiş ikili sənədlərdə təhlükəsizlik sxemlərini təhlil etdik. Nəzərə alınan paylamalar OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 və 7, həmçinin Ubuntu 14.04, 12.04 və 18.04 LTS-dir.
Nəticələr təsdiqləyir ki, hətta kanareykaların yığılması və mövqedən asılı olmayan kod kimi əsas sxemlər hələ hamı tərəfindən qəbul edilmir. Yanvar ayında dərc edildikdən sonra diqqət mərkəzinə düşən stack toqquşması kimi zəifliklərdən qorunmağa gəldikdə, kompilyatorlar üçün vəziyyət daha da pisdir. . Ancaq hər şey o qədər də ümidsiz deyil. Əhəmiyyətli sayda binarlar əsas qorunma üsullarını tətbiq edir və onların sayı versiyadan versiyaya artır.
İcmal göstərdi ki, ən çox qorunma üsulları Ubuntu 18.04-də ƏS və tətbiq səviyyələrində, ardınca Debian 9-da həyata keçirilir. Digər tərəfdən, OpenSUSE 12.4, CentOS 7 və RHEL 7 əsas qoruma sxemlərini və yığınların toqquşmasından mühafizəni həyata keçirir. daha sıx standart paketlər dəsti ilə daha da geniş istifadə olunur.
Giriş
Yüksək keyfiyyətli proqram təminatını təmin etmək çətindir. Statik kodun təhlili və dinamik iş vaxtının təhlili üçün çox sayda qabaqcıl alətlərə, həmçinin kompilyatorların və proqramlaşdırma dillərinin inkişafında əhəmiyyətli irəliləyişlərə baxmayaraq, müasir proqram təminatı hələ də təcavüzkarlar tərəfindən daim istifadə edilən zəifliklərdən əziyyət çəkir. Köhnə kodu ehtiva edən ekosistemlərdə vəziyyət daha da pisdir. Belə hallarda biz nəinki istifadə edilə bilən mümkün səhvləri tapmaqla bağlı əbədi problemlə üzləşirik, həm də bizdən çox vaxt məhdud və ya daha da pis, həssas və ya səhv kodu qorumağı tələb edən ciddi geriyə uyğun uyğunluq çərçivələri ilə məhdudlaşırıq.
Proqramların qorunması və ya sərtləşdirilməsi üsulları burada işə düşür. Bəzi xətaların qarşısını ala bilmirik, lakin qarşısını almaq və ya qarşısını almaqla təcavüzkarın həyatını çətinləşdirə və problemi qismən həll edə bilərik. istismar bu səhvlər. Bu cür qorunma bütün müasir əməliyyat sistemlərində istifadə olunur, lakin üsullar mürəkkəblik, səmərəlilik və performans baxımından çox fərqlənir: kanareykalardan və tam mühafizəyə и . Bu yazıda biz standart konfiqurasiyada ən populyar Linux paylamalarında hansı qorunma üsullarından istifadə olunduğuna baxacağıq, həmçinin hər bir paylamanın paket idarəetmə sistemləri vasitəsilə paylanan ikili faylların xüsusiyyətlərini araşdıracağıq.
CVE və təhlükəsizlik
Hamımız “İlin ən həssas proqramları” və ya “Ən həssas əməliyyat sistemləri” kimi başlıqlı məqalələr görmüşük. Adətən onlar kimi zəifliklər haqqında qeydlərin ümumi sayı haqqında statistik məlumat verirlər , əldə edilmişdir etibarən və digər mənbələr. Sonradan bu proqramlar və ya ƏS CVE-lərin sayına görə sıralanır. Təəssüf ki, CVE-lər problemləri izləmək və təchizatçıları və istifadəçiləri məlumatlandırmaq üçün çox faydalı olsa da, proqram təminatının faktiki təhlükəsizliyi haqqında çox az şey deyirlər.
Nümunə olaraq, Linux nüvəsi və beş ən populyar server paylamaları, yəni Ubuntu, Debian, Red Hat Enterprise Linux və OpenSUSE üçün son dörd il ərzində CVE-lərin ümumi sayını nəzərdən keçirək.
Fig. 1
Bu qrafik bizə nə deyir? CVE-lərin daha çox olması bir paylamanın digərindən daha həssas olduğunu bildirirmi? Cavab yoxdur. Məsələn, bu məqalədə görəcəksiniz ki, Debian, məsələn, OpenSUSE və ya RedHat Linux ilə müqayisədə daha güclü təhlükəsizlik mexanizmlərinə malikdir, lakin Debian-da daha çox CVE var. Bununla belə, onlar mütləq zəifləmiş təhlükəsizlik demək deyil: hətta CVE-nin olması belə zəifliyin olub olmadığını göstərmir. istismar olunur. Şiddətlilik balları necə olduğunu göstərir yəqin ki zəifliyin istismarı, lakin son nəticədə istismar qabiliyyəti təsirə məruz qalan sistemlərdə mövcud qorunmalardan və hücum edənlərin resurslarından və imkanlarından çox asılıdır. Üstəlik, CVE hesabatlarının olmaması başqaları haqqında heç nə demir qeydiyyatsız və ya naməlum zəifliklər. CVE-dəki fərq proqram keyfiyyətindən başqa amillərlə, o cümlədən test üçün ayrılmış resurslar və ya istifadəçi bazasının ölçüsü ilə bağlı ola bilər. Bizim nümunəmizdə Debian-ın daha çox CVE sayı sadəcə Debian-ın daha çox proqram paketi göndərdiyini göstərə bilər.
Əlbəttə ki, CVE sistemi sizə müvafiq qorunma yaratmağa imkan verən faydalı məlumatlar təqdim edir. Proqramın uğursuzluğunun səbəblərini nə qədər yaxşı başa düşsək, mümkün istismar üsullarını müəyyən etmək və müvafiq mexanizmləri hazırlamaq bir o qədər asan olar. aşkarlanması və cavablandırılması. Şəkildə. 2 son dörd il ərzində bütün paylamalar üçün zəifliklərin kateqoriyalarını göstərir (). Dərhal aydın olur ki, əksər CVE-lər aşağıdakı kateqoriyalara bölünür: xidmətdən imtina (DoS), kodun icrası, daşqın, yaddaşın pozulması, məlumat sızması (exfiltrasiya) və imtiyazların yüksəldilməsi. Çoxlu CVE-lər müxtəlif kateqoriyalarda dəfələrlə hesablansa da, ümumilikdə eyni problemlər ildən-ilə davam edir. Məqalənin növbəti hissəsində biz bu zəifliklərin istismarının qarşısını almaq üçün müxtəlif mühafizə sxemlərinin istifadəsini qiymətləndirəcəyik.
Fig. 2
vəzifələri
Bu yazıda aşağıdakı suallara cavab vermək niyyətindəyik:
- Müxtəlif Linux paylamalarının təhlükəsizliyi nədir? Kernel və istifadəçi sahəsi proqramlarında hansı qorunma mexanizmləri mövcuddur?
- Zamanla paylamalar arasında təhlükəsizlik mexanizmlərinin qəbulu necə dəyişdi?
- Hər paylama üçün paketlərin və kitabxanaların orta asılılıqları hansılardır?
- Hər ikili sistem üçün hansı qorumalar həyata keçirilir?
Dağıtımların seçilməsi
Məlum olub ki, paylama qurğuları ilə bağlı dəqiq statistika tapmaq çətindir, çünki əksər hallarda yükləmələrin sayı faktiki quraşdırmaların sayını göstərmir. Bununla belə, Unix variantları server sistemlərinin əksəriyyətini təşkil edir (veb serverlərdə 69,2%, by W3techs və digər mənbələr) və onların payı daim artır. Beləliklə, araşdırmamız üçün platformada qutudan çıxarılan paylamalara diqqət yetirdik . Xüsusilə, aşağıdakı əməliyyat sistemini seçdik:
Dağıtım/versiya
Kernel
qurmaq
OpenSUSE 12.4
4.12.14-95.3-defolt
#1 SMP Çərşənbə 5 Dekabr 06:00:48 UTC 2018 (63a8d29)
Debian 9 (uzanır)
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 Çərşənbə axşamı 15 Yanvar 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP 1 Fevral Cümə 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Çərşənbə 21 Noyabr 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Cümə axşamı 15 Noyabr 17:36:42 UTC 2018
Ubuntu 14.04 (Güvənli Təhrir)
4.4.0-140-ümumi
#166~14.04.1-Ubuntu SMP 17 Noyabr Şənbə 01:52:43 UTC 20…
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP 7 Dekabr Cümə 09:59:47 UTC 2018
Ubuntu 18.04 (Bionik Qunduz)
4.15.0–1026-gcp
#27-Ubuntu SMP Cümə 6 Dekabr 18:27:01 UTC 2018
Cədvəl 1
Təhlil
Gəlin standart nüvə konfiqurasiyasını, eləcə də qutudan kənar hər paylamanın paket meneceri vasitəsilə mövcud paketlərin xüsusiyyətlərini öyrənək. Beləliklə, biz qeyri-sabit depolardan (məsələn, Debian “sınaq” güzgüləri kimi) və üçüncü tərəf paketlərini (standart güzgülərdən Nvidia paketləri kimi) nəzərə almayaraq, yalnız hər paylamanın standart güzgülərindən paketləri nəzərdən keçiririk. Bundan əlavə, biz xüsusi kernel kompilyasiyalarını və ya təhlükəsizliklə gücləndirilmiş konfiqurasiyaları nəzərə almırıq.
Kernel Konfiqurasiya Təhlili
əsasında təhlil skriptini tətbiq etdik . Gəlin adları çəkilən paylanmaların mühafizə parametrlərinə baxaq və onları siyahı ilə müqayisə edək. (KSPP). Hər bir konfiqurasiya seçimi üçün Cədvəl 2 arzu olunan parametri təsvir edir: onay qutusu KSSP tövsiyələrinə uyğun paylamalar üçündür (şərtlərin izahı üçün aşağıdakılara baxın). ; Gələcək məqalələrdə bu təhlükəsizlik üsullarından neçəsinin meydana gəldiyini və onlar olmadıqda sistemi necə sındırmağı izah edəcəyik).
Ümumiyyətlə, yeni nüvələr qutudan kənarda daha sərt parametrlərə malikdir. Məsələn, 6.10 nüvəsindəki CentOS 6.10 və RHEL 2.6.32 yeni nüvələrdə tətbiq olunan kritik funksiyaların əksəriyyətinə malik deyil. , ciddi RWX icazələri, ünvan randomizasiyası və ya copy2usr qorunması. Qeyd etmək lazımdır ki, cədvəldəki konfiqurasiya variantlarının bir çoxu nüvənin köhnə versiyalarında mövcud deyil və reallıqda tətbiq olunmur - bu, hələ də cədvəldə lazımi qorunmanın olmaması kimi göstərilir. Eyni şəkildə, əgər verilmiş versiyada konfiqurasiya seçimi yoxdursa və təhlükəsizlik həmin seçimin deaktiv edilməsini tələb edirsə, bu ağlabatan konfiqurasiya hesab olunur.
Nəticələri şərh edərkən nəzərə alınmalı olan başqa bir məqam: hücum səthini artıran bəzi nüvə konfiqurasiyaları təhlükəsizlik üçün də istifadə edilə bilər. Belə nümunələrə problar və kproblar, nüvə modulları və BPF/eBPF daxildir. Tövsiyəmiz real müdafiəni təmin etmək üçün yuxarıda göstərilən mexanizmlərdən istifadə etməkdir, çünki onların istifadəsi qeyri-ciddidir və onların istismarı pis niyyətli aktorların sistemdə artıq öz yerini tutduğunu güman edir. Lakin bu seçimlər aktivləşdirilibsə, sistem administratoru sui-istifadəyə aktiv şəkildə nəzarət etməlidir.
Cədvəl 2-dəki qeydlərə daha ətraflı nəzər salsaq görərik ki, müasir nüvələr informasiya sızması və yığın/yığın daşması kimi zəifliklərin istismarından qorunmaq üçün bir neçə variant təqdim edir. Bununla belə, qeyd edirik ki, hətta ən son populyar paylamalar hələ də daha mürəkkəb qorunma tətbiq etməyiblər (məsələn, yamaqlarla ) və ya kodun təkrar istifadəsi hücumlarına qarşı müasir müdafiə (məs. ). Vəziyyəti daha da pisləşdirmək üçün, hətta bu daha təkmil müdafiələr bütün hücumlardan qorunmur. Buna görə də, sistem administratorları üçün ağıllı konfiqurasiyaları icra zamanı istismarın aşkarlanması və qarşısının alınmasını təklif edən həllər ilə tamamlaması çox vacibdir.
Tətbiq təhlili
Təəccüblü deyil ki, müxtəlif paylamaların fərqli paket xüsusiyyətləri, tərtib variantları, kitabxanadan asılılıqları və s. var. Fərqlər hətta onlar üçün də mövcuddur. az sayda asılılığı olan paylamalar və paketlər (məsələn, Ubuntu və ya Debian-da coreutils). Fərqləri qiymətləndirmək üçün biz bütün mövcud paketləri yüklədik, onların məzmununu çıxardıq və ikili və asılılıqları təhlil etdik. Hər bir paket üçün biz ondan asılı olan digər paketləri izlədik və hər ikili üçün onun asılılıqlarını izlədik. Bu bölmədə biz nəticələri qısaca ümumiləşdiririk.
paylamalar
Ümumilikdə, biz yalnız standart güzgülərdən paketləri çıxararaq, bütün paylamalar üçün 361 paket endirdik. Mənbələr, şriftlər və s. kimi ELF icra edilə bilənləri olmayan paketləri nəzərə almadıq. Filtrdən sonra cəmi 556 ikili fayldan ibarət 129 paket qaldı. Paketlərin və faylların paylamalar arasında paylanması Şəkil 569-də göstərilmişdir. 584.
Fig. 3
Siz fərq edə bilərsiniz ki, paylanma nə qədər müasir olsa, bir o qədər çox paket və ikili faylları ehtiva edir, bu məntiqlidir. Bununla belə, Ubuntu və Debian paketləri Ubuntu və Debian-ın hücum səthinə potensial təsir göstərən CentOS, SUSE və RHEL-dən daha çox ikili faylları (həm icra olunanlar, həm də dinamik modullar və kitabxanalar) ehtiva edir (qeyd etmək lazımdır ki, nömrələr bütün versiyaların bütün binalarını əks etdirir. paket, yəni bəzi fayllar bir neçə dəfə təhlil edilir). Bu, paketlər arasında asılılıqları nəzərə aldıqda xüsusilə vacibdir. Beləliklə, bir ikili paketdəki zəiflik ekosistemin bir çox hissələrinə təsir göstərə bilər, necə ki, həssas kitabxana onu idxal edən bütün binar sənədlərə təsir edə bilər. Başlanğıc olaraq, müxtəlif əməliyyat sistemlərində paketlər arasında asılılıqların sayının paylanmasına baxaq:
Fig. 4
Demək olar ki, bütün paylamalarda paketlərin 60%-nin ən azı 10 asılılığı var. Bundan əlavə, bəzi paketlərdə əhəmiyyətli dərəcədə daha çox asılılıq var (100-dən çox). Eyni şey tərs paket asılılıqlarına da aiddir: gözlənildiyi kimi, bir neçə paket paylamada bir çox digər paketlər tərəfindən istifadə olunur, ona görə də bəzi seçilmiş paketlərdə zəifliklər yüksək risklidir. Nümunə olaraq, aşağıdakı cədvəl SLES, Centos 20, Debian 7 və Ubuntu 9-də əks asılılıqların maksimum sayına malik 18.04 paketi sadalayır (hər xana paketi və əks asılılıqların sayını göstərir).
Cədvəl 3
Maraqlı fakt. Baxmayaraq ki, təhlil edilən bütün ƏS-lər x86_64 arxitekturası üçün qurulmuşdur və əksər paketlər x86_64 və x86 kimi müəyyən edilmiş arxitekturaya malik olsalar da, Şəkil 5-də göstərildiyi kimi paketlər çox vaxt digər arxitekturalar üçün binarları ehtiva edir. XNUMX.
Fig. 5
Növbəti hissədə biz təhlil edilən ikili faylların xüsusiyyətlərini araşdıracağıq.
İkili fayl mühafizəsi statistikası
Mütləq minimumda, mövcud ikili fayllarınız üçün əsas təhlükəsizlik seçimlərini araşdırmalısınız. Bir neçə Linux paylamaları bu cür yoxlamaları yerinə yetirən skriptlərlə gəlir. Məsələn, Debian/Ubuntu-da belə bir skript var. Onun işindən bir nümunə:
$ 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: yesSkript beşi yoxlayır :
- Position Independent Executable (PIE): ASLR nüvədə aktiv olduqda, təsadüfiləşdirməyə nail olmaq üçün proqramın mətn bölməsinin yaddaşa köçürülüb-köçürülmədiyini göstərir.
- Stack Protected: Yığın kanareykalarının yığın toqquşması hücumlarından qorunmaq üçün aktiv olub-olmaması.
- Gücləndirici Mənbə: təhlükəli funksiyaların (məsələn, strcpy) daha təhlükəsiz analoqları ilə əvəz olunub-olunmaması və icra zamanı yoxlanılan zənglərin yoxlanılmamış həmkarları ilə əvəz edilib-edilməməsi (məsələn, __memcpy_chk əvəzinə memcpy).
- Yalnız oxunan yerdəyişmələr (RELRO): Köçürülmə cədvəli daxiletmələrinin icra başlamazdan əvvəl işə salındıqda yalnız oxunmaq üçün qeyd edilib-edilməməsi.
- Dərhal bağlama: Proqramın icrası başlamazdan əvvəl icra zamanı əlaqələndiricisinin bütün hərəkətlərə icazə verib-verməməsi (bu, tam RELRO-ya bərabərdir).
Yuxarıda göstərilən mexanizmlər kifayətdirmi? Təəssüf ki, heç bir. Yuxarıda göstərilən bütün müdafiələrdən yan keçməyin məlum yolları var, lakin müdafiə nə qədər sərt olsa, hücumçu üçün bar bir o qədər yüksəkdir. Misal üçün, PIE və dərhal bağlama qüvvədə olduqda tətbiq etmək daha çətindir. Eynilə, tam ASLR işləyən istismar yaratmaq üçün əlavə iş tələb edir. Bununla belə, mürəkkəb hücumçular artıq bu cür qorunmalara cavab verməyə hazırdırlar: onların olmaması hacki əhəmiyyətli dərəcədə sürətləndirəcək. Ona görə də bu tədbirlərin zəruri hesab edilməsi vacibdir minimum.
Sözügedən paylamalarda neçə ikili faylın bu və digər üç üsulla qorunduğunu öyrənmək istədik:
- İcra olunmayan bit () icra edilə bilməyən hər hansı bir bölgədə icranın qarşısını alır, məsələn, yığın yığını və s.
- uyğun kitabxanaları tapmaq üçün dinamik yükləyicinin istifadə etdiyi icra yolunu bildirir. Birincisi məcburi istənilən müasir sistem üçün: onun olmaması təcavüzkarlara özbaşına yükü yaddaşa yazmağa və onu olduğu kimi icra etməyə imkan verir. İkincisi, səhv icra yolu konfiqurasiyaları bir sıra problemlərə səbəb ola biləcək etibarsız kodun tətbiqinə kömək edir (məsələn, Və ).
- Yığın toqquşmasından qorunma yığının yaddaşın digər sahələrinin (məsələn, yığın) üst-üstə düşməsinə səbəb olan hücumlardan qorunma təmin edir. Son istismarları nəzərə alaraq , biz bu mexanizmi verilənlər bazamıza daxil etməyi məqsədəuyğun hesab etdik.
Beləliklə, çox uzatmadan rəqəmlərə keçək. Cədvəl 4 və 5 müvafiq olaraq icra edilə bilən faylların və müxtəlif paylanmaların kitabxanalarının təhlilinin xülasəsini ehtiva edir.
- Gördüyünüz kimi, NX qorunması nadir istisnalarla hər yerdə həyata keçirilir. Xüsusilə, Ubuntu və Debian paylamalarında CentOS, RHEL və OpenSUSE ilə müqayisədə bir qədər aşağı istifadəni qeyd etmək olar.
- Yığın kanareykaları bir çox yerdə, xüsusən də köhnə ləpələri olan paylamalarda yoxdur. Centos, RHEL, Debian və Ubuntu-nun ən son paylamalarında müəyyən irəliləyişlər müşahidə olunur.
- Debian və Ubuntu 18.04 istisna olmaqla, əksər paylamalar zəif PIE dəstəyinə malikdir.
- Stack toqquşma qorunması OpenSUSE, Centos 7 və RHEL 7-də zəifdir, digərlərində isə praktiki olaraq mövcud deyil.
- Müasir ləpələri olan bütün paylamalar RELRO-ya müəyyən dəstək verir, Ubuntu 18.04 öndə, Debian isə ikinci yerdədir.
Artıq qeyd edildiyi kimi, bu cədvəldəki göstəricilər ikili faylın bütün versiyaları üçün ortadır. Faylların yalnız ən son versiyalarına baxsanız, nömrələr fərqli olacaq (məsələn, bax ). Üstəlik, əksər paylamalar adətən statistika hesablanarkən binar sistemdə bir neçə funksiyanın təhlükəsizliyini yoxlayır, lakin bizim təhlilimiz sərtləşdirilmiş funksiyaların həqiqi faizini göstərir. Buna görə də, 5 funksiyadan 50-i binar sistemdə qorunursa, ona 0,1 bal verəcəyik ki, bu da gücləndirilən funksiyaların 10%-nə uyğundur.
Cədvəl 4. Şəkildə göstərilən icra olunan fayllar üçün təhlükəsizlik xüsusiyyətləri. 3 (icra olunan faylların ümumi sayının faizi kimi müvafiq funksiyaların yerinə yetirilməsi)
Cədvəl 5. Şəkildə göstərilən kitabxanalar üçün təhlükəsizlik xüsusiyyətləri. 3 (kitabxanaların ümumi sayına nisbətdə müvafiq funksiyaların yerinə yetirilməsi)
Yəni irəliləyiş varmı? Mütləq var: bunu ayrı-ayrı paylamaların statistikasından görmək olar (məsələn, ), eləcə də yuxarıdakı cədvəllərdən. Şəkildə bir nümunə olaraq. Şəkil 6 Ubuntu LTS 5-in üç ardıcıl paylanmasında qoruma mexanizmlərinin tətbiqini göstərir (biz yığının toqquşmasından qorunma statistikasını buraxdıq). Biz qeyd edirik ki, versiyadan versiyaya getdikcə daha çox fayl yığın kanareykalarını dəstəkləyir, həmçinin getdikcə daha çox ikili fayl tam RELRO mühafizəsi ilə göndərilir.
Fig. 6
Təəssüf ki, müxtəlif paylanmalarda olan bir sıra icra edilə bilən fayllar hələ də yuxarıda göstərilən qorunmalardan heç birinə malik deyil. Məsələn, Ubuntu 18.04-ə baxaraq, siz ngetty binary (getty dəyişdirilməsi), həmçinin mksh və lksh qabıqları, picolisp tərcüməçisi, nvidia-cuda-toolkit paketlərini (GPU-sürətləndirilmiş proqramlar üçün məşhur paket) görə bilərsiniz. maşın öyrənmə çərçivələri kimi) və klibc -utils. Eyni şəkildə, mandos-client binar (şifrələnmiş fayl sistemləri ilə maşınları avtomatik yenidən işə salmağa imkan verən inzibati alət), eləcə də rsh-redone-client (rsh və rlogin-in yenidən tətbiqi) SUID hüquqlarına malik olsalar da, NX müdafiəsi olmadan göndərilir: (Həmçinin, bir neçə suid binari, yığın kanareykaları (məsələn, Xorg paketindən olan Xorg.wrap binari) kimi əsas müdafiədən məhrumdur.
Xülasə və Yekun qeydlər
Bu yazıda biz müasir Linux paylamalarının bir neçə təhlükəsizlik xüsusiyyətlərini vurğuladıq. Təhlil göstərdi ki, ən son Ubuntu LTS paylanması (18.04) Ubuntu 14.04, 12.04 və Debian 9 kimi nisbətən yeni nüvələrə malik paylamalar arasında orta hesabla ən güclü ƏS və proqram səviyyəsinin qorunmasını həyata keçirir. Bununla belə, tədqiq edilmiş paylamalar CentOS, RHEL və Bizim dəstimizdə OpenSUSE standart olaraq daha sıx paketlər dəsti istehsal edir və ən son versiyalarda (CentOS və RHEL) Debian əsaslı rəqiblərlə (Debian və Ubuntu) müqayisədə yığının toqquşmasından daha yüksək faiz qorunur. CentOS və RedHat versiyalarını müqayisə etsək, biz 6-dan 7-ci versiyaya qədər stack kanareykaları və RELRO-nun tətbiqində böyük irəliləyişlər görürük, lakin orta hesabla CentOS RHEL-dən daha çox funksiyaya malikdir. Ümumiyyətlə, bütün paylamalar, Debian 9 və Ubuntu 18.04 istisna olmaqla, verilənlər bazamızda ikili faylların 10%-dən azında həyata keçirilən PIE qorunmasına xüsusi diqqət yetirməlidir.
Nəhayət, qeyd etmək lazımdır ki, tədqiqatı əl ilə aparsaq da, bir çox təhlükəsizlik alətləri mövcuddur (məsələn, , , ), təhlil aparan və təhlükəli konfiqurasiyaların qarşısını almağa kömək edən. Təəssüf ki, ağlabatan konfiqurasiyalarda belə güclü qorunma istismarların olmamasına zəmanət vermir. Buna görə də biz əminik ki, bunu təmin etmək çox vacibdir , istismar nümunələrinə diqqət yetirmək və onların qarşısını almaq.
Mənbə: www.habr.com