Kaip dvi savaitės branduolio klaidų atėmė šarvus iš saugiausios pasaulyje operacinės sistemos

Šiuolaikinio įmonių saugumo ironija yra ta, kad mes išleidžiame milijonus dolerių perimetro gynybai — naujos kartos ugniasienėms, dirbtiniu intelektu pagrįstai srauto analizei ir biometriniams prieigos taškams — tik tam, kad viską sugriautų viena neteisinga nuoroda operacinės sistemos branduolyje. Tai didžiausias architektūrinis paradoksas: pats pagrindas, kuriuo pasitikime užtikrindami izoliaciją ir saugumą, dažnai yra sudėtingiausia ir pažeidžiamiausia sistemos dalis. Šį mėnesį „Linux“ bendruomenė grumiasi su šia realybe, nes praėjus vos keturiolikai dienų po to, kai ankstesnė kritinė klaida privertė sistemų administratorius skubiai ieškoti pataisų valdymo įrankių, iškilo antras sunkus pažeidžiamumas.

Žvelgiant iš rizikos perspektyvos, tai nėra tik nesėkmių ruožas. Tai didėjančio „Linux“ branduolio sudėtingumo simptomas, kurį dabar sudaro daugiau nei 30 milijonų kodo eilučių. Praėjusią savaitę, kai per „Signal“ skambutį aptarinėjau pirminius padarinius su kolega tyrėju, mes abu įtarėme, kad netrukus pasirodys ir kita bloga žinia. Greitis, kuriuo saugumo tyrėjai ir piktavaliai dabar audituoja pagrindines posistemes, tokias kaip io_uring ir eBPF, pavertė branduolį didelių statymų mūšio lauku. Todėl tai, ką matome dabar, nėra atskiras incidentas, o sisteminis iššūkis suvokiamam atvirojo kodo flagmano nenugalimumui.

Dvigubas smūgis: atakos paviršiaus įvertinimas

Pirmasis pažeidžiamumas, iškilęs balandžio pabaigoje, buvo nutaikytas į lenktynių sąlygą (angl. race condition) atminties valdymo posistemėje. Jis leido vietiniam vartotojui stebėtinai lengvai gauti šaknines (root) teises. Kol didžioji pramonės dalis vis dar tikrino savo švelninimo strategijas šiam incidentui, šią savaitę atsirado nauja grėsmė. Šis antrasis pažeidžiamumas yra bene pavojingesnis, nes jis slypi tinklo steko paketų apdorojimo logikoje, potencialiai atverdamas duris nuotoliniam išnaudojimui specifinėse, nors ir sudėtingose, konfigūracijose.

Architektūriniu lygmeniu šie du trūkumai atstovauja skirtingų tipų klaidoms. Pirmoji buvo loginė klaida — sistemos nesugebėjimas teisingai sekti atminties puslapių būsenos. Tačiau antroji yra klasikinė atminties sugadinimo problema. Užkulisiuose pažeidžiamumas suaktyvinamas, kai branduolys apdoroja specialiai suformuotas tinklo antraštes, o tai sukelia buferio perpildymą, kuris gali perrašyti gretimą branduolio atmintį. Atakos paviršiaus įvertinimas šiame kontekste yra blaivinantis; bet kuri sistema, kurioje veikia šiuolaikinis branduolys su įjungtomis specifinėmis tinklo funkcijomis, teoriškai yra pasiekiama piktavaliams.

Duomenų vientisumo požiūriu rizika yra absoliuti. Kai užpuolikas įgyja branduolio lygio vykdymo teises, C-I-A triada — konfidencialumas, vientisumas ir prieinamumas — faktiškai nustoja egzistuoti. Branduolys yra galutinis tiesos arbitras sistemoje. Jei jis yra pažeistas, atmintyje saugomi šifravimo raktai, apriboti failai diske ir konteinerių izoliacija nebėra garantuojami.

Naujosios klaidos anatomija

Norėdami suprasti, kodėl ši antroji klaida yra tokia paplitusi, turime pažvelgti į tai, kaip „Linux“ branduolys valdo didelės spartos duomenis. Tikimasi, kad šiuolaikiniai serveriai apdoros milijonus paketų per sekundę. Norėdami tai pasiekti, branduolys naudoja itin optimizuotą, žemo lygio C kodą, kuris dažnai apeina tradicines saugos patikras, kad sumažintų delsą. Žvelgiant į grėsmių kraštovaizdį, šios „našumas bet kokia kaina“ kodo sritys yra būtent tos vietos, kur linkę slėptis patys slapčiausi pažeidžiamumai.

