{"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\/sv\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Miljontals bin\u00e4rer senare. Hur Linux bef\u00e4stes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MiljontalsTL;DR<\/b>. I denna artikel utforskar vi h\u00e5rdningsscheman (hardening schemes) som fungerar fr\u00e5n start i fem popul\u00e4ra Linux-distributioner. F\u00f6r varje har vi tagit standard k\u00e4rnkonfigurationen, laddat ner alla paket och analyserat skyddsscheman i de inb\u00e4ddade bin\u00e4ra filerna. Distributioner som behandlas \u00e4r OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 och 7 samt Ubuntu 14.04, 12.04 och 18.04 LTS. <\/p>\n

Resultaten bekr\u00e4ftar att \u00e4ven grundl\u00e4ggande scheman, s\u00e5som stack Canary och positionoberoende kod, fortfarande inte anv\u00e4nds av alla. Situationen \u00e4r \u00e4nnu v\u00e4rre f\u00f6r kompilatorer n\u00e4r det kommer till skydd mot s\u00e5rbarheter som stack clash, som kom i fokus i januari efter publiceringen av information om s\u00e5rbarheter i systemd<\/a><\/noindex>. Men allt \u00e4r inte hoppl\u00f6st. En betydande del av bin\u00e4ra filer implementerar grundl\u00e4ggande skydds\u00e5tg\u00e4rder, och antalet \u00f6kar fr\u00e5n version till version. <\/p>\n

Kontrollen visade att flest skydds\u00e5tg\u00e4rder har implementerats i Ubuntu 18.04 p\u00e5 OS- och applikationsniv\u00e5, f\u00f6ljt av Debian 9. \u00c5 andra sidan \u00e4r grundl\u00e4ggande skyddsscheman ocks\u00e5 implementerade i OpenSUSE 12.4, CentOS 7 och RHEL 7, medan skydd mot stack clash till\u00e4mpas \u00e4nnu mer utbrett med en mycket t\u00e4tare upps\u00e4ttning standardpaket.
\n<\/a><\/noindex><\/p>\n

Introduktion<\/h1>\n

\nDet \u00e4r sv\u00e5rt att s\u00e4kerst\u00e4lla h\u00f6g kvalitet p\u00e5 programvara. Trots det stora antalet avancerade verktyg f\u00f6r statisk kodanalys och dynamisk analys under k\u00f6rning, samt betydande framsteg inom kompilatorer och programmeringsspr\u00e5k, lider modern mjukvara fortfarande av s\u00e5rbarheter som st\u00e4ndigt utnyttjas av angripare. Situationen \u00e4r \u00e4nnu sv\u00e5rare i ekosystem som inkluderar gammal kod. I s\u00e5dana fall st\u00e5r vi inte bara inf\u00f6r det eviga problemet med att hitta potentiellt exploaterbara fel, utan vi \u00e4r ocks\u00e5 begr\u00e4nsade av strikta krav p\u00e5 bak\u00e5tkompatibilitet som ofta tvingar oss att beh\u00e5lla begr\u00e4nsad, och \u00e4nnu v\u00e4rre, s\u00e5rbar eller buggig kod.<\/p>\n

H\u00e4r kommer skyddsmetoder eller h\u00e5rdning (hardening) in i bilden. Vissa typer av fel kan vi inte f\u00f6rhindra, men vi kan g\u00f6ra livet sv\u00e5rare f\u00f6r angriparen och delvis l\u00f6sa problemet genom att f\u00f6rhindra eller hindra. utnyttjande<\/i> dessa fel. Detta skydd anv\u00e4nds i alla moderna operativsystem, men metoderna skiljer sig mycket \u00e5t n\u00e4r det g\u00e4ller komplexitet, effektivitet och prestanda: fr\u00e5n stackcanaries och ASLR<\/a><\/noindex> till fullv\u00e4rdigt skydd CFI<\/a><\/noindex> och ROP<\/a><\/noindex>. I denna artikel kommer vi att titta p\u00e5 vilka skydds\u00e5tg\u00e4rder som anv\u00e4nds i de mest popul\u00e4ra Linux-distributionerna i standardkonfigurationen, samt unders\u00f6ka egenskaperna hos de bin\u00e4ra filer som distribueras via pakethanteringssystemen f\u00f6r varje distribution.<\/p>\n

CVE och s\u00e4kerhet<\/h3>\n

\nVi har alla sett artiklar med titlar som \"De mest s\u00e5rbara programvarorna under \u00e5ret\" eller \"De mest s\u00e5rbara operativsystemen\". Vanligtvis presenteras statistik \u00f6ver det totala antalet poster f\u00f6r s\u00e5rbarheter av typen CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, erh\u00e5llna fr\u00e5n Nationella s\u00e5rbarhetsdatabasen (NVD)<\/a><\/noindex> fr\u00e5n NIST<\/a><\/noindex> och andra k\u00e4llor. Dessa program eller operativsystem rangordnas senare efter antalet CVE. Tyv\u00e4rr, \u00e4ven om CVE \u00e4r mycket anv\u00e4ndbara f\u00f6r att sp\u00e5ra problem och informera leverant\u00f6rer och anv\u00e4ndare, s\u00e4ger de lite om den verkliga s\u00e4kerheten hos programvaran.<\/p>\n

Som ett exempel, l\u00e5t oss betrakta det totala antalet CVE de senaste fyra \u00e5ren f\u00f6r Linux-k\u00e4rnan och fem av de mest popul\u00e4ra serverdistributionerna, n\u00e4mligen Ubuntu, Debian, Red Hat Enterprise Linux och OpenSUSE.<\/p>\n

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

Vad s\u00e4ger denna graf oss? Betyder ett h\u00f6gre antal CVE att en distribution \u00e4r mer s\u00e5rbar \u00e4n en annan? Svaret \u00e4r nej. Till exempel kommer du i denna artikel att se att Debian har mer strikta skyddsmekanismer j\u00e4mf\u00f6rt med OpenSUSE eller RedHat Linux, och \u00e4nd\u00e5 har Debian fler CVE. Men det betyder inte n\u00f6dv\u00e4ndigtvis en f\u00f6rsvagad s\u00e4kerhet: att ha CVE betyder inte om en s\u00e5rbarhet \u00e4r utnyttjad<\/i>. Allvarlighetsgrader ger en uppfattning om hur sannolikt<\/i> det \u00e4r att utnyttja en s\u00e5rbarhet, men i slut\u00e4ndan beror utnyttjande i stor utstr\u00e4ckning p\u00e5 det skydd som finns i de drabbade systemen samt p\u00e5 resurser och m\u00f6jligheter f\u00f6r angriparna. Dessutom s\u00e4ger avsaknaden av CVE-rapporter ingenting om andra oregistrerande eller ok\u00e4nda<\/i> S\u00e5rbarheter. Skillnaden i CVE kan f\u00f6rklaras av inte bara mjukvarukvaliteten utan ocks\u00e5 av andra faktorer, inklusive resurser som avsatts f\u00f6r testning eller storleken p\u00e5 anv\u00e4ndarbasen. I v\u00e5rt exempel kan det st\u00f6rre antalet CVE i Debian helt enkelt indikera att Debian tillhandah\u00e5ller fler programvarupaket. <\/p>\n

Sj\u00e4lvklart ger CVE-systemet anv\u00e4ndbar information som g\u00f6r det m\u00f6jligt att skapa adekvata skydd. Ju b\u00e4ttre vi f\u00f6rst\u00e5r orsakerna till programvarufel, desto enklare blir det att identifiera potentiella utnyttjanden och utveckla motsvarande mekanismer. f\u00f6r uppt\u00e4ckte och respons<\/i>. P\u00e5 figur 2 visas kategorier av s\u00e5rbarheter f\u00f6r alla distributioner under de senaste fyra \u00e5ren (ClickHouse-Ninja\/Proton<\/a><\/noindex>). Det framg\u00e5r tydligt att de flesta CVE faller inom f\u00f6ljande kategorier: DoS (Denial of Service), kodexekvering, buffert\u00f6verskridning, minneskorruption, l\u00e4ckage (utexfiltrering) av information och privilegief\u00f6rh\u00f6jning. \u00c4ven om m\u00e5nga CVE redovisas flera g\u00e5nger i olika kategorier kvarst\u00e5r generellt samma problem \u00e5r efter \u00e5r. I n\u00e4sta del av artikeln kommer vi att utv\u00e4rdera anv\u00e4ndningen av olika skyddsscheman f\u00f6r att f\u00f6rhindra exploatering av de angivna s\u00e5rbarheterna.<\/p>\n

\"Miljontals
\nFigur 2<\/i><\/p>\n

Uppgifter<\/h3>\n

\nI den h\u00e4r artikeln avser vi att svara p\u00e5 f\u00f6ljande fr\u00e5gor:<\/p>\n