Kā divas nedēļas ar kodola ievainojamībām atņēma bruņas pasaules drošākajai operētājsistēmai

Mūsdienu uzņēmumu drošības ironija ir tāda, ka mēs tērējam miljoniem dolāru perimetra aizsardzībai — nākamās paaudzes ugunsmūriem, AI vadītai trafika analīzei un biometriskajiem piekļuves punktiem —, lai mūs pieviltu viens vienīgs nevietā novietots rādītājs operētājsistēmas kodolā. Tas ir galējais arhitektūras paradokss: pats pamats, kuram mēs uzticamies, lai nodrošinātu izolāciju un drošību, bieži vien ir vissarežģītākā un neaizsargātākā sistēmas daļa. Šomēnes Linux kopiena cīnās ar šo realitāti, jo ir parādījusies otrā smagā ievainojamība tikai četrpadsmit dienas pēc tam, kad iepriekšējais kritiskais trūkums lika sistēmu administratoriem steigšus meklēt ielāpu pārvaldības rīkus.

No riska perspektīvas raugoties, tā nav tikai neveiksmju sērija. Tas ir simptoms pieaugošajai Linux kodola sarežģītībai, kas tagad sastāv no vairāk nekā 30 miljoniem koda rindu. Pagājušajā nedēļā, kad es apspriedu sākotnējās sekas ar kolēģi pētnieku Signal zvanā, mēs abi aizdomājāmies, ka drīz sekos nākamais trieciens. Ātrums, ar kādu drošības pētnieki un ļaundari tagad auditē tādas galvenās apakšsistēmas kā io_uring un eBPF, ir pārvērtis kodolu par augstu likmju kaujas lauku. Līdz ar to tas, ko mēs redzam tagad, nav izolēts gadījums, bet gan sistēmisks izaicinājums atvērtā pirmkoda flagmaņa šķietamajai neievainojamībai.

Dubultais trieciens: uzbrukuma virsmas novērtēšana

Pirmā ievainojamība, kas parādījās aprīļa beigās, bija vērsta uz sacensības apstākļiem (race condition) atmiņas pārvaldības apakšsistēmā. Tā ļāva lokālajam lietotājam ar pārsteidzošu vieglumu iegūt root privilēģijas. Kamēr lielākā daļa nozares vēl pārbaudīja savas mazināšanas stratēģijas šim incidentam, šonedēļ parādījās jauns apdraudējums. Šī otrā ievainojamība, iespējams, ir bīstamāka, jo tā atrodas tīkla steka pakešu apstrādes loģikā, potenciāli atverot durvis attālinātai izmantošanai specifiskās, lai arī sarežģītās konfigurācijās.

Arhitektūras līmenī šie divi trūkumi pārstāv dažādus kļūmju veidus. Pirmais bija loģikas kļūda — kļūme tajā, kā sistēma izseko atmiņas lapu stāvokli. Otrais tomēr ir klasiska atmiņas korupcijas problēma. Aizkulisēs ievainojamība tiek aktivizēta, kad kodols apstrādā īpaši izveidotas tīkla galvenes, izraisot bufera pārpildi, kas var pārrakstīt blakus esošo kodola atmiņu. Uzbrukuma virsmas novērtēšana šajā kontekstā ir satraucoša; jebkura sistēma, kurā darbojas moderns kodols ar iespējotām specifiskām tīkla funkcijām, teorētiski ir sasniedzama ekspluatācijai.

Datu integritātes ziņā risks ir absolūts. Tiklīdz uzbrucējs iegūst kodola līmeņa izpildes tiesības, CIA triāde — konfidencialitāte, integritāte un pieejamība — faktiski tiek iznīcināta. Kodols ir galvenais patiesības arbitrs sistēmā. Ja tas tiek kompromitēts, atmiņā saglabātās šifrēšanas atslēgas, ierobežotie faili diskā un konteineru izolācija vairs netiek garantēta.

Jaunās kļūdas anatomija

Lai saprastu, kāpēc šī otrā kļūda ir tik izplatīta, mums jāskatās uz to, kā Linux kodols pārvalda liela ātruma datus. Paredzams, ka mūsdienu serveri apstrādās miljoniem pakešu sekundē. Lai to panāktu, kodols izmanto augsti optimizētu, zema līmeņa C kodu, kas bieži vien apiet tradicionālās drošības pārbaudes, lai samazinātu latentumu. Raugoties uz apdraudējumu ainavu, šie koda reģioni, kur veiktspēja ir prioritāte pār visu pārējo, ir vietas, kur mēdz slēpties visvairāk slepeno ievainojamību.

