{"id":29880,"date":"2019-10-31T21:32:27","date_gmt":"2019-10-31T18:32:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux\/"},"modified":"2019-10-31T21:32:27","modified_gmt":"2019-10-31T18:32:27","slug":"milliony-binarnikov-spustya-kak-ukreplyalsya-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Millionar av bin\u00e6rar seinare. Korleis Linux har styrkt seg","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MillionarTL;DR<\/b>. I denne artikkelen utforskar vi sikringsordningar (hardening schemes) som kjem standard i fem popul\u00e6re Linux-distribusjonar. For kvar av dei har vi brukt standard kjernekonfigurasjon, lasta ned alle pakkar og analysert sikringsskjemer i innbundne bin\u00e6rar. Vi vurderer distribusjonane OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 og 7, samt Ubuntu 14.04, 12.04 og 18.04 LTS. <\/p>\n

Resultata bekreftar at sj\u00f8lv grunnleggjande skjemer som stabelkanariar og posisjonsuavhengig kode, enno ikkje blir brukt av alle. Situasjonen er enda verre for kompilatorar n\u00e5r det kjem til \u00e5 sikre mot s\u00e5rbarheiter som stabelkollisjon (stack clash), som fekk oppmerksomheit i januar etter publiseringa av informasjon om s\u00e5rbarheiter i systemd<\/a><\/noindex>. Men ikkje alt er s\u00e5 h\u00e5plaust. I ein betydelig del av bin\u00e6rane er grunnleggjande sikre metodar implementert, og talet p\u00e5 desse auke fr\u00e5 versjon til versjon. <\/p>\n

Sjekken viste at det st\u00f8rste antallet sikre metodar er implementert i Ubuntu 18.04 p\u00e5 eit OS- og applikasjonsniv\u00e5, deretter kjem Debian 9. P\u00e5 den andere sida har OpenSUSE 12.4, CentOS 7 og RHEL 7 ogs\u00e5 basale sikringsordningar, og beskyttinga mot stabelkollisjon blir utnytta enda breiare med eit mykje tettare sett av pakkar som standard.
\n<\/a><\/noindex><\/p>\n

Innledning<\/h1>\n

\nDet er vanskeleg \u00e5 sikre h\u00f8g kvalitet p\u00e5 programvara. Til tross for det enorme antallet av avanserte verkt\u00f8y for statisk kodeanalyse og dynamisk analyse under kj\u00f8ring, samt betydelig framgang i utviklinga av kompilatorar og programmeringsspr\u00e5k, lider moderne programvare framleis av s\u00e5rbarheiter som stadig blir utnytta av angriparar. Situasjonen er enda meir prek\u00e6r i \u00f8kosystem som inkluderer foreldra kode. I slike tilfeller m\u00f8ter vi ikkje berre det evige problemet med \u00e5 finne potensielle utnyttbare feil, men ogs\u00e5 er vi avgrensa av strenge rammer for bakoverkompatibilitet som ofte krev at vi m\u00e5 bevare begrensa, og enda verre, s\u00e5rbar eller feilaktig kode.<\/p>\n

Her kjem sikringsmetodane eller forsterkende program (hardening) inn i spelet. Nokre typar feil kan vi ikkje forhindre, men vi kan gjere livet til angriparen meir komplisert og delvis l\u00f8yse problemet ved \u00e5 forhindre eller hindre utnyttelse<\/i> disse feilene. Slik beskyttelse brukes i alle moderne operativsystemer, men metodene varierer sterkt i kompleksitet, effektivitet og ytelse: fra stakkens kanarifugler (stack canaries) og ASLR<\/a><\/noindex> til fullverdige beskyttelser CFI<\/a><\/noindex> og ROP<\/a><\/noindex>. I denne artikkelen vil vi se p\u00e5 hvilke beskyttelsesmetoder som brukes i de mest popul\u00e6re Linux-distribusjonene med standardkonfigurasjon, samt unders\u00f8ke egenskapene til bin\u00e6rfiler som distribueres gjennom pakkebehandlingssystemene til hver distribusjon.<\/p>\n