Įsivaizduokite branduolį kaip laivo korpusą. Metų metus mes stiprinome plieną, darėme jį storesnį ir atsparesnį išoriniam spaudimui. Tačiau, kad laivas būtų greitesnis, mes įrengėme sudėtingas vamzdžių ir vožtuvų sistemas, kurios driekiasi per visą konstrukciją. Dabartinis pažeidžiamumas yra sugedęs vožtuvas. Jis puikiai veikia esant normaliam slėgiui, tačiau jei piktavalis per sistemą paleidžia tam tikrą skysčių seką, vožtuvas sugenda, sukeldamas nuotėkį, kuris galiausiai gali nuskandinti visą laivą. Atmetus pataisymus, pagrindinė problema yra ta, kad kuo sudėtingesnė santechnika, tuo didesnė katastrofiško gedimo tikimybė.

Atlikdamas savo teismo ekspertizės analizę, susijusią su preliminariu išnaudojimo kodu, kuriuo buvo dalijamasi privačiuose etinių įsilaužėlių ratuose, buvau sukrėstas atakos elegancijos. Ji nesiremia dideliu, triukšmingu duomenų srautu. Vietoj to naudojamas granuliuotas požiūris, lėtai sugadinant po vieną atminties baitą, kol branduolio vidinės saugumo struktūros perkonfigūruojamos taip, kad užpuolikui būtų suteikta visiška kontrolė. Tai labiau chirurginis smūgis, o ne buko objekto trauma.

Dviejų savaičių klaidų palyginimas

Norėdami geriau suprasti bendrą riziką, galime palyginti šių dviejų viena po kitos sekusių pažeidžiamumų charakteristikas. Nors abu sukelia visišką sistemos suvereniteto praradimą, jų patekimo taškai ir reikalavimai gerokai skiriasi.

Galutinio vartotojo požiūriu, skirtumas tarp vietinio ir nuotolinio gali atrodyti akademinis, jei jūsų mašina jau yra pažeista. Tačiau saugumo operacijų centro (SOC) analitikui nuotolinis vektorius pakeičia prioriteto lygį iš „kritinio“ į „katastrofišką“. Kalbant proaktyviai, antroji klaida panaikina pradinio įsitvirtinimo poreikį, leisdama užpuolikui iš viešojo interneto šokti tiesiai į infrastruktūros širdį.

Žmogiškasis faktorius ir nulinio pasitikėjimo iliuzija

Mes dažnai kalbame apie nulinį pasitikėjimą (angl. zero trust) kaip apie VIP klubo apsauginį prie kiekvienų vidinių durų, kuris niekada nepasitiki ir visada tikrina. Tai tvirta filosofija, tačiau ji remiasi tuo, kad pats apsauginis yra nepaperkamas. Šie branduolio pažeidžiamumai įrodo, kad jei paties apsauginio smegenys — operacinė sistema — yra pažeistos, durys faktiškai lieka atviros. Apsauginis vis dar gali tikrinti ID, bet užpuolikas jau perrašė svečių sąrašą.

Tai pabrėžia kritinę tiesą: programinę įrangą rašo žmonės, o žmonės daro klaidas. Net ir taikant griežtus kodo peržiūros procesus bei automatizuotą testavimą, klaidų išliks. Decentralizuotas „Linux“ kūrimo pobūdis yra didžiausia jo stiprybė, nes leidžia sparčiai diegti naujoves ir pritraukti įvairių talkininkų. Tačiau tai taip pat yra sisteminės rizikos šaltinis, kai giliai techniniai pakeitimai sujungiami pilnai nesuvokiant jų saugumo pasekmių visai ekosistemai.

Prisimenu pokalbį su pagrindiniu branduolio prižiūrėtoju prieš kelerius metus, kuris man pasakė, kad kiekvieną kartą, kai jie prideda funkciją, pagerinančią našumą 1 %, jie padidina atakos paviršių 5 %. Ši matematika nepasikeitė. Siekdami labiau keičiamo dydžio ir kritinės svarbos programų, mes nevalingai statome savo skaitmeninius bokštus ant vis labiau netvirto pagrindo.

Daugiau nei tik reaktyvus lopymas

Atsiradus dideliam pažeidžiamumui, standartinis patarimas visada yra nedelsiant įdiegti pataisą. Nors tai būtina, tai yra reaktyvi pozicija. Įsilaužimo atveju laukti tiekėjo atnaujinimo yra prabanga, kurios dauguma organizacijų negali sau leisti. Turime judėti link atsparesnių architektūrų, kurios daro prielaidą, kad branduolys gali būti pažeistas.

