TL; DR. Yn dit artikel ûndersykje wy de ferhurdingsskema's dy't bûten it fak wurkje op fiif populêre Linux-distribúsjes. Foar elk namen wy de standert kernel-konfiguraasje, laden alle pakketten, en analysearren de feiligensskema's yn 'e taheakke binaries. De beskôge distribúsjes binne OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 en 7, lykas Ubuntu 14.04, 12.04 en 18.04 LTS.
De resultaten befêstigje dat sels basisskema's lykas it stapeljen fan kanarissen en posysje-ûnôfhinklike koade noch net troch elkenien oannommen wurde. De situaasje is noch slimmer foar gearstallers as it giet om beskerming tsjin kwetsberens lykas stackclash, dy't yn jannewaris nei publikaasje yn it fuotljocht kaam . Mar net alles is sa hopeleas. In signifikant oantal binaries ymplementearje basisbeskermingsmetoaden, en har oantal groeit fan ferzje nei ferzje.
De resinsje liet sjen dat it grutste oantal beskermingsmetoaden yn Ubuntu 18.04 ymplementearre is op it OS- en applikaasjenivo's, folge troch Debian 9. Oan 'e oare kant implementearje OpenSUSE 12.4, CentOS 7 en RHEL 7 ek basisbeskermingsskema's, en stapelbotsingsbeskerming. wurdt noch breder brûkt mei in folle tichtere set fan standertpakketten.
Ynlieding
It is lestich om software fan hege kwaliteit te garandearjen. Nettsjinsteande it grutte oantal avansearre ark foar statyske koade-analyze en dynamyske runtime-analyze, lykas ek wichtige foarútgong yn 'e ûntwikkeling fan gearstallers en programmeartalen, hat moderne software noch te lijen fan kwetsberens dy't konstant wurde eksploitearre troch oanfallers. De situaasje is noch slimmer yn ekosystemen dy't legacy-koade omfetsje. Yn sokke gefallen wurde wy net allinich konfrontearre mei it ivige probleem fan it finen fan mooglike eksploitbere flaters, mar wy binne ek beheind troch strikte efterútkompatibiliteitskaders, dy't ús faaks fereaskje om beheinde, of noch slimmer, kwetsbere of buggy-koade te behâlden.
Dit is wêr't metoaden foar beskerming of ferhurding fan programma's yn spiel komme. Wy kinne guon soarten flaters net foarkomme, mar wy kinne it libben fan 'e oanfaller dreger meitsje en it probleem foar in part oplosse troch te foarkommen of te foarkommen eksploitaasje dizze flaters. Sokke beskerming wurdt brûkt yn alle moderne bestjoeringssystemen, mar de metoaden ferskille sterk yn kompleksiteit, effisjinsje en prestaasjes: fan stapelkanaryske en ta folsleine beskerming и . Yn dit artikel sille wy sjen op hokker beskermingmetoaden wurde brûkt yn 'e populêrste Linux-distribúsjes yn' e standertkonfiguraasje, en ek ûndersiikje de eigenskippen fan 'e binaries dy't ferspraat wurde troch de pakketbehearsystemen fan elke distribúsje.
CVE en feiligens
Wy hawwe allegear artikels sjoen mei titels lykas "De meast kwetsbere applikaasjes fan it jier" of "De meast kwetsbere bestjoeringssystemen." Normaal leverje se statistiken oer it totale oantal records oer kwetsberens lykas , krigen fan от en oare boarnen. Dêrnei wurde dizze applikaasjes as OS rangearre troch it oantal CVE's. Spitigernôch, wylst CVE's heul nuttich binne foar it folgjen fan problemen en it ynformearjen fan leveransiers en brûkers, sizze se net folle oer de eigentlike feiligens fan 'e software.
As foarbyld, beskôgje it totale oantal CVE's yn 'e ôfrûne fjouwer jier foar de Linux-kernel en de fiif populêrste serverdistribúsjes, nammentlik Ubuntu, Debian, Red Hat Enterprise Linux en OpenSUSE.
Fig. 1
Wat fertelt dizze grafyk ús? Betsjut in heger oantal CVE's dat de iene distribúsje kwetsberder is as de oare? Gjin antwurd. Bygelyks, yn dit artikel sille jo sjen dat Debian sterkere feiligensmeganismen hat yn ferliking mei bygelyks OpenSUSE of RedHat Linux, en dochs hat Debian mear CVE's. Se betsjutte lykwols net needsaaklik ferswakke feiligens: sels de oanwêzigens fan in CVE jout net oan oft in kwetsberens is eksploitearre. Severity scores jouwe in yndikaasje fan hoe wierskynlik eksploitaasje fan in kwetsberens, mar úteinlik eksploitaasje hinget sterk ôf fan de beskermingen oanwêzich yn de troffen systemen en de middels en mooglikheden fan de oanfallers. Boppedat seit it ûntbrekken fan CVE-rapporten neat oer oaren net registrearre of ûnbekend kwetsberens. It ferskil yn CVE kin wêze fanwege faktoaren oars as software kwaliteit, ynklusyf de boarnen tawiisd oan testen of de grutte fan 'e brûkersbasis. Yn ús foarbyld kin it hegere oantal CVE's fan Debian gewoan oanjaan dat Debian mear softwarepakketten ferstjoert.
Fansels leveret it CVE-systeem nuttige ynformaasje wêrmei jo passende beskermingen kinne meitsje. Hoe better wy de redenen foar it mislearjen fan programma's begripe, hoe makliker it is om mooglike metoaden fan eksploitaasje te identifisearjen en passende meganismen te ûntwikkeljen deteksje en antwurd. Yn Fig. 2 toant de kategoryen fan kwetsberens foar alle distribúsjes oer de lêste fjouwer jier (). It is fuortendaliks dúdlik dat de measte CVE's yn 'e folgjende kategoryen falle: ûntkenning fan tsjinst (DoS), útfiering fan koade, oerstreaming, ûnthâldkorrupsje, ynformaasjelekkage (eksfiltraasje) en eskalaasje fan privileezjes. Hoewol in protte CVE's meardere kearen yn ferskate kategoryen teld wurde, besteane yn 't algemien deselde problemen jier nei jier. Yn it folgjende diel fan it artikel sille wy it gebrûk fan ferskate beskermingskema's evaluearje om de eksploitaasje fan dizze kwetsberens te foarkommen.
Fig. 2
taken
Yn dit artikel wolle wy de folgjende fragen beantwurdzje:
- Wat is de feiligens fan ferskate Linux-distribúsjes? Hokker beskermingsmeganismen besteane yn 'e kernel- en brûkersromteapplikaasjes?
- Hoe is it oannimmen fan feiligensmeganismen yn 'e rin fan' e tiid feroare oer distribúsjes?
- Wat binne de gemiddelde ôfhinklikens fan pakketten en bibleteken foar elke distribúsje?
- Hokker beskermingen wurde ymplementearre foar elke binêr?
Seleksje fan distribúsjes
It docht bliken dat it lestich is om krekte statistiken te finen oer distribúsje-ynstallaasjes, om't yn 'e measte gefallen it oantal downloads it oantal werklike ynstallaasjes net oanjout. Unix-farianten meitsje lykwols de mearderheid fan serversystemen út (op webservers 69,2%, troch W3techs en oare boarnen), en har oandiel groeit konstant. Sa, foar ús ûndersyk rjochte wy ús op distribúsjes beskikber út it fak op it platfoarm . Yn it bysûnder hawwe wy it folgjende OS selektearre:
Distribúsje / ferzje
De kearn
Bouwe
OpenSUSE 12.4
4.12.14-95.3-standert
#1 SMP Wo 5 Des 06:00:48 UTC 2018 (63a8d29)
Debian 9 (stretch)
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 Tue Jannewaris 15 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP freed 1 febrewaris 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Wo 21 novimber 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 15 Nov 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0-140-generysk
#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Fri 7 Dec 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu 6 Dec 18:27:01 UTC 2018
Tabel 1
Analysis
Litte wy de standert kernel-konfiguraasje studearje, lykas de eigenskippen fan pakketten beskikber fia de pakketbehearder fan elke distribúsje út 'e doaze. Sa beskôgje wy allinich pakketten fan 'e standertspegels fan elke distribúsje, negearje pakketten fan ynstabile repositories (lykas Debian 'testen' spegels) en pakketten fan tredden (lykas Nvidia-pakketten fan standertspegels). Derneist beskôgje wy gjin oanpaste kernel-kompilaasjes of feiligens-ferhurde konfiguraasjes.
Kernel konfiguraasje Analyse
Wy tapast in analyse skript basearre op . Litte wy nei de out-of-the-box beskermingsparameters fan 'e neamde distribúsjes sjen en fergelykje mei de list fan (KSPP). Foar elke konfiguraasjeopsje beskriuwt Tabel 2 de winske ynstelling: it karfakje is foar distribúsjes dy't foldogge oan de KSSP-oanbefellings (sjoch it folgjende foar in útlis fan termen). ; Yn takomstige artikels sille wy útlizze hoefolle fan dizze feiligensmetoaden ûntstien binne en hoe't jo in systeem kinne hacke yn har ôfwêzigens).
Yn 't algemien hawwe de nije kernels strangere ynstellings bûten it fak. Bygelyks, CentOS 6.10 en RHEL 6.10 op 'e 2.6.32 kernel misse de measte krityske funksjes ymplementearre yn nijere kernels lykas , strange RWX tagongsrjochten, adres randomization of copy2usr beskerming. It moat opmurken wurde dat in protte fan 'e konfiguraasjeopsjes yn' e tabel net beskikber binne yn âldere ferzjes fan 'e kernel en binne net fan tapassing yn' e realiteit - dit wurdt yn 'e tabel noch altyd oanjûn as in gebrek oan goede beskerming. Likemin, as in konfiguraasjeopsje net oanwêzich is yn in opjûne ferzje, en feiligens fereasket dat dizze opsje útskeakele is, wurdt dit beskôge as in ridlike konfiguraasje.
In oar punt om te beskôgjen by it ynterpretearjen fan de resultaten: guon kernelkonfiguraasjes dy't it oanfalflak ferheegje kinne ek brûkt wurde foar feiligens. Sokke foarbylden omfetsje uprobes en kprobes, kernelmodules, en BPF/eBPF. Us oanbefelling is om de boppesteande meganismen te brûken om echte beskerming te leverjen, om't se net-trivial binne om te brûken en har eksploitaasje giet derfan út dat kweade akteurs al in foet yn it systeem fêststeld hawwe. Mar as dizze opsjes ynskeakele binne, moat de systeembehearder aktyf kontrolearje op misbrûk.
As wy fierder sjogge nei de yngongen yn Tabel 2, sjogge wy dat moderne kernels ferskate opsjes leverje foar beskerming tsjin eksploitaasje fan kwetsberens lykas ynformaasjelekkage en stack / heap oerstreamingen. Wy fernimme lykwols dat sels de meast resinte populêre distribúsjes noch gjin kompleksere beskerming hawwe ymplementearre (bygelyks mei patches ) of moderne beskerming tsjin oanfallen fan koade opnij brûke (bgl. ). Om saken slimmer te meitsjen, sels dizze mear avansearre ferdigeningswurken beskermje net tsjin it folsleine oanbod fan oanfallen. Dêrom is it kritysk foar systeembehearders om tûke konfiguraasjes oan te foljen mei oplossingen dy't deteksje en previnsje fan runtime-exploitaasje biede.
Application Analysis
Net ferrassend, ferskillende distribúsjes hawwe ferskillende pakket skaaimerken, kompilaasje opsjes, biblioteek ôfhinklikens, ensfh Ferskillen bestean sels foar distribúsjes en pakketten mei in lyts oantal ôfhinklikens (bygelyks coreutils op Ubuntu of Debian). Om de ferskillen te evaluearjen, hawwe wy alle beskikbere pakketten downloade, har ynhâld ekstrahearre en de binaries en ôfhinklikens analysearre. Foar elk pakket hawwe wy de oare pakketten folge wêrfan it hinget, en foar elke binêr hawwe wy de ôfhinklikens folge. Yn dizze paragraaf gearfetsje wy koart de konklúzjes.
Distributions
Yn totaal hawwe wy 361 pakketten ynladen foar alle distribúsjes, allinich pakketten út standertspegels ekstrahearje. Wy negeare pakketten sûnder ELF-útfierbere bestannen, lykas boarnen, lettertypen, ensfh. De ferdieling fan pakketten en bestannen oer distribúsjes wurdt werjûn yn Fig. 556.
Fig. 3
Jo kinne merke dat de modernere de distribúsje, hoe mear pakketten en binaries it befettet, wat logysk is. Ubuntu- en Debian-pakketten omfetsje lykwols folle mear binaries (sawol útfierbere as dynamyske modules en bibleteken) dan CentOS, SUSE en RHEL, dy't mooglik ynfloed hawwe op it oanfalsflak fan Ubuntu en Debian (it moat opmurken wurde dat de nûmers alle binaries fan alle ferzjes reflektearje pakket, dat is, guon bestannen wurde ferskate kearen analysearre). Dit is foaral wichtich as jo ôfhinklikens tusken pakketten beskôgje. Sa kin in kwetsberens yn ien binêr pakket in protte dielen fan it ekosysteem beynfloedzje, lykas in kwetsbere bibleteek kin beynfloedzje alle binaries dy't it ymportearje. Litte wy as útgongspunt sjen nei de ferdieling fan it oantal ôfhinklikens tusken pakketten yn ferskate bestjoeringssystemen:
Fig. 4
Yn hast alle distribúsjes hat 60% fan pakketten op syn minst 10 ôfhinklikens. Derneist hawwe guon pakketten in signifikant grutter oantal ôfhinklikens (mear as 100). Itselde jildt foar omkearde pakketôfhinklikens: lykas ferwachte wurde in pear pakketten brûkt troch in protte oare pakketten yn 'e distribúsje, dus kwetsberens yn dy selekteare pear binne heech risiko. As foarbyld lit de folgjende tabel de 20 pakketten mei it maksimale oantal reverse ôfhinklikens yn SLES, Centos 7, Debian 9 en Ubuntu 18.04 (elke sel jout it pakket en it oantal reverse ôfhinklikens oan).
Tabel 3
Ynteressant feit. Hoewol alle analysearre OS's binne boud foar de x86_64-arsjitektuer, en de measte pakketten hawwe de arsjitektuer definieare as x86_64 en x86, pakketten befetsje faak binaries foar oare arsjitektuer, lykas werjûn yn figuer 5. XNUMX.
Fig. 5
Yn 'e folgjende paragraaf sille wy dûke yn' e skaaimerken fan 'e analysearre binaries.
Statistiken foar binêre triembeskerming
Op it absolute minimum moatte jo in basis set fan befeiligingsopsjes ûndersykje foar jo besteande binaries. Ferskate Linux-distribúsjes komme mei skripts dy't sokke kontrôles útfiere. Bygelyks, Debian/Ubuntu hat sa'n skript. Hjir is in foarbyld fan syn wurk:
$ 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: yesIt skript kontrolearret fiif :
- Posysje ûnôfhinklik útfierber (PIE): jout oan oft de tekst seksje fan in programma kin wurde ferpleatst yn it ûnthâld te kommen ta randomization as ASLR is ynskeakele yn de kearn.
- Stapel beskerme: Oft stapelkanaries binne ynskeakele om te beskermjen tsjin oanfallen fan stapelbotsingen.
- Fersterkje Boarne: oft ûnfeilige funksjes (Bygelyks strcpy) wurde ferfongen troch harren feiliger tsjinhingers, en oproppen kontrolearre by runtime wurde ferfongen troch harren net kontrolearre tsjinhingers (Bygelyks memcpy ynstee fan __memcpy_chk).
- Allinnich-lêzen ferhuzingen (RELRO): Oft ferhuzing tabel yngongen wurde markearre allinnich-lêzen as se wurde trigger foar de útfiering begjint.
- Direkte bining: Oft de runtime-linker alle bewegingen tastean foardat de útfiering fan it programma begjint (dit is lykweardich oan in folsleine RELRO).
Binne de boppesteande meganismen genôch? Spitigernôch Nee. D'r binne bekende manieren om alle boppesteande ferdigeningen te omgean, mar hoe hurder de ferdigening, hoe heger de balke foar de oanfaller. Bygelyks, dreger om oan te passen as PIE en direkte bining yn wurking binne. Likemin fereasket folsleine ASLR ekstra wurk om in wurkjende eksploitaasje te meitsjen. Ferfine oanfallers binne lykwols al ree om te foldwaan oan sokke beskermingen: har ôfwêzigens sil de hack yn wêzen fersnelle. It is dêrom essinsjeel dat dizze maatregels nedich wurde achte minimum.
Wy woenen ûndersykje hoefolle binêre bestannen yn 'e kwestje binne beskerme troch dizze en trije oare metoaden:
- Unútfierbere bit () foarkomt útfiering yn elke regio dy't net útfierber wêze moat, lykas de stapelheap, ensfh.
- jout it útfieringspaad oan dat wurdt brûkt troch de dynamyske loader om oerienkommende biblioteken te finen. De earste is ferplicht foar elk modern systeem: it ûntbrekken dêrfan lit oanfallers de loadload eigenwillich yn it ûnthâld skriuwe en útfiere sa't it is. Foar de twadde, ferkearde konfiguraasjes foar útfieringspaad helpe by it yntrodusearjen fan ûnbetroubere koade dy't kin liede ta in oantal problemen (bgl. , lykas ek ).
- Stack botsing beskerming jout beskerming tsjin oanfallen dy't feroarsaakje de stack te oerlaapjen oare gebieten fan ûnthâld (lykas de heap). Sjoen resinte exploits misbrûk , fûnen wy dat it passend wie om dit meganisme op te nimmen yn ús dataset.
Dus, sûnder fierdere ado, litte wy nei de nûmers komme. Tabellen 4 en 5 befetsje in gearfetting fan de analyze fan útfierbere triemmen en bibleteken fan ferskate distribúsjes, respektivelik.
- Sa't jo sjen kinne, wurdt NX-beskerming oeral ymplementearre, mei seldsume útsûnderings. Benammen kin men it wat legere gebrûk yn Ubuntu en Debian-distribúsjes opmerke yn ferliking mei CentOS, RHEL en OpenSUSE.
- Stack kanaries ûntbrekke op in protte plakken, benammen yn distribúsjes mei âldere kernels. Guon foarútgong wurdt sjoen yn 'e lêste distribúsjes fan Centos, RHEL, Debian en Ubuntu.
- Mei útsûndering fan Debian en Ubuntu 18.04 hawwe de measte distribúsjes minne PIE-stipe.
- Stapelbotsingsbeskerming is swak yn OpenSUSE, Centos 7 en RHEL 7, en praktysk net-besteand yn oaren.
- Alle distribúsjes mei moderne kernels hawwe wat stipe foar RELRO, mei Ubuntu 18.04 foarop en Debian komt yn twadde.
Lykas al neamd, binne de metriken yn dizze tabel it gemiddelde foar alle ferzjes fan it binêre bestân. As jo allinich nei de lêste ferzjes fan bestannen sjogge, sille de nûmers oars wêze (sjoch bygelyks ). Boppedat testen de measte distribúsjes gewoanlik allinich de feiligens fan in pear funksjes yn 'e binêre by it berekkenjen fan statistiken, mar ús analyse lit it wiere persintaazje funksjes sjen dy't ferhurde binne. Dêrom, as 5 fan de 50 funksjes yn in binêr beskerme binne, jouwe wy it in skoare fan 0,1, wat oerienkomt mei 10% fan 'e funksjes dy't fersterke wurde.
Tabel 4. Feiligens skaaimerken foar de útfierbere triemmen werjûn yn Fig. 3 (ymplemintaasje fan relevante funksjes as persintaazje fan it totale oantal útfierbere bestannen)
Tabel 5. Feiligens skaaimerken foar de biblioteken werjûn yn Fig. 3 (ymplemintaasje fan relevante funksjes as persintaazje fan it totale oantal bibleteken)
Dus is d'r foarútgong? D'r is perfoarst: dit kin sjoen wurde út 'e statistiken foar yndividuele distribúsjes (bygelyks, ), lykas út 'e boppesteande tabellen. As foarbyld yn Fig. Ofbylding 6 toant de ymplemintaasje fan beskermingsmeganismen yn trije opienfolgjende distribúsjes fan Ubuntu LTS 5 (wy hawwe statistyk foar beskerming fan stapelbotsing wegere). Wy fernimme dat fan ferzje nei ferzje mear en mear bestannen stackkanaries stypje, en ek mear en mear binaries wurde ferstjoerd mei folsleine RELRO-beskerming.
Fig. 6
Spitigernôch hawwe in oantal útfierbere bestannen yn ferskate distribúsjes noch gjin ien fan 'e boppesteande beskermingen. As jo bygelyks nei Ubuntu 18.04 sjogge, sille jo de ngetty-binêre (in Getty-ferfanging) fernimme, lykas de mksh- en lksh-skelpen, de picolisp-tolk, de nvidia-cuda-toolkit-pakketten (in populêr pakket foar GPU-fersnelde applikaasjes lykas masine-learramen), en klibc -utils. Likegoed wurdt de binary mandos-client (in bestjoerlik ark wêrmei jo masines automatysk opnij starte kinne mei fersifere bestânsystemen) lykas rsh-redone-client (in werimplementaasje fan rsh en rlogin) sûnder NX-beskerming, hoewol se SUID-rjochten hawwe: (. Ek, Ferskate suid binaries misse basis beskerming lykas stack canaries (bygelyks, de Xorg.wrap binary út it Xorg pakket).
Gearfetting en ôfslutende opmerkingen
Yn dit artikel hawwe wy ferskate feiligensfunksjes fan moderne Linux-distribúsjes markearre. De analyze liet sjen dat de lêste Ubuntu LTS-distribúsje (18.04) yn trochsneed de sterkste OS- en applikaasjenivo-beskerming ymplementearret ûnder distribúsjes mei relatyf nije kernels, lykas Ubuntu 14.04, 12.04 en Debian 9. De ûndersochte distribúsjes CentOS, RHEL en OpenSUSE yn ús set produsearje standert in tichtere set fan pakketten, en yn 'e lêste ferzjes (CentOS en RHEL) hawwe se in heger persintaazje fan beskerming tsjin stapelbotsing yn ferliking mei Debian-basearre konkurrinten (Debian en Ubuntu). Fergelykjen fan CentOS- en RedHat-ferzjes fernimme wy grutte ferbetteringen yn 'e ymplemintaasje fan stackkanaries en RELRO fan ferzjes 6 oant 7, mar yn trochsneed hat CentOS mear funksjes ymplementearre as RHEL. Yn it algemien moatte alle distribúsjes spesjaal omtinken jaan oan PIE-beskerming, dy't, mei útsûndering fan Debian 9 en Ubuntu 18.04, yn minder dan 10% fan 'e binaries yn ús dataset ymplementearre is.
Uteinlik moat it wurde opmurken dat hoewol wy it ûndersyk mei de hân hawwe útfierd, d'r in protte befeiligingsark beskikber binne (bgl. , , ), dy't analyse útfiere en helpe ûnfeilige konfiguraasjes te foarkommen. Spitigernôch garandearret sels sterke beskerming yn ridlike konfiguraasjes de ôfwêzigens fan eksploaten net. Dêrom leauwe wy fêst dat it essensjeel is om te garandearjen , rjochte op patroanen fan eksploitaasje en it foarkommen fan har.
Boarne: www.habr.com