Meltdown ja Spectre ehk kuidas bittidega spekuleerida ja võõras mälus sobrada

Kuigi alguses oli jutt peamiselt Inteli protsessoritest, sai peagi selgeks, et ka teiste tootjate protsessorid on probleemist mõjutatud, kuigi oluliselt vähem kui Inteli toodetud.

Üldise meeleolu illustreerimiseks sobib kenasti video terasetehasest. Meie püüame olla need tegelased lõpukaadritest, kes paanikasse ei satu, toimuvat dokumenteerivad ja rahulikult tagajärgedega tegelemiseks valmistuvad 🙂

Nagu tänapäeval tavaline, said turvaprobleemid oma tavapärastele CVE numbritele lisaks nime, veebilehe jpms. Peamiselt ainult Intelit puudutav probleem sai nimeks Meltdown (CVE-2017-5754) ja kaasaegsete protsessorite enamust puudutav probleem on Spectre, millel on kaks variatsiooni (CVE-2017-5753 ja CVE-2017-5715).

Kui üritada seda ühe lausega öelda, siis mõlema näol on tegemist on nõrkustega, mis võimaldavad pahatahtlikel rakendustel spekulatiivselt koodi käivitatavate protsessorite disainiprobleeme ära kasutades lugeda seadmetes külgkanalründe abil mälu, millele nad tegelikult ligi pääseda ei tohiks. Kuidas saab protsessoris üldse selliseid vigu olla ning millega täpsemalt tegemist, on jäänud paljudele arusaamatuks.

Sõnad “külgkanalrünne protsessori spekulatiivse käivitusse realisatsioonide vastu” ei tee enamusele asja oluliselt selgemaks, kuid neile, kes huvi tunnevad, on postituse lõpus lihtsustatud kokkuvõte probleemi olemusest. Kõik, kel jõud ja mõistus üle käib, peaksid kindlasti läbi lugema probleemid avastanud teadlaste originaalartiklid.

Mida siis nende probleemide tõttu tegelikult teha saab?

Praktiliselt ainult Inteli protsessoreid puudutav Meltdown on kahest probleemist tõsisem – kui pahatahtlik rakendus saab seadmes ennast käivitada, siis sellest piisab, et kogu operatsioonisüsteemi tuuma kasutuses olevat mälu maha lugeda. Lugemine ei toimu küll eriti kiiresti, kuid piisavalt, et sellest edasiseks ründeks ära kasutatavaid andmeid (paroolid, krüptovõtmed jms) leida. Probleemi on võimalik vältida tarkvaraliste vahenditega ja tänase päeva (15.01.2018) seisuga on kõik peamised operatsioonisüsteemid (Windows, MacOSX, iOS, Linux, Android) ka turvapaigad väljastanud.

Spectre võimaldab pahatahtlikul rakendusel lugeda nii operatsioonisüsteemi tuuma kui ka teiste rakenduste mälu, kuid selle ära kasutamine on oluliselt keerulisem. Selleks ei piisa lihtsalt koodi käivitamisest – see eeldab ka konkreetsete ära kasutatavate koodimustrite olemasolu operatsioonisüsteemi tuumas või teistes rakendustes. Keerukam on ka Spectre mõjude kõrvaldamine ning see võtab veel aega. Üks Spectre variatsioonidest on ilmselt suhteliselt lihtsalt lahendatav operatsioonisüsteemi tuuma tasemel, kuid teise vastaste meetmete otsing veel käib. Praegu olemas olevad lahendused on väga kulukad – kas kannatab jõudlus väga palju või peaks kõik seadmetes olevad rakendused uue kompilaatoriga ringi kompileerima.

Arusaadaval põhjusel on eelkõige ohustatud keskkonnad, kus kasutajad saavad vabalt koodi käivitada – eelkõige jagatud serverid ning virtuaalmasinate keskkonnad. Virtuaalmasinate puhul võimaldavad need nõrkused kasutajal ka ennast virtuaalmasinast välja murda – lugeda hüperviisori ja teiste virtuaalmasinate mälu. Kuid ohus on ka kõik tavalised tööjaamad – probleeme uurinud eksperdid on tõestanud, et rünnak toimib ka JavaScripti kaudu. Praeguseks on kõik suuremad brauserid rakendanud meetmed, et veebi kaudu probleemide ära kasutamine oleks vähemalt hästi keeruline.