Vienas iš būdų yra technine įranga pagrįsta izoliacija, pavyzdžiui, konfidencialioji kompiuterija ir saugūs anklavai. Šifruodami duomenis net tada, kai juos naudoja procesorius, galime apsaugoti jautrią informaciją nuo piktavališko branduolio. Kita strategija apima detalesnį izoliavimą (angl. sandboxing). Jei programa yra izoliuota taip, kad ji negali net sąveikauti su pažeidžiamomis branduolio posistemėmis, išnaudojimas tampa nebeaktualus. Standartiškai dauguma „Linux“ distribucijų nėra taip sukonfigūruotos; jos teikia pirmenybę suderinamumui ir naudojimo paprastumui, o ne maksimaliam saugumui.

Be to, turėtume atkreipti dėmesį į atminties požiūriu saugių kalbų, tokių kaip „Rust“, kilimą „Linux“ branduolio projekte. Tai ilgalaikis projektas, tačiau jis sprendžia pagrindinę daugelio šių problemų priežastį: būdingą rankinio atminties valdymo pavojų C kalboje. Pagal savo konstrukciją „Rust“ užkerta kelią daugeliui buferio perpildymo ir „use-after-free“ klaidų, kurios dešimtmečius kankino branduolį. Tai nėra stebuklinga piliulė, bet tai labai reikalingas mūsų skaitmeninio įrankių rinkinio atnaujinimas.

Pagrindinės įžvalgos IT ir saugumo vadovams

• Teikite pirmenybę kraštui: Nors visas sistemas reikia lopyti, pirmiausia susikoncentruokite į viešai prieinamus serverius ir krašto įrenginius, kurie yra jautrūs nuotolinio tinklo klaidai.
• Audituokite branduolio modulius: Išjunkite visus nereikalingus branduolio modulius (pvz., nenaudojamas failų sistemos tvarkykles ar eksperimentines tinklo funkcijas), kad sumažintumėte prieinamą atakos paviršių.
• Įdiekite mikro-segmentaciją: Nepasikliaukite branduoliu, kad užtikrintumėte visišką izoliaciją tarp konteinerių. Naudokite tinklo lygio segmentaciją, kad išvengtumėte šoninio judėjimo, jei vienas mazgas būtų pažeistas.
• Stebėkite anomalijas: Naudokite eBPF pagrįstus saugumo įrankius (ironiška, tą pačią posistemę, kuri dažnai yra klaidų šaltinis), kad stebėtumėte neįprastą branduolio lygio veiklą, pavyzdžiui, neteisėtus privilegijų pasikeitimus.
• Peržiūrėkite savo gyvavimo ciklą: Jei jūsų organizacija vis dar naudoja „ilgalaikio palaikymo“ (LTS) branduolius, kuriems yra keleri metai, įsitikinkite, kad jie gauna perkeltus saugumo pataisymus šiems konkretiems CVE.

Strateginė gynyba trapioje ekosistemoje

Žvelgiant į ateitį, šių „sunkių“ „Linux“ klaidų dažnumas turėtų tapti žadintuvu. Gyvename eroje, kai tinklo perimetras yra pasenęs pilies griovys, o tikroji gynyba vyksta atskirų sistemos iškvietimų ir atminties priskyrimų lygmeniu. Kova už saugumą keliasi giliau į sistemą, o mūsų gynybinės strategijos turi sekti iš paskos.

Raginu kiekvieną skaitytoją vertinti šiuos incidentus ne kaip atskiras antraštes, o kaip paskatą atlikti išsamų savo „Linux“ infrastruktūros rizikos vertinimą. Ne tik įdiekite pataisą; paklauskite, kodėl pažeidžiamumas jūsų aplinkoje apskritai buvo išnaudojamas. Ar veikė nereikalingos paslaugos? Ar jūsų stebėjimo sistema sugebėjo aptikti išnaudojimą? Tikrasis atsparumas atsiranda suprantant „kaip“, o ne tik „kas“.

Šaltiniai:

• NIST National Vulnerability Database (NVD)
• MITRE ATT&CK Framework: Software Process Discovery (T1012) and Exploitation for Privilege Escalation (T1068)
• Linux Kernel Organization (kernel.org) Security Advisories
• Open Source Security Foundation (OpenSSF) Best Practices

Atsakomybės apribojimas: Šis straipsnis yra skirtas tik informaciniams ir švietimo tikslams. Jis nepakeičia profesionalaus kibernetinio saugumo audito, teismo ekspertizės analizės ar reagavimo į incidentus paslaugų. Prieš atlikdami reikšmingus gamybinės infrastruktūros pakeitimus, visada pasitarkite su sertifikuotais saugumo specialistais.