Tl; DRSa artikulong ito, susuriin natin ang mga scheme ng hardening na gumagana agad sa limang sikat na distribusyon. LinuxPara sa bawat isa, kinuha namin ang default na kernel configuration, na-download ang lahat ng package, at sinuri ang mga security scheme sa mga kasama na binary. Ang mga distribusyon na isinasaalang-alang ay ang OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 at 7, at Ubuntu 14.04, 12.04 at 18.04 LTS.

Kinumpirma ng mga resulta na kahit na ang mga pangunahing scheme tulad ng stacking canaries at position-independent code ay hindi pa pinagtibay ng lahat. Ang sitwasyon ay mas masahol pa para sa mga compiler pagdating sa pagprotekta laban sa mga kahinaan tulad ng stack clash, na napunta sa spotlight noong Enero pagkatapos ng publikasyon impormasyon tungkol sa mga kahinaan ng systemd. Ngunit hindi lahat ay walang pag-asa. Ang isang makabuluhang bilang ng mga binary ay nagpapatupad ng mga pangunahing paraan ng proteksyon, at ang kanilang bilang ay lumalaki mula sa bersyon hanggang sa bersyon.

Ipinakita ng audit na ang pinakamalaking bilang ng mga paraan ng proteksyon ay ipinatupad sa Ubuntu 18.04 sa antas ng OS at aplikasyon, na sinusundan ng Debian 9. Sa kabilang banda, sa OpenSUSE 12.4, CentOS Nagpapatupad din ang 7 at RHEL 7 ng mga pangunahing pamamaraan ng proteksyon, at ang proteksyon laban sa stack collision ay mas malawak na inilalapat gamit ang mas siksik na hanay ng mga default na pakete.

Pagpapakilala

Mahirap tiyakin ang mataas na kalidad ng software. Sa kabila ng napakaraming advanced na tool para sa static code analysis at dynamic na runtime analysis, pati na rin ang makabuluhang pag-unlad sa pagbuo ng mga compiler at programming language, ang modernong software ay dumaranas pa rin ng mga kahinaan na patuloy na pinagsasamantalahan ng mga umaatake. Mas malala pa ang sitwasyon sa mga ecosystem na may kasamang legacy code. Sa ganitong mga kaso, hindi lamang tayo nahaharap sa walang hanggang problema sa paghahanap ng mga posibleng mapagsamantalang error, ngunit nalilimitahan din tayo ng mahigpit na backward compatibility frameworks, na kadalasang nangangailangan sa atin na panatilihin ang limitado, o mas masahol pa, mahina o buggy code.

Dito pumapasok ang mga paraan ng pagprotekta o pagpapatigas ng mga programa. Hindi namin mapipigilan ang ilang uri ng mga error, ngunit maaari naming gawing mas mahirap ang buhay ng umaatake at bahagyang malulutas ang problema sa pamamagitan ng pagpigil o pagpigil pagsasamantala ang mga pagkakamaling ito. Ang ganitong proteksyon ay ginagamit sa lahat ng modernong operating system, ngunit ang mga pamamaraan ay naiiba nang malaki sa pagiging kumplikado, kahusayan at pagganap: mula sa stack canaries at ASLR sa ganap na proteksyon CFI и ROPSa artikulong ito, titingnan natin ang mga pamamaraan ng seguridad na ginagamit sa mga pinakasikat na distribusyon. Linux sa default na configuration, at suriin din ang mga katangian ng mga binary na ipinamamahagi sa pamamagitan ng mga package management system ng bawat distribution.

CVE at seguridad

Nakakita na tayong lahat ng mga artikulong may mga pamagat tulad ng "Ang Pinaka Mahina na Aplikasyon ng Taon" o "Ang Pinaka Mahinang Operating System." Kadalasan ay nagbibigay sila ng mga istatistika sa kabuuang bilang ng mga talaan tungkol sa mga kahinaan tulad ng CVE (Mga Karaniwang Kahinaan at Pagkakalantad), nakuha mula sa National Vulnerability Database (NVD) mula sa NIST at iba pang mga mapagkukunan. Kasunod nito, niraranggo ang mga application o OS na ito ayon sa bilang ng mga CVE. Sa kasamaang palad, habang ang mga CVE ay lubhang kapaki-pakinabang para sa pagsubaybay sa mga isyu at pagpapaalam sa mga vendor at user, kakaunti ang sinasabi nila tungkol sa aktwal na seguridad ng software.