Suhteliselt pessimistliku kirjelduse peale tekib kindlasti küsimus, et kuhu poole nüüd paanikas jooksma peaks ja mida tegema? Ja miks see üleüldse nii kaua aega võtab?

Üks on selge – protsessoreid välja vahetama ei hakka ei Intel ega ka ükski teine tootja ning nendest probleemidest vabad protsessorid jõuavad meieni ilmselt alles järgmisel aastal. Kuid rahu, ainult rahu. Probleemid on vaatamata tõsidusele protsessoritootjate abiga tarkvaras lahendatavad ning kõigi arenduses olevate operatsioonisüsteemide arendajad on praegu ametis. Aega võtab see ka selle pärast, et olukord on väga paljudele uus – tarkvara ja riistvara tootjad peavad tegema koostööd ja üksteist ka usaldama. Ma olen kindel, et tsivilisatsioon ei kuku veel selle pärast kokku, kuid turvapaikade operatiivne paigaldamine on olulisem kui kunagi varem. Nagu juba eespool öeldud, on Meltdown praeguseks juba suuremates opsüsteemides paigatud ning kui sul on uuemad turvapaigad seadmetes, oled sa tõenäoliselt selle vastu juba kaitstud.

Oluline on ka mõista, et kui ründajal pole seadmes võimalik koodi käivitada, otsest ohtu pole. Mis ei tähenda muidugi seda, et esimesel võimalusel uuendamist siiski ette võtma ei peaks – Meltdown ja Spectre võivad olla osa keerulisemast ründest, kus mingi teise turvaprobleemi tõttu saavutatakse kõigepealt koodi käivitamise õigus.

Kuidas Meltdown ja Spectre Zone servereid mõjutavad?

Nii Virtuaalserverite kui Pilveserverite puhul jagab hulk kliente sama riistvaralist serverit ning turvaprobleemid, kus ühe kliendi serveris jooksev kood võib mõjutada teisi, on meie jaoks kõrgeima prioriteediga. Tänaseks on Zone serverid Meltdowni vastu kaitstud – enamus juba 06-08.01 nädalavahetusel.

Küll aga tuletame meelde, et Pilverserver PRO kasutajad peavad oma virtuaalmasinate kernelite uuendamise eest ise hoolt kandma (Pilveserver VPS kernelid uuendasime 07.01 varahommikul).

Meie tehnikud jälgivad sündmuste arenguid ja paigaldavad parandused ka Spectre vastu niipea kui võimalik. Võimalik, et selleks on vaja veel üht erakorralist hooldusakent.

Kas Meltdown’i paikamine mõjutas ka serverite töökiirust?

Paikade mõju sõltub rakendusteks, aga tavapärase veebirakenduse puhul on meie seninsed testid näidanud, et muutus on pea olematu. Tegime oma koormustestiks kasutatava WordPress+WooCommerce+WPML+Flatsome näidisrakendusega teste ning uurisime rakenduse tasemel monitooringus olevate veebide käitumist ning mingit mõõdetavat erinevust ei tuvastanud.

Küll aga on muutus näha Pilveserver VPS protsessori-aja kasutuses. Sellel pildil on üks hardware node, kus ilmselt VPSides jooksvate rakenduste eripärast lähtuvalt on syscall’ide osakaal märkimisväärne ja kasvab ca 2% pealt ca 10% peale:

Kuna enamikul ülejäänutest oli kasv oluliselt väiksem, tasub rakenduse töökiiruse muutumisel vaadata üle kõik syscall’e põhjustav ehk ennekõike IO, sh andmebaasikasutus. Selle osa optimeerimine on mõistlik ka ilma Meltdown ja Spectre paikade negatiivse mõju peale mõtlemata.

Trivialiseeritud Meltdown ehk “Kuidas lugeda võõrast mälu?”

Probleemide olemuse mõistmine pole tegelikult ühelegi programmeerimisega kokku puutunule üle jõu käiv, kuid illustreerib väga hästi külgkanalründe olemust. Alljärgnev on kõvasti lihtustatud versioon Meltdown probleemist. Kõigepealt räägime pisut kaasaegse protsessori tööst.