CVE og sikkerhet<\/h3>\n

\nVi har alle sett artikler med titler som \u00abDe mest s\u00e5rbare applikasjonene i \u00e5ret\u00bb eller \u00abDe mest s\u00e5rbare operativsystemene\u00bb. Vanligvis presenteres det statistikk over det totale antallet registreringer av s\u00e5rbarheter av typen CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, hentet fra Nasjonal s\u00e5rbarhetsdatabase (NVD)<\/a><\/noindex> fra NIST<\/a><\/noindex> og andre kilder. Senere rangeres disse applikasjonene eller OSene ut fra antall CVE. Dessverre, selv om CVE er sv\u00e6rt nyttige for \u00e5 redusere problemer og informere leverand\u00f8rer og brukere, sier de lite om den faktiske sikkerheten til programvaren.<\/p>\n

Som et eksempel kan vi se p\u00e5 det totale antallet CVE de siste fire \u00e5rene for Linux-kjernen og de fem mest popul\u00e6re serverdistribusjonene, nemlig Ubuntu, Debian, Red Hat Enterprise Linux og OpenSUSE.<\/p>\n

\"Millionar
\nFig. 1<\/i><\/p>\n

Hva forteller denne grafen oss? Betyr et h\u00f8yere antall CVE at en distribusjon er mer s\u00e5rbar enn en annen? Svaret er nei. For eksempel, i denne artikkelen vil du se at Debian har implementert strengere beskyttelsesmekanismer sammenlignet med for eksempel OpenSUSE eller RedHat Linux, og allikevel har Debian flere CVE. Men de betyr ikke n\u00f8dvendigvis svekket sikkerhet: selv tilstedev\u00e6relsen av CVE sier ikke noe om en s\u00e5rbarhet er utnyttbar<\/i>. Alvorlighetsgradsratinger gir en indikasjon p\u00e5 hvor sannsynlig<\/i> det er at en s\u00e5rbarhet blir utnyttet, men til syvende og sist avhenger utnyttbarheten i stor grad av beskyttelsen som er til stede i de ber\u00f8rte systemene, samt ressursene og evnene til angriperne. Videre sier frav\u00e6ret av CVE-rapporter ikke noe om andre uregistrerte eller ukjente<\/i> Sikkerhetsproblemer. Forskjellen i CVE kan forklares ikke med kvaliteten p\u00e5 programvaren, men med andre faktorer, inkludert ressursene som er avsatt til testing, eller st\u00f8rrelsen p\u00e5 brukerbasen. I v\u00e5rt eksempel kan et h\u00f8yere antall CVE hos Debian bare indikere at Debian leverer flere programvarepakker. <\/p>\n

Selvf\u00f8lgelig gir CVE-systemet nyttig informasjon som muliggj\u00f8r utvikling av passende beskyttelser. Jo bedre vi forst\u00e5r \u00e5rsakene til programfeil, desto enklere er det \u00e5 identifisere mulige utnyttelsesmetoder og utvikle relevante mekanismer for oppdagelse og respons.<\/i>Fig. 2 viser kategoriene av s\u00e5rbarheter for alle distribusjoner de siste fire \u00e5rene (kilde<\/a><\/noindex>). Det er umiddelbart synlig at de fleste CVE faller innenfor f\u00f8lgende kategorier: tjenestenekt (DoS), kodegjennomf\u00f8ring, buffer-overl\u00f8p, minneskade, lekkasje (eksfiltrering) av informasjon og privilegieheving. Selv om mange CVE er registrert flere ganger under forskjellige kategorier, forblir de samme problemene generelt \u00e5r etter \u00e5r. I neste del av artikkelen vil vi vurdere bruken av forskjellige beskyttelsesskjemaer for \u00e5 forhindre utnyttelse av de nevnte s\u00e5rbarhetene.<\/p>\n

\"Millionar
\nFig. 2<\/i><\/p>\n

Oppgaver<\/h3>\n

\nI denne artikkelen har vi til hensikt \u00e5 svare p\u00e5 f\u00f8lgende sp\u00f8rsm\u00e5l:<\/p>\n