Halimbawa, tingnan natin ang kabuuang bilang ng mga CVE sa nakalipas na apat na taon para sa kernel Linux at ang limang pinakasikat na distribusyon ng server, lalo na Ubuntu, Debian, Red Hat Enterprise Linux at OpenSUSE.

Fig. 1

Ano ang sinasabi sa atin ng graph na ito? Ang mas mataas na bilang ng mga CVE ba ay nangangahulugan na ang isang distribusyon ay mas mahina kaysa sa iba? Walang sagot. Halimbawa, sa artikulong ito makikita mo na Debian mas mahigpit na mekanismo ng seguridad ang naipatupad kumpara sa, halimbawa, OpenSUSE o RedHat Linux, at gayon pa man Debian mas maraming CVE. Gayunpaman, hindi naman nangangahulugang humina ang seguridad: kahit ang pagkakaroon ng CVE ay hindi nagpapahiwatig kung ang isang kahinaan pinagsamantalahan. Ang mga marka ng kalubhaan ay nagbibigay ng indikasyon kung paano marahil pagsasamantala sa isang kahinaan, ngunit sa huli ang pagsasamantala ay nakadepende nang husto sa mga proteksyong naroroon sa mga apektadong sistema at sa mga mapagkukunan at kakayahan ng mga umaatake. Bukod dito, ang kawalan ng mga ulat ng CVE ay walang sinasabi tungkol sa iba hindi nakarehistro o hindi kilala mga kahinaan. Ang pagkakaiba sa mga CVE ay maaaring ipaliwanag hindi sa kalidad ng software, kundi sa iba pang mga salik, kabilang ang mga mapagkukunang inilaan para sa pagsubok o ang laki ng base ng gumagamit. Sa aming halimbawa, ang mas mataas na bilang ng mga CVE ay Debian maaaring ipahiwatig lamang na Debian nagbibigay ng mas maraming software package.

Siyempre, ang CVE system ay nagbibigay ng kapaki-pakinabang na impormasyon na nagpapahintulot sa iyo na lumikha ng mga naaangkop na proteksyon. Kung mas naiintindihan natin ang mga dahilan ng pagkabigo ng programa, mas madaling matukoy ang mga posibleng paraan ng pagsasamantala at bumuo ng mga naaangkop na mekanismo pagtuklas at pagtugon. Sa Fig. 2 ay nagpapakita ng mga kategorya ng mga kahinaan para sa lahat ng mga pamamahagi sa nakalipas na apat na taon (pinagmulan). Kaagad na malinaw na ang karamihan sa mga CVE ay nabibilang sa mga sumusunod na kategorya: pagtanggi sa serbisyo (DoS), pagpapatupad ng code, overflow, katiwalian sa memorya, pagtagas ng impormasyon (exfiltration) at pagdami ng pribilehiyo. Bagama't maraming CVE ang binibilang nang maraming beses sa iba't ibang kategorya, sa pangkalahatan ang parehong mga isyu ay nagpapatuloy taon-taon. Sa susunod na bahagi ng artikulo, susuriin natin ang paggamit ng iba't ibang mga scheme ng proteksyon upang maiwasan ang pagsasamantala sa mga kahinaang ito.

Fig. 2

gawain

Sa artikulong ito nilalayon naming sagutin ang mga sumusunod na katanungan:

• Ano ang seguridad ng iba't ibang distribusyon? LinuxAnong mga mekanismo ng proteksyon ang umiiral sa mga aplikasyon ng kernel at user-space?
• Paano nagbago ang paggamit ng mga mekanismo ng seguridad sa paglipas ng panahon sa mga distribusyon?
• Ano ang mga karaniwang dependency ng mga pakete at aklatan para sa bawat pamamahagi?
• Anong mga proteksyon ang ipinatupad para sa bawat binary?

Pagpili ng mga pamamahagi

Lumalabas na mahirap makahanap ng tumpak na mga istatistika sa mga pag-install ng pamamahagi, dahil sa karamihan ng mga kaso ang bilang ng mga pag-download ay hindi nagpapahiwatig ng bilang ng mga aktwal na pag-install. Gayunpaman, ang mga variant ng Unix ay bumubuo sa karamihan ng mga sistema ng server (sa mga web server 69,2%, sa pamamagitan ng mga istatistika W3techs at iba pang mga mapagkukunan), at ang kanilang bahagi ay patuloy na lumalaki. Kaya, para sa aming pananaliksik nakatuon kami sa mga pamamahagi na magagamit sa labas ng kahon sa platform Google Cloud. Sa partikular, pinili namin ang sumusunod na OS:

Pamamahagi/bersyon
Ang pangunahing
Bumuo

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

Debian 9 (inat)
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 Mar 15 Ene 17:07:28 UTC 2019

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

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

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

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic

#166~14.04.1-Ubuntu SMP Sat Nob 17 01:52:43 UTC 20…

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

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

Table 1

Pagsusuri

Susuriin natin ang default na configuration ng kernel, pati na rin ang mga katangian ng mga package na available agad sa pamamagitan ng package manager ng bawat distribution. Nangangahulugan ito na isasaalang-alang lamang natin ang mga package mula sa mga default mirror ng bawat distribution, at hindi papansinin ang mga package mula sa mga unstable repository (hal., ang mga 'testing' mirror sa Debian) at mga third-party na pakete (tulad ng mga pakete ng Nvidia mula sa mga karaniwang mirror). Hindi rin namin isinasaalang-alang ang mga custom na compilation ng kernel o mga pinatigas na configuration.

Pagsusuri ng Configuration ng Kernel

Naglapat kami ng script ng pagsusuri batay sa libreng kconfig checker. Tingnan natin ang out-of-the-box na mga parameter ng proteksyon ng mga pinangalanang distribusyon at ihambing ang mga ito sa listahan mula sa Core Self Defense Project (KSPP). Para sa bawat opsyon sa pagsasaayos, inilalarawan ng Talahanayan 2 ang gustong setting: ang checkbox ay para sa mga distribusyon na sumusunod sa mga rekomendasyon ng KSSP (tingnan ang sumusunod para sa paliwanag ng mga termino). dito; Sa mga artikulo sa hinaharap, ipapaliwanag namin kung ilan sa mga pamamaraang pangseguridad na ito ang nabuo at kung paano mag-hack ng system kapag wala sila).

Sa pangkalahatan, ang mga mas bagong kernel ay may mas mahigpit na mga setting na dala-dala. Halimbawa, CentOS Ang 6.10 at RHEL 6.10 sa kernel 2.6.32 ay walang halos lahat ng mahahalagang tampok na ipinatupad sa mga mas bagong kernel, tulad ng SMAP, mahigpit na mga pahintulot sa RWX, randomization ng address o proteksyon ng copy2usr. Dapat tandaan na marami sa mga pagpipilian sa pagsasaayos sa talahanayan ay hindi magagamit sa mga mas lumang bersyon ng kernel at hindi naaangkop sa katotohanan - ito ay ipinahiwatig pa rin sa talahanayan bilang isang kakulangan ng tamang proteksyon. Gayundin, kung walang opsyon sa pagsasaayos sa isang partikular na bersyon, at hinihiling ng seguridad na huwag paganahin ang opsyong iyon, ito ay itinuturing na isang makatwirang configuration.

Isa pang puntong dapat isaalang-alang kapag binibigyang kahulugan ang mga resulta: ang ilang mga pagsasaayos ng kernel na nagpapataas sa ibabaw ng pag-atake ay maaari ding gamitin para sa seguridad. Kasama sa mga naturang halimbawa ang mga uprobe at kprobes, kernel module, at BPF/eBPF. Ang aming rekomendasyon ay gamitin ang mga mekanismo sa itaas upang magbigay ng tunay na proteksyon, dahil ang mga ito ay hindi mahalaga na gamitin at ang kanilang pagsasamantala ay ipinapalagay na ang mga malisyosong aktor ay nakapagtatag na ng isang foothold sa system. Ngunit kung pinagana ang mga opsyong ito, dapat aktibong subaybayan ng system administrator ang pang-aabuso.

Kung titingnan pa ang mga entry sa Talahanayan 2, makikita natin na ang mga modernong kernel ay nagbibigay ng ilang mga opsyon para sa pagprotekta laban sa pagsasamantala sa mga kahinaan gaya ng pagtagas ng impormasyon at mga stack/heap overflow. Gayunpaman, napansin namin na kahit na ang pinakahuling tanyag na mga pamamahagi ay hindi pa nagpapatupad ng mas kumplikadong proteksyon (halimbawa, na may mga patch grsecurity) o modernong proteksyon laban sa mga pag-atake sa muling paggamit ng code (hal. kumbinasyon ng randomization na may mga scheme tulad ng R^X para sa code). Ang masama pa nito, kahit na ang mga mas advanced na depensang ito ay hindi nagpoprotekta laban sa buong hanay ng mga pag-atake. Samakatuwid, napakahalaga para sa mga administrator ng system na umakma sa mga matalinong pagsasaayos ng mga solusyon na nag-aalok ng runtime exploit detection at pag-iwas.

Pagsusuri ng Application

Hindi nakakagulat na ang iba't ibang mga distribusyon ay may iba't ibang mga katangian ng pakete, mga pagpipilian sa compilation, mga dependency sa library, atbp. Ang mga pagkakaiba ay umiiral kahit para sa kaugnay mga distribusyon at pakete na may maliit na bilang ng mga dependency (halimbawa, mga coreutils sa Ubuntu o DebianUpang masuri ang mga pagkakaiba, dinala namin ang lahat ng magagamit na pakete, kinuha ang mga nilalaman ng mga ito, at sinuri ang mga binary at dependency. Para sa bawat pakete, sinubaybayan namin ang iba pang mga pakete na pinagbabasehan nito, at para sa bawat binary, sinubaybayan namin ang mga dependency nito. Binubuod ng seksyong ito ang mga natuklasan.

mga pamamahagi

Sa kabuuan, nag-download kami ng 361 na pakete para sa lahat ng mga distribusyon, na kumukuha lamang ng mga pakete mula sa mga default na salamin. Hindi namin pinansin ang mga package na walang ELF executable, gaya ng mga source, font, atbp. Pagkatapos ng pag-filter, 556 na package ang natitira, na naglalaman ng kabuuang 129 binary. Ang pamamahagi ng mga pakete at mga file sa mga distribusyon ay ipinapakita sa Fig. 569.

Fig. 3

Mapapansin mo na habang mas moderno ang distribusyon, mas maraming pakete at binary ang nilalaman nito, na lohikal naman. Bukod dito, ang mga pakete Ubuntu и Debian mas maraming binary (parehong executables at dynamic modules at libraries) kaysa sa CentOS, SUSE at RHEL, na posibleng makaapekto sa ibabaw ng pag-atake Ubuntu и Debian (Dapat tandaan na ang mga bilang na ito ay sumasalamin sa lahat ng binary ng lahat ng bersyon ng package, ibig sabihin ang ilang mga file ay sinusuri nang maraming beses.) Ito ay lalong mahalaga kapag isinasaalang-alang ang mga dependency sa pagitan ng mga package. Kaya, ang isang kahinaan sa binary ng isang package ay maaaring makaapekto sa maraming bahagi ng ecosystem, tulad ng isang vulnerable library na maaaring makaapekto sa lahat ng binary na nag-i-import nito. Bilang panimulang punto, tingnan natin ang distribusyon ng mga dependency sa mga package sa iba't ibang operating system:

Fig. 4

Sa halos lahat ng distribusyon, 60% ng mga pakete ay may hindi bababa sa 10 dependencies. Bukod pa rito, ang ilang mga pakete ay may mas maraming dependencies (mahigit sa 100). Ganito rin ang naaangkop sa mga reverse dependencies ng pakete: gaya ng inaasahan, maraming pakete ang ginagamit ng maraming iba pang mga pakete sa distribusyon, kaya ang mga kahinaan sa piling iilang ito ay nagdudulot ng mataas na panganib. Bilang halimbawa, ang sumusunod na talahanayan ay naglilista ng 20 pakete na may pinakamataas na bilang ng mga reverse dependencies sa SLES. Centos 7, Debian 9 at Ubuntu 18.04 (ipinapahiwatig ng bawat cell ang pakete at ang bilang ng mga kabaligtaran na dependency).

Table 3

Kawili-wiling katotohanan. Bagama't ang lahat ng OS na nasuri ay binuo para sa x86_64 na arkitektura, at karamihan sa mga pakete ay may arkitektura na tinukoy bilang x86_64 at x86, ang mga pakete ay kadalasang naglalaman ng mga binary para sa iba pang mga arkitektura, tulad ng ipinapakita sa Figure 5. XNUMX.

Fig. 5

Sa susunod na seksyon, susuriin natin ang mga katangian ng nasuri na mga binary.

Mga istatistika ng proteksyon ng binary file

Sa pinakamababa, dapat mong tuklasin ang isang pangunahing hanay ng mga opsyon sa proteksyon para sa iyong mga umiiral na binary. Maraming distribusyon Linux may kasamang mga script na nagsasagawa ng mga naturang pagsusuri. Halimbawa, sa Debian/Ubuntu Mayroong ganoong script. Narito ang isang halimbawa kung paano ito gumagana:

$ 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

Sinusuri ng script ang lima mga function ng proteksyon:

• Position Independent Executable (PIE): Ipinapahiwatig kung ang seksyon ng teksto ng isang programa ay maaaring ilipat sa memorya upang makamit ang randomization kung ang ASLR ay pinagana sa kernel.
• Stack Protected: Kung ang mga stack canaries ay pinagana upang maprotektahan laban sa mga pag-atake ng banggaan ng stack.
• Fortify Source: kung ang mga hindi ligtas na function (halimbawa, strcpy) ay papalitan ng kanilang mga mas secure na katapat, at ang mga tawag na nasuri sa runtime ay papalitan ng kanilang mga hindi naka-check na katapat (halimbawa, memcpy sa halip na __memcpy_chk).
• Read-only relocations (RELRO): Kung ang mga entry sa relocation table ay minarkahan ng read-only kung na-trigger ang mga ito bago magsimula ang execution.
• Agarang pagbubuklod: Kung pinapayagan ng runtime linker ang lahat ng mga galaw bago magsimula ang pagpapatupad ng programa (ito ay katumbas ng isang buong RELRO).

Sapat ba ang mga mekanismo sa itaas? Sa kasamaang palad hindi. May mga kilalang paraan upang lampasan ang lahat ng mga panlaban sa itaas, ngunit kung mas mahigpit ang depensa, mas mataas ang bar para sa umaatake. Halimbawa, RELRO bypass method mas mahirap mag-apply kung may bisa ang PIE at agarang pagbubuklod. Gayundin, ang buong ASLR ay nangangailangan ng karagdagang trabaho upang lumikha ng isang gumaganang pagsasamantala. Gayunpaman, ang mga sopistikadong umaatake ay handa na upang matugunan ang mga naturang proteksyon: ang kanilang kawalan ay talagang magpapabilis sa pag-hack. Samakatuwid, napakahalaga na ang mga hakbang na ito ay itinuturing na kinakailangan minimum.

Nais naming pag-aralan kung gaano karaming mga binary file sa mga distribusyon na pinag-uusapan ang protektado ng mga ito at ng tatlong iba pang mga pamamaraan:

• Unexecutable bit (NX) pinipigilan ang pagpapatupad sa anumang rehiyon na hindi dapat maisagawa, tulad ng stack heap, atbp.
• RPATH/RUNPATH nagsasaad ng execution path na ginagamit ng dynamic loader para maghanap ng mga katugmang library. Ang una ay sapilitan para sa anumang modernong sistema: ang kawalan nito ay nagbibigay-daan sa mga umaatake na arbitraryong isulat ang payload sa memorya at isagawa ito kung ano man. Para sa pangalawa, nakakatulong ang mga maling configuration ng path ng execution sa pagpapakilala ng hindi mapagkakatiwalaang code na maaaring humantong sa ilang problema (hal. pagtaas ng pribilehiyoAt ibang problema).
• Ang proteksyon ng stack collision ay nagbibigay ng proteksyon laban sa mga pag-atake na nagiging sanhi ng pag-overlap ng stack sa iba pang bahagi ng memorya (gaya ng heap). Dahil sa mga kamakailang pagsasamantala sa pag-abuso systemd heap collision vulnerabilities, naramdaman naming angkop na isama ang mekanismong ito sa aming dataset.

Kaya, nang walang karagdagang ado, bumaba tayo sa mga numero. Ang mga talahanayan 4 at 5 ay naglalaman ng isang buod ng pagsusuri ng mga executable na file at mga aklatan ng iba't ibang mga distribusyon, ayon sa pagkakabanggit.

• Gaya ng nakikita mo, ang proteksyon ng NX ay ipinapatupad kahit saan, maliban sa mga bihirang eksepsiyon. Sa partikular, ang paggamit nito sa mga distribusyon ay medyo mas mababa. Ubuntu и Debian kumpara sa CentOS, RHEL at OpenSUSE.
• Kulang ang mga stack canary sa maraming lugar, lalo na sa mga distribusyon na may mas lumang mga kernel. May ilang pag-unlad na nagawa sa mga kamakailang distribusyon. Centos, RHEL, Debian и Ubuntu.
• Maliban Debian и Ubuntu 18.04, karamihan sa mga distribusyon ay may mahinang suporta sa PIE.
• Hindi maayos na naipatupad ang stack collision protection sa OpenSUSE, Centos 7 at RHEL 7 at halos wala sa iba.
• Lahat ng distribusyon na may mga modernong kernel ay may suporta para sa RELRO, kung saan ang nangunguna ay Ubuntu 18.04, at ang pangalawang pwesto ay nakuha ng Debian.

Gaya ng nabanggit na, ang mga sukatan sa talahanayang ito ay ang average para sa lahat ng mga bersyon ng binary file. Kung titingnan mo lamang ang mga pinakabagong bersyon ng mga file, ang mga numero ay magkakaiba (halimbawa, tingnan pag-unlad Debian sa pagpapakilala ng PIE). Bukod dito, kadalasang sinusubok lamang ng karamihan sa mga distribusyon ang seguridad ng ilang function sa binary kapag kinakalkula ang mga istatistika, ngunit ipinapakita ng aming pagsusuri ang tunay na porsyento ng mga function na pinatigas. Samakatuwid, kung 5 sa 50 function ay protektado sa isang binary, bibigyan namin ito ng marka na 0,1, na tumutugma sa 10% ng mga function na pinalakas.

Talahanayan 4. Mga katangian ng seguridad para sa mga maipapatupad na file na ipinapakita sa Fig. 3 (pagpapatupad ng mga nauugnay na function bilang isang porsyento ng kabuuang bilang ng mga executable na file)

Talahanayan 5. Mga katangian ng seguridad para sa mga aklatan na ipinapakita sa Fig. 3 (pagpapatupad ng mga nauugnay na function bilang isang porsyento ng kabuuang bilang ng mga aklatan)

So may progress na ba? Talagang mayroon: ito ay makikita mula sa mga istatistika para sa mga indibidwal na pamamahagi (halimbawa, Debian), pati na rin mula sa mga talahanayan sa itaas. Bilang halimbawa, ipinapakita ng Fig. 6 ang implementasyon ng mga mekanismong pangproteksyon sa tatlong magkakasunod na distribusyon. Ubuntu LTS 5 (tinanggal namin ang mga istatistika ng proteksyon laban sa stack collision). Napansin namin na, mula sa isang bersyon patungo sa isa pa, parami nang parami ang mga file na sumusuporta sa mga stack canary, at parami nang parami ang mga binary na may kumpletong proteksyon ng RELRO.

Fig. 6

Sa kasamaang palad, maraming executable file sa iba't ibang distribusyon ang kulang pa rin sa alinman sa mga proteksyong nabanggit. Halimbawa, ang pagtingin sa Ubuntu Sa bersyon 18.04, mapapansin mo ang ngetty binary (isang kapalit ng getty), pati na rin ang mga shell ng mksh at lksh, ang picolisp interpreter, at ang nvidia-cuda-toolkit (isang sikat na package para sa mga application na pinabilis ng GPU tulad ng mga machine learning framework) at mga pakete ng klibc-utils. Katulad nito, ang mandos-client binary (isang administrative tool na nagbibigay-daan sa awtomatikong pag-reboot ng mga makinang may naka-encrypt na mga filesystem) at rsh-redone-client (isang muling pagpapatupad ng rsh at rlogin) ay gumagana nang walang proteksyon ng NX, kahit na mayroon silang mga pahintulot sa SUID :(. Bukod pa rito, maraming binary ng SUID ang kulang sa mga pangunahing proteksyon tulad ng mga stack canary (halimbawa, ang Xorg.wrap binary mula sa pakete ng Xorg).

Buod at Pangwakas na Puna

Sa artikulong ito, aming itinampok ang ilang mga tampok sa seguridad ng mga modernong distribusyon. LinuxIpinakita ng pagsusuri na sa pinakabagong distribusyon Ubuntu Ang LTS (18.04) ay may, sa karaniwan, pinakamalakas na proteksyon sa antas ng OS at aplikasyon sa mga distribusyon na may medyo bagong mga kernel, tulad ng Ubuntu 14.04, 12.04 at Debian 9. Gayunpaman, ang mga distribusyon na isinaalang-alang CentOS, ang RHEL at OpenSUSE sa aming dataset ay gumagawa ng mas siksik na hanay ng mga pakete bilang default, at sa mga kamakailang bersyon (CentOS at RHEL) ay may mas mataas na porsyento ng pagpapatupad ng stack collision protection kumpara sa mga kakumpitensya batay sa Debian (Debian и Ubuntu). Paghahambing ng mga bersyon CentOS at RedHat, nakakakita kami ng malalaking pagpapabuti sa implementasyon ng stack canary at RELRO mula bersyon 6 hanggang 7, ngunit sa karaniwan sa CentOS mas maraming feature ang ipinapatupad kaysa sa RHEL. Sa pangkalahatan, dapat bigyang-pansin ng lahat ng distribusyon ang proteksyon ng PIE, na, maliban sa Debian 9 at Ubuntu 18.04, na ipinatupad sa wala pang 10% ng mga binary sa aming dataset.

Sa wakas, dapat tandaan na bagama't manu-mano naming isinagawa ang pananaliksik, maraming magagamit na tool sa seguridad (hal. Lynis, Tigre, Hubble), na nagsasagawa ng pagsusuri at tumutulong na maiwasan ang mga hindi ligtas na pagsasaayos. Sa kasamaang palad, kahit na ang malakas na proteksyon sa mga makatwirang pagsasaayos ay hindi ginagarantiyahan ang kawalan ng mga pagsasamantala. Iyon ang dahilan kung bakit kami ay lubos na naniniwala na ito ay mahalaga upang matiyak maaasahang pagsubaybay at pag-iwas sa mga pag-atake sa real time, na tumutuon sa mga pattern ng pagsasamantala at pagpigil sa mga ito.

Pinagmulan: www.habr.com