Kaasaegsed protsessorid on kiired, kuid mälust lugemine ja sinna kirjutamine ca 100x aeglasem. Et protsessor mälu taga pidevalt ootama ei peaks, on protsessoritel varuks hulga trikke, millest olulisimad on spekulatiivne käivitamine ja vahemälu.

Kui arvutitunnis räägiti teile, et protsessor käivitab ühe käsu teise järel, siis tänapäeval ei vasta see tihti enam tõele. Kuna protsessorid on mälust nii palju kiiremad, üritavad nad juhul, kui neil midagi targemat teha pole, järgmiseks käivitatavaid programmi harusid ette aimata ning selle töö ka igaks juhuks ette ära teha. Kui peaks juhtuma, et tõenäoline stsenaarium siiski ei realiseerunud, unustatakse see igaks juhuks ette tehtud töö tulemus lihtsalt ära. Kuna spekulatiivset tööd tehakse protsessori “vabast ajast”, ei muuda see midagi aeglasemaks, kuid kui stsenaarium realiseerub, on kiirusevõit oluline.

Võtame näiteks alltoodud veebilehe vaatamise pseudokoodi. Lehe kerimine on veebilehel oluliselt tõenäolisem sündmus kui lingile vajutamine ning protsessoril on kasulik see alati ette ära teha, isegi kui kasutaja veel kerimise liigutust teinud pole.

kui (kasutaja kerib lehte alla) {
  liigu rida allapoole;
} vastasel juhul kui (vajutatakse lingile) {
  liigu uuele lehele;
}

Sellisest spekulatiivsest käivitamisest poleks iseenesest aga väga palju kasu, sest suure tõenäosusega vajavad ka need käsud mälu poole pöördumist. Selle vältimiseks on protsessorites endis olemas hästi kiire vahemälu, kus hoitakse hiljuti kasutatud või sagedamini vaja minevaid andmeid neid mälust sinna portsu kaupa laadides. Kui protsessor vajab käsu täitmiseks andmeid mälust, laaditakse need vahemällu, kuhu need jäetakse ka pärast käsu täitmist – igaks juhuks, äkki läheb vaja.

Nüüd on meil olemas kõik põhiteadmised, et mõista alljärgnevat pseudokoodi. Pahatahtlik häkker soovib teada saada mis on mäluaadressi 0x200 vähima kaaluga biti väärtus. Rakendus ei saa seda mäluaadressi otseselt lugeda, kuid ta saab kirjutada sellise programmi.

kui (tingimus) {
  kui (aadressil 0x200 on 1) {
    loe väärtus aadressilt 0x800;
  } vastasel juhul {
    loe väärtus aadressilt 0x900;
  }
}
loe väärtus aadressilt 0x800;
mõõda eelmise käsu täitmiseks kulunud aeg;
loe väärtus aadressilt 0x900;
mõõda eelmise käsu täitmiseks kulunud aeg;

Protsessor täidab spekulatiivselt tingimuslaused ja kuigi selle käigus toimub lugemine aadressilt 0x200, millele pahatahtlik rakendus ei tohiks ligi saada, on see esmapilgul ohutu, sest protsessor on disainitud nii, et rakendus lõpetaks töö kohe, kui „tingimus“ peaks tõeks osutuma ja enne, kui 0x200 aadressilt lugemine rakenduseni reaalselt jõuaks. Sellel spekulatiivsel tingimuslausete täitmisel on aga kõrvalefekt – kas 0x800 või 0x900 aadress laaditakse protsessori vahemällu. Kui nüüd pärast seda mõõta 0x800 ja 0x900 aadresside lugemiseks kuluvat aega, on meil võimalik järeldada kas kumbki neist oli juba protsessori vahemälus olemas (kiire) või tuli seda mälust lugemas käia (aeglane) ning sellest järeldada aadressil 0x200 asuva biti väärtuse.

Tegelikult on probleemide olemus ja ära kasutamine muidugi märksa keerulisem, kuid põhimõte on just nii lihtne – pahatahtlik rakendus saab aja mõõtmise abil järeldada mis väärtused on mäluaadressidel, millele ta muidu ligi ei pääse. Kuna mäluaadresse otse ei loeta, vaid seal leiduva kohta tehakse järeldusi käskude käivitamiseks kulunud aega mõõtes, nimetataksegi selliseid ründeid külgkanalrünneteks (inglise keeles side-channel attack).