Iedomājieties kodolu kā kuģa korpusu. Gadiem ilgi mēs esam stiprinājuši tēraudu, padarot to biezāku un izturīgāku pret ārējo spiedienu. Tomēr, lai padarītu kuģi ātrāku, mēs esam uzstādījuši sarežģītas cauruļu un vārstu sērijas, kas iet cauri visai konstrukcijai. Pašreizējā ievainojamība ir bojāts vārsts. Tas darbojas nevainojami zem normāla spiediena, bet, ja ļaundaris caur sistēmu izsūknē specifisku šķidruma secību, vārsts sabojājas, izraisot noplūdi, kas galu galā var nogremdēt visu kuģi. Atstājot malā ielāpu uzlikšanu, fundamentālā problēma ir tāda, ka, jo sarežģītāka ir "santehnika", jo lielāka ir katastrofālas kļūmes iespējamība.

Veicot savu sākotnējā ekspluatācijas koda kriminālistikas analīzi, ar kuru dalījās privātās "balto cepuru" aprindās, uzbrukuma elegance bija stindzinoša. Tas nepaļaujas uz masīvu, trokšņainu lietderīgo slodzi. Tā vietā tas izmanto granulētu pieeju, lēnām korumpējot pa vienam atmiņas baitam, līdz kodola iekšējās drošības struktūras tiek pārkonfigurētas, lai piešķirtu uzbrucējam pilnīgu kontroli. Tas ir ķirurģisks trieciens, nevis neass spēka pielietojums.

Divu nedēļu kļūdu salīdzinājums

Lai labāk izprastu kumulatīvo risku, mēs varam salīdzināt šo divu secīgo ievainojamību īpašības. Lai gan abas izraisa pilnīgu sistēmas suverenitātes zaudēšanu, to iekļūšanas punkti un prasības ievērojami atšķiras.

No galalietotāja perspektīvas atšķirība starp lokālu un attālinātu var šķist akadēmiska, ja jūsu mašīna jau ir kompromitēta. Tomēr SOC analītiķim attālinātais vektors maina prioritātes līmeni no "kritiskas" uz "katastrofālu". Proaktīvi runājot, otrā kļūda apiet nepieciešamību pēc sākotnējā atbalsta punkta, ļaujot uzbrucējam no publiskā interneta ielēkt tieši infrastruktūras sirdī.

Cilvēciskais faktors un nulles uzticamības ilūzija

Mēs bieži runājam par nulles uzticamību (zero trust) kā par VIP kluba apsargu pie katrām iekšējām durvīm, kurš nekad neuzticas un vienmēr pārbauda. Tā ir robusta filozofija, taču tā balstās uz to, ka apsargs ir neuzpērkams. Šīs kodola ievainojamības pierāda, ka, ja apsarga smadzenes — operētājsistēma — tiek kompromitētas, durvis faktiski tiek atstātas plaši vaļā. Apsargs joprojām var pārbaudīt ID, taču uzbrucējs jau ir pārrakstījis viesu sarakstu.

Tas izgaismo kritiski svarīgu patiesību: programmatūru raksta cilvēki, un cilvēki pieļauj kļūdas. Pat ar stingriem koda pārskatīšanas procesiem un automatizētu testēšanu, kļūdas saglabāsies. Linux izstrādes decentralizētais raksturs ir tā lielākais spēks, jo tas ļauj veikt strauju inovāciju un piesaistīt dažādus līdzstrādniekus. Tomēr tas ir arī sistēmiska riska avots, kad dziļi tehniskas izmaiņas tiek apvienotas bez pilnīgas izpratnes par to drošības ietekmi visā ekosistēmā.

Es atceros sarunu ar vadošo kodola uzturētāju pirms gadiem, kurš man teica, ka katru reizi, kad viņi pievieno funkciju, lai uzlabotu veiktspēju par 1%, viņi palielina uzbrukuma virsmu par 5%. Šī matemātika nav mainījusies. Tā kā mēs tiecamies pēc mērogojamākām un kritiskākām lietojumprogrammām, mēs netīšām būvējam savus digitālos torņus uz arvien nedrošāka pamata.

Pāreja no reaktīvas ielāpu uzlikšanas

Kad parādās liela ievainojamība, standarta ieteikums vienmēr ir nekavējoties uzstādīt ielāpus. Lai gan tas ir nepieciešams, tā ir reaktīva nostāja. Pārkāpuma gadījumā gaidīt pārdevēja atjauninājumu ir greznība, ko lielākā daļa organizāciju nevar atļauties. Mums ir jāvirzās uz elastīgākām arhitektūrām, kas pieņem, ka kodols varētu tikt kompromitēts.

Viena no pieejām ir aparatūras nodrošinātas izolācijas izmantošana, piemēram, konfidenciālā skaitļošana un drošie anklāvi. Šifrējot datus pat tad, kad tos izmanto CPU, mēs varam aizsargāt sensitīvu informāciju no ļaundabīga kodola. Cita stratēģija ietver granulētākas smilškastes (sandboxing) izmantošanu. Ja lietojumprogramma ir izolēta tā, ka tā pat nevar mijiedarboties ar ievainojamajām kodola apakšsistēmām, ekspluatācija kļūst par nebūtisku problēmu. Lielākā daļa Linux distribūciju pēc noklusējuma nav konfigurētas šādā veidā; tās par prioritāti izvirza saderību un lietošanas ērtumu, nevis maksimālu ierobežošanu.

Turklāt mums vajadzētu pievērst uzmanību atmiņas ziņā drošu valodu, piemēram, Rust, pieaugumam Linux kodola projektā. Tas ir ilgtermiņa projekts, taču tas risina daudzu šo problēmu cēloni: raksturīgo bīstamību, ko rada manuāla atmiņas pārvaldība C valodā. Pēc konstrukcijas Rust novērš daudzas bufera pārpildes un "use-after-free" kļūdas, kas gadu desmitiem ir mocījušas kodolu. Tās nav brīnumzāles, taču tas ir ļoti nepieciešams uzlabojums mūsu digitālajam rīku komplektam.

Galvenās atziņas IT un drošības vadītājiem

• Prioritizējiet malas ierīces: Lai gan visām sistēmām ir nepieciešami ielāpi, vispirms koncentrējieties uz publiski pieejamiem serveriem un malu ierīcēm, kas ir uzņēmīgas pret attālināto tīkla kļūdu.
• Auditējiet kodola moduļus: Atspējojiet visus nevajadzīgos kodola moduļus (piemēram, neizmantotos failu sistēmas draiverus vai eksperimentālās tīkla funkcijas), lai samazinātu pieejamo uzbrukuma virsmu.
• Ieviesiet mikrosegmentāciju: Nepaļaujieties uz to, ka kodols nodrošinās pilnīgu izolāciju starp konteineriem. Izmantojiet tīkla līmeņa segmentāciju, lai novērstu laterālo kustību, ja viens mezgls tiek kompromitēts.
• Pārraugiet anomālijas: Izmantojiet uz eBPF balstītus drošības rīkus (ironiski, ka tā ir tā pati apakšsistēma, kas bieži ir kļūdu avots), lai uzraudzītu neparastas kodola līmeņa darbības, piemēram, neautorizētas privilēģiju maiņas.
• Pārskatiet dzīves ciklu: Ja jūsu organizācija joprojām izmanto "Long Term Support" (LTS) kodolus, kas ir vairākus gadus veci, pārliecinieties, ka tie saņem portētos drošības labojumus šiem konkrētajiem CVE.

Stratēģiskā aizsardzība trauslā ekosistēmā

Raugoties nākotnē, šo "smago" Linux kļūdu biežumam vajadzētu kalpot kā modinātāja zvanam. Mēs dzīvojam laikmetā, kurā tīkla perimetrs ir novecojis pils grāvis, un reālā aizsardzība notiek atsevišķu sistēmas izsaukumu un atmiņas piešķīrumu līmenī. Cīņa par drošību virzās dziļāk sistēmas struktūrā, un mūsu aizsardzības stratēģijām ir jāseko līdzi.

Es mudinu ikvienu lasītāju uztvert šos incidentus nevis kā izolētus virsrakstus, bet gan kā pamudinājumu veikt rūpīgu savas Linux infrastruktūras riska novērtējumu. Neuzstādiet tikai ielāpu; pajautājiet, kāpēc ievainojamība vispār bija izmantojama jūsu vidē. Vai jums darbojās nevajadzīgi pakalpojumi? Vai jūsu monitorings spēja noteikt ekspluatāciju? Patiesa noturība rodas no izpratnes par to, kā, nevis tikai kas notika.

Avoti:

• 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

Atruna: Šis raksts ir paredzēts tikai informatīviem un izglītojošiem mērķiem. Tas neaizstāj profesionālu kiberdrošības auditu, kriminālistikas analīzi vai incidentu reaģēšanas pakalpojumu. Vienmēr konsultējieties ar sertificētiem drošības speciālistiem, pirms veicat būtiskas izmaiņas savā produkcijas infrastruktūrā.