Olykor nehéz mit kezdeni azokkal a hírekkel, amik egy-egy hardverelemmel vagy szoftverrel kapcsolatos biztonsági kockázatról számolnak be. Az ember elolvassa és értelmezi a sorokat, netán még picit meg is lepődik, hogyan fordulhat elő ilyesmi, de aztán igazából nem tud érdemben erre mit reagálni. Nem azért, mert a legyintés korszakát éljük, és könnyebb a szőnyeg alá söpörni a problémákat, homokba dugni a fejet, hanem mert például egy processzorban felfedezett működésbeli hiba megoldására nincs saját, azonnal elérhető eszköztár. Nincs mit tenni, várni kell az iparági, gyártói reakcióra, ami jó esetben egy gyors és a működésre nézve fájdalommentes, szoftveres gyógymód, rosszabb esetben hosszú várakozás után kiadott félmegoldás.
A napi híreket figyelve most épp sem az AMD, sem az Intel nem panaszkodhat amiatt, ki kap a másiknál nagyobb médiavisszhangot. Mindkét vállalat esetében napvilágra került egy-egy súlyosabb hiba, amik jellegüket tekintve egy szimpla asztali PC esetén is komoly biztonsági kockázatot jelentenek. Ez a nyár a Zenbleed és a Downfall névre keresztelt sérülékenységekről szól, de mielőtt elmerülnénk a regisztertárakban, próbálunk választ adni arra a jogos kérdésre, hogyan fordulhatnak elő ilyen súlyos hibák az egyre modernebb tervezési- és gyártási folyamatok mellett?
Mindig is voltak és lesznek bugok
Egészen odáig elmehetnénk a gondolatmenetben, hogy azt fejtegetjük, az emberi tudás és akarat mennyi hibalehetőséget tartogat, és ehhez képest a mesterséges intelligencia minden bizonnyal hibamentes termékeket vésne papírra; nála nincs jobb bugirtó. No, ezt a gondolatcsírát itt most hagyjuk is elhalni, mert nem ezen múlik az, hogy az asztali gépedben vagy notebookodban, netán a munkahelyeden lévő szerverben üzemelő főbb hardverelemek miképp működnek megfelelően, vagy épp biztonsági kockázatot jelentenek az érzékeny adatokra.
A processzor-, illetve hardvertervezés és gyártás mindig is együtt járt hibákkal, sőt a Spectre-esemény kapcsán is több helyen olvashattál arról, hogy a kereskedelmi forgalomba szánt CPU-k sosem hibamentesek, a microarchitektúra fejlődése és a későbbi, leginkább szoftveres javítások tartják alacsonyan a működést érintő kockázati tényezőket. Legtöbb esetben a hibákat tekintve nem tehetünk különbséget a végfelhasználóknak vagy vállalatoknak szánt modellek között, az architektúra szintjén az alapok ma már többnyire megegyeznek. A kiszolgálóknál annyiban más a helyzet, hogy szerteágazóbb adatbiztonsági megoldásokkal igyekeznek elébe menni az ilyen és ehhez hasonló biztonsági problémáknak.
A számítási teljesítmény felgyorsítása érdekében a mérnökcsapatok számtalan eljárással, becslési lépcsőkkel próbálkoznak, amik a lehető legalacsonyabb késleltetésen és legrövidebb feldolgozási úton tartják a processzor általi parancsvégrehajtást. Ha csak egy részelemet emelünk ki, akkor magad is láthatod, hogy a többmagos felépítés, ráadásul annak hibrid, tehát eltérő funkcionalitású magokat tartalmazó verziója egészen komplex memóriafelépítést, cache-kialakítást igényel. Legyen minél több adat közel a számolóegységek számára, nanoszekundumok alatt ürülnek és töltődnek fel a KB/MB méretű ideiglenes tárak, közvetlen rendszermemória-elérésekkel, melyek akár egészen a videokártyáig és/vagy SSD-meghajtóig érnek. Gyorsabb adatáramlás több résztvevővel? Hát meg is lett ennek a böjtje.
Ijesztő, pedig a mérnököknek csak egy újabb nap az irodában
A Zenbleed és Downfall kapcsán nem egyértelmű, a gyártók mióta tudnak a hibáról, de beszédes, hogy az AMD a szerverprocesszoraihoz szinte azonnal elérhetővé tette a javítást. Az Intellel kapcsolatos hiba felbukkanására is már csak olyan vállalati reakció érkezett, ami a mikrokód-frissítés várható közeledtét jelzi; nincs itt semmi látnivaló, elég lesz BIOS-t frissíteni, és oszolhat a pánikoló tömeg.
Pedig a két sérülékenység a hivatalos leírás szerint nem csak olyan esetekben idézhet elő súlyos támadást, amikor a rosszindulatú egyén a konkrét gép mellett áll és a hibát előidéző programkóddal bombázza a rendszert. Sőt, igazából egészen kényelmesen támadható bármely rendszer, ami az AMD esetében a Zen 2 architektúrára épülő CPU-kat érinti. Elég egy megfelelően, spekulatív módon megírt javascript kódsor, ami a kellő időben, a kellő ütemezés mellett hajtja végre a sérülékenységben érintett regiszterek nullázását. A regiszterek rendelkezésre állása ugyanis kulcsfontosságú a teljesítmény szempontjából, az ún. vzeroupper utasítással teszi ezt meg a processzor, ha úgy véli, az abban tárolt adatra már nincs szükség. Az exploit ezzel szemben pont azt éri el, hogy a nullázást rossz utasításnak titulálja az adott CPU-mag, aminek köszönhetően az érintett regiszter tartalma újra olvashatóvá válik.
A módszer gyors és "halálos" a konkrét adatlopást és az adatok értékét tekintve, mert ezzel nemcsak személyes adatokat, titkosítatlan jelszavakat lophat el a rosszakaró, hanem teljes titkosítási kulcsokat is, amelyek egyszerű online fizetési folyamathoz vagy épp szerverautentikációhoz tartoznak. Mindegy, mit véd a titkosított adat, másodpercenként 30 KB sebességgel nyerhető ki, ami első hallásra nem tűnik soknak, de ha belegondolsz, hogy egy normál, 16 karakteres felhasználói jelszó sima szövegként mentve mekkora méretű, akkor bizony lehet aggódni.
A gyártói reagálás példaszerű abban a tekintetben, hogy az EPYC szerver CPU-k számára a javítás még aznap elérhetővé vált. Az asztali gépekbe és laptopokba szerelt típusok felhasználóinak viszont várnia kell egészen az év utolsó negyedévéig, ami minimum egy hónapnyi időtávot jelent a nyár végétől számítva, érdemes rendszeresen figyelni a partnergyártók weboldalait a javítást tartalmazó alaplapi BIOS-frissítések miatt. Ennyi, mehetünk tovább? Nos, ha félni nem is kell, megijedni pedig még annyira sem, azért nem lesz minden olyan, mint azelőtt.
Túl gyors volt? Le kell lassítani és jó lesz!
A Spectre/Meltdown kapcsán talán neked is az jut eszedbe először, hogy a hiba elvileg nagyon súlyosnak számított, amit végül úgy sikerült kijavítani, hogy a sérülékenységet előidéző működést tulajdonképpen egy lassítással oldották meg. A gyors parancsvégrehajtás, becslés és memóriabetöltés (adatcache) másképp megy végbe, ami miatt akár 40%-os teljesítményvesztés tapasztalható. A felhasználók többsége vélhetően rögtön akadozó játékokat és weboldalakat vizionált, valójában erről nem volt szó, csupán bizonyos, jelentős gyorsítótárhasználatot és párhuzamos programszálfuttatást igénylő programkódok esetén esik vissza a processzor teljesítménye. Típustól és órajeltől függ a csökkenés mértéke, a többség túltette magát ezen.
Az Intel garmadáját érintő Downfall hibajelentés mellett azonban ismét ez a tünetkezelés került elő, ami egyre rosszabb képet fest a Skylake-generációról, ami az alapjait tekintve a hatodiktól egészen a tizenegyes sorozatú Core processzorokig terjed. A közepes súlyosságúnak besorolt hiba hasonló ahhoz, amitől a Zen 2-es AMD lapkák szenvednek, csak épp más utasítás a ludas, aminek révén adatok nyerhetők ki a memóriaoptimalizálás érdekében felgyorsított működésű regiszterekből. A Gather névre keresztelt utasítás a gyorsabb adatmozgás érdekében a rendszermemóriában fellelhető adatok eléréseinek gyorsítását végzi, az arra célzott szoftverrel vagy programkóddal akaratlanul felfedve a vektorregiszterekben található adatokat. A támadható terület neve alapján beazonosítható, hogy a hiba kizárólag AVX és AVX-512 utasításkészletet használó alkalmazások futása során merülhet fel, és a sérülékenység súlyossága kizárólag azért maradt közepes besorolásban, mert a támadás csak helyben, az érintett gépre történő fizikai kapcsolattal valósítható meg.
Az Intel közlése szerint a hibajavításhoz elegendő egy mikrokódfrissítés, ami az érintett processzorokat támogató alaplap- és szervergyártóktól várható, azonban további szoftveres változtatásokra is szükség lehet annak érdekében, hogy az AVX-utasítások futása megfelelő teljesítményen, a hiba előtti szinten maradjon. Eléggé megrázó a százalékos adat, a gyártó akár 50%-os sebességvesztésről beszél, amit mindenképp érdemes szoftveres oldalon kezelni.
Ezek csak példák
A hardvervilág iránt érdeklődőkhöz hamar eljutott e két sebezhetőség híre, sőt, a Downfallról szóló híradásokkal egyidőben már egy másik AMD-sérülékenységre is fény derült, az Inception a Zen 3 és 4 architektúrákra épülő processzorokat érintő hiba, ami jogosulatlan folyamatok számára adhat ki adatokat hibás előrejelzés indításával. Ebben az esetben elméletileg nem kell teljesítményvesztéssel számolni a biztonsági rés befoltozása után, de azért várjuk meg a BIOS- és AGESA-frissítéseket.
Ezek tartják lázban épp a processzorok világát, de ez csak a felszín, a CVE-jelentések mindennaposak, legyen szó hardverről, operációs rendszerről, alkalmazásról, vagy csak szimpla adatkapcsolatról az eszközeid között. Felhasználói oldalról nézve az ezekkel kapcsolatos megértés és tudatos cselekvés várható el, avagy az untig ismételt biztonsági frissítések és óvatos online létezés a minimum, hogy túléljük a gombamód szaporodó réseket, az ezekre épülő töréseket, támadásokat.
Nem elég az erős jelszó
Ha annyit már megtanultál, hogy a születési dátum és háziállat neve nem elég erős jelszónak, akkor csak egy minimum lépést tettél meg annak érdekében, hogy ne legyél kibertámadás áldozata. Ne hollywoodi filmekre gondolj, amikor látványosan átveszik a géped felett az irányítást, és a szemed láttán tűnnek el az adatok; ennél sokkal kifinomultabb módszerek vannak, és bizony érdemes résen lenned.
Úgy érezheted, hogy ebben csak reaktív módon tudsz cselekedni, avagy amikor mondják, akkor odafigyelsz a frissítésekre, tanácsokra. Valójában az általános hozzáállás proaktív, hiszen nem az a dolgod, hogy figyeld a sajtót a CVE-bejelentések kapcsán, hanem tartsd frissen internetre csatlakozó eszközeid, figyelj oda arra, hol milyen adatokat tárolsz, és lehetőleg ne adj hozzáférést olyan "láthatatlan kibererőknek", akik épp a kártyaadataidra pályáznak. Zenbleed vagy Downfall, oly' mindegy, a gyártók résen vannak, Te se tégy másképp.
