Tl; DR. Sa artikulong ito, tuklasin namin ang mga hardening scheme na gumagana sa labas ng kahon sa limang sikat na distribusyon ng Linux. Para sa bawat isa, kinuha namin ang default na pagsasaayos ng kernel, na-load ang lahat ng mga pakete, at sinuri ang mga scheme ng seguridad sa mga nakalakip na binary. Ang mga distribusyon na isinasaalang-alang ay ang OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 at 7, pati na rin ang 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.

Ang pagsusuri ay nagpakita na ang pinakamalaking bilang ng mga paraan ng proteksyon ay ipinatupad sa Ubuntu 18.04 sa OS at mga antas ng aplikasyon, na sinusundan ng Debian 9. Sa kabilang banda, ang OpenSUSE 12.4, CentOS 7 at RHEL 7 ay nagpapatupad din ng mga pangunahing scheme ng proteksyon, at stack collision protection. ay ginagamit nang mas malawak sa isang 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 и ROP. Sa artikulong ito, titingnan natin kung anong mga paraan ng proteksyon ang ginagamit sa pinakasikat na mga pamamahagi ng Linux sa default na pagsasaayos, at susuriin din ang mga katangian ng mga binary na ipinamamahagi sa pamamagitan ng mga sistema ng pamamahala ng pakete ng bawat pamamahagi.

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.

Bilang halimbawa, isaalang-alang ang kabuuang bilang ng mga CVE sa nakalipas na apat na taon para sa Linux kernel at ang limang pinakasikat na pamamahagi ng server, katulad ng Ubuntu, Debian, Red Hat Enterprise Linux at OpenSUSE.

Fig. 1

Ano ang sinasabi sa atin ng graph na ito? Nangangahulugan ba ang mas mataas na bilang ng mga CVE na ang isang pamamahagi ay mas mahina kaysa sa isa pa? Walang sagot. Halimbawa, sa artikulong ito makikita mo na ang Debian ay may mas malakas na mekanismo ng seguridad kumpara sa, halimbawa, OpenSUSE o RedHat Linux, ngunit ang Debian ay may mas maraming CVE. Gayunpaman, hindi nila nangangahulugang humina ang seguridad: kahit na ang pagkakaroon ng isang CVE ay hindi nagpapahiwatig kung ang isang kahinaan ay 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 CVE ay maaaring dahil sa mga salik maliban sa kalidad ng software, kabilang ang mga mapagkukunang inilaan sa pagsubok o ang laki ng user base. Sa aming halimbawa, ang mas mataas na bilang ng mga CVE ng Debian ay maaaring magpahiwatig lamang na ang Debian ay nagpapadala ng higit pang mga pakete ng software.

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 mga pamamahagi ng Linux? Anong mga mekanismo ng proteksyon ang umiiral sa kernel at mga aplikasyon ng espasyo ng gumagamit?
• 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 (kahabaan)
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 Thu Dis 6 18:27:01 UTC 2018

Table 1

Pagsusuri

Pag-aralan natin ang default na pagsasaayos ng kernel, pati na rin ang mga katangian ng mga pakete na magagamit sa pamamagitan ng manager ng package ng bawat pamamahagi sa labas ng kahon. Kaya, isinasaalang-alang lamang namin ang mga pakete mula sa mga default na salamin ng bawat pamamahagi, binabalewala ang mga pakete mula sa hindi matatag na mga repositoryo (tulad ng mga salamin na 'pagsubok' ng Debian) at mga pakete ng third-party (tulad ng mga pakete ng Nvidia mula sa mga karaniwang salamin). Bukod pa rito, hindi namin isinasaalang-alang ang mga custom na kernel compilations o security-hardened 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 bagong kernel ay may mas mahigpit na mga setting sa labas ng kahon. Halimbawa, ang CentOS 6.10 at RHEL 6.10 sa 2.6.32 kernel ay kulang sa karamihan ng mga kritikal na tampok na ipinapatupad 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 coreutil sa Ubuntu o Debian). Upang suriin ang mga pagkakaiba, na-download namin ang lahat ng magagamit na mga pakete, kinuha ang kanilang mga nilalaman, at sinuri ang mga binary at dependency. Para sa bawat pakete, sinusubaybayan namin ang iba pang mga pakete kung saan ito nakasalalay, at para sa bawat binary, sinusubaybayan namin ang mga dependency nito. Sa bahaging ito, maikli nating ibubuod ang mga konklusyon.

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

Maaari mong mapansin na mas moderno ang pamamahagi, mas maraming mga pakete at binary ang nilalaman nito, na lohikal. Gayunpaman, ang mga pakete ng Ubuntu at Debian ay may kasamang marami pang binary (parehong mga executable at dynamic na module at library) kaysa sa CentOS, SUSE at RHEL, na posibleng makaapekto sa attack surface ng Ubuntu at Debian (dapat tandaan na ang mga numero ay sumasalamin sa lahat ng binary ng lahat ng mga bersyon package, iyon ay, ang ilang mga file ay sinusuri nang maraming beses). Ito ay lalong mahalaga kapag isinasaalang-alang mo ang mga dependency sa pagitan ng mga pakete. Kaya, ang kahinaan sa isang binary na package ay maaaring makaapekto sa maraming bahagi ng ecosystem, tulad ng isang vulnerable na library na maaaring makaapekto sa lahat ng binary na nag-i-import nito. Bilang panimulang punto, tingnan natin ang pamamahagi ng bilang ng mga dependency sa mga pakete sa iba't ibang mga operating system:

Fig. 4

Sa halos lahat ng mga distribusyon, 60% ng mga pakete ay may hindi bababa sa 10 dependencies. Bilang karagdagan, ang ilang mga pakete ay may mas malaking bilang ng mga dependency (higit sa 100). Ang parehong naaangkop sa reverse package dependencies: tulad ng inaasahan, ang ilang mga pakete ay ginagamit ng maraming iba pang mga pakete sa pamamahagi, kaya ang mga kahinaan sa mga piling iilan ay mataas ang panganib. Bilang halimbawa, ang sumusunod na talahanayan ay naglilista ng 20 mga pakete na may pinakamataas na bilang ng reverse dependencies sa SLES, Centos 7, Debian 9 at Ubuntu 18.04 (bawat cell ay nagpapahiwatig ng package at ang bilang ng mga reverse dependencies).

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 ganap na minimum, kailangan mong galugarin ang isang pangunahing hanay ng mga opsyon sa seguridad para sa iyong mga umiiral na binary. Ang ilang mga distribusyon ng Linux ay may kasamang mga script na nagsasagawa ng mga naturang pagsusuri. Halimbawa, ang Debian/Ubuntu ay may ganoong script. Narito ang isang halimbawa ng kanyang trabaho:

$ 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.

• Tulad ng nakikita mo, ang proteksyon ng NX ay ipinatupad sa lahat ng dako, na may mga bihirang eksepsiyon. Sa partikular, mapapansin ng isa ang bahagyang mas mababang paggamit nito sa mga distribusyon ng Ubuntu at Debian kumpara sa CentOS, RHEL at OpenSUSE.
• Ang mga stack canaries ay nawawala sa maraming lugar, lalo na sa mga distribusyon na may mas lumang mga kernels. Ang ilang pag-unlad ay nakikita sa pinakabagong mga pamamahagi ng Centos, RHEL, Debian at Ubuntu.
• Maliban sa Debian at Ubuntu 18.04, karamihan sa mga distribusyon ay may mahinang suporta sa PIE.
• Ang proteksyon ng stack collision ay mahina sa OpenSUSE, Centos 7 at RHEL 7, at halos wala sa iba.
• Ang lahat ng mga distribusyon na may mga modernong kernel ay may ilang suporta para sa RELRO, kung saan ang Ubuntu 18.04 ang nangunguna at ang Debian ay pumapangalawa.

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 ng Debian sa pagpapatupad 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 isang halimbawa sa Fig. Ipinapakita ng Figure 6 ang pagpapatupad ng mga mekanismo ng proteksyon sa tatlong sunud-sunod na distribusyon ng Ubuntu LTS 5 (inalis namin ang stack collision protection statistics). Napansin namin na mula sa bersyon hanggang sa bersyon, parami nang parami ang mga file na sumusuporta sa mga stack canaries, at parami rin nang parami ang mga binary na ipinapadala na may ganap na proteksyon ng RELRO.

Fig. 6

Sa kasamaang palad, ang isang bilang ng mga executable na file sa iba't ibang mga distribusyon ay wala pa ring anumang mga proteksyon sa itaas. Halimbawa, sa pagtingin sa Ubuntu 18.04, mapapansin mo ang ngetty binary (isang getty replacement), pati na rin ang mksh at lksh shell, ang picolisp interpreter, ang nvidia-cuda-toolkit packages (isang sikat na package para sa GPU-accelerated applications. gaya ng machine learning frameworks), at klibc -utils. Gayundin, ang mandos-client binary (isang administratibong tool na nagbibigay-daan sa iyong awtomatikong i-reboot ang mga machine na may mga naka-encrypt na file system) pati na rin ang rsh-redone-client (isang muling pagpapatupad ng rsh at rlogin) ay nagpapadala nang walang proteksyon ng NX, bagama't mayroon silang mga karapatan sa SUID : (. Gayundin, ang ilang suid binary ay walang pangunahing proteksyon gaya ng stack canaries (halimbawa, ang Xorg.wrap binary mula sa Xorg package).

Buod at Pangwakas na Puna

Sa artikulong ito, na-highlight namin ang ilang mga tampok sa seguridad ng mga modernong pamamahagi ng Linux. Ang pagsusuri ay nagpakita na ang pinakabagong pamamahagi ng Ubuntu LTS (18.04) ay nagpapatupad, sa karaniwan, ang pinakamalakas na OS at proteksyon sa antas ng aplikasyon sa mga distribusyon na may mga bagong kernel, tulad ng Ubuntu 14.04, 12.04 at Debian 9. Gayunpaman, ang napagmasdan na mga distribusyon na CentOS, RHEL at Ang OpenSUSE sa aming set bilang default ay gumagawa sila ng mas siksik na hanay ng mga pakete, at sa mga pinakabagong bersyon (CentOS at RHEL) mayroon silang mas mataas na porsyento ng proteksyon sa stack collision kumpara sa mga katunggali na nakabase sa Debian (Debian at Ubuntu). Kung ihahambing ang mga bersyon ng CentOS at RedHat, napansin namin ang malalaking pagpapabuti sa pagpapatupad ng mga stack canaries at RELRO mula sa mga bersyon 6 hanggang 7, ngunit sa karaniwan ang CentOS ay may mas maraming feature na ipinapatupad kaysa sa RHEL. Sa pangkalahatan, dapat bigyan ng espesyal na pansin ng lahat ng mga distribusyon ang proteksyon ng PIE, na, maliban sa Debian 9 at Ubuntu 18.04, ay ipinapatupad sa mas mababa sa 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