Između 20. i 21. srpnja objavljena je serija od 432 CVE-a za Linux kernel, no to ne znači da je popravljeno 432 grešaka, jer funkcioniranje CVE-a za kernel je drugačije.
Prvo, što je CVE? To je jedinstveni identifikator (Common Vulnerabilities and Exposures) dodijeljen javno poznatom sigurnosnom propustu u računalnom softveru. Takva ranjivost definira se kao slabost u logici softvera koja napadaču omogućuje kršenje sigurnosne politike i izvođenje radnji na koje inače nema pravo. U većini slučajeva, CVE se objavljuju prije odgovarajućih popravaka, jer često služe kao osnova za sigurnosna izvješća. CVE obično prati CVSS (Common Vulnerability Scoring System) ocjena, koja bi trebala predstavljati razinu opasnosti propusta, te kontekstualni detalji (vektor napada na daljinu, potrebna razina privilegija itd.).
Sigurnost
CVSS 4.0: teško, teško, biti stručnjak!
Četvrtak, 30. studenog 2023. u 18:17
16
Postoji CVE i CVE
CVE dodjeljuju CNA (CVE Numbering Authorities). Od veljače 2024. projekt Linux postao je vlastita tijela za numeriranje, s posebnim pravilima prilagođenima razmjeru goleme baze koda.
Da bismo razumjeli trenutnu situaciju, treba zapamtiti da su ova pravila obrnuta u odnosu na ostatak industrije. U klasičnom slučaju, otkriće propusta dovodi do dodjele CVE-a, uzbune, a zatim razvoja zakrpe. Bez obzira na to što se detalji ponekad objave kasnije, CVE se dodjeljuje prvi. Unutar projekta Linux suprotno je: otkriće slabosti u kodu dovodi do razvoja zakrpe, zatim njenog uklapanja u stabilne grane kernela, i tek onda do pojave CVE-a. To znači da unutar Linux kernela nepopravljene greške nemaju CVE.
Još jedno važno pojašnjenje: kernel tim sustavno dodjeljuje CVE svakom popravku greške koja bi mogla utjecati na stabilnost ili pristup memoriji, bez pokušaja kvalifikacije je li greška lako iskoristiva ili ne. To je objasnio Greg Kroah-Hartman, glavni održavatelj stabilnih grana kernela, na svom blogu u veljači. Također, ne proizvodi se CVSS ocjena, i to s razlogom: programeri kernela ne znaju kako se Linux koristi, dakle u kakvom okruženju će se kod izvršavati.
S druge strane, tamo gdje tradicionalni CVE opisuje ponašanje na višoj razini, Linux CVE izravno odgovara identifikatoru Git commita. Ovo automatizirano praćenje objašnjava zašto masovna upotreba fuzzera i alata za statičku analizu generira iznenadne skokove od nekoliko stotina CVE-ova.
Ali gdje je problem?
Iako je objava 432 CVE-a sama po sebi bez presedana, oni odgovaraju već popravljenim greškama. Ipak, Jan Schaumann, glavni arhitekt informacijske sigurnosti u Akamai Technologies, požalio se na mailing listi OSS-SEC. Izrazio je zabrinutost zbog takvog volumena, pitajući kako poduzeća, i općenito proizvodna okruženja, mogu pratiti taj tempo.
Ali u čemu je problem? Ako su greške već popravljene, nije li dovoljno strpljivo pričekati sljedeću reviziju kernela? Nije tako jednostavno.
Treba uzeti u obzir nekoliko elemenata. S jedne strane, popravci uklopljeni u stabilne grane znače da će ih preuzeti sve trenutno podržane verzije Linux kernela. U teoriji, bilo bi dovoljno instalirati sljedeću verziju u korištenoj grani, na primjer Linux 7.2 koji popravlja opasne bugove ako se koristi distribucija koja prati najnovije verzije. S druge strane, proizvodna okruženja često koriste modificirane verzije, čak i stare verzije u kojima timovi “backportiraju” (retroportiraju) izmjene koje ih zanimaju.
Tu nastaje problem na koji se Jan Schaumann žali: kada se 432 CVE objavi u 24 sata, kako znati što je važno i što treba retroportirati? U pismu upućenom The Registeru, spominje mogućnost korištenja LLM-ova za automatsko upravljanje tokom. “Automatizirana, redovita i česta ažuriranja koja uključuju sve promjene u zadanom vremenskom roku čine mi se jedinim razumnim pristupom, ali to je vrlo teško za mnoge velike organizacije”, objašnjava.
Najnoviji dostupni kernel, uvijek
Na mailing listi OSS-SEC, rasprava sadrži zanimljive odgovore, posebno onaj Grega Kroah-Hartmana osobno. Iako ne reagira izravno na početnu poruku, razmatraju se rješenja koja su predložili drugi, a on jasno daje prednost jednom: uvijek koristiti najnoviji stabilni kernel dostupan na željenoj grani i redovito provjeravati sve upravljane sustave.
Kroah-Hartman priznaje da to nije uvijek jednostavno unutar poduzeća, ali da postoje plaćeni proizvodi koji omogućuju učinkovito upravljanje tim procesom. Ako plaćanje takvog proizvoda nije moguće, preporučuje instaliranje distribucija poput Debiana ili Yoctoa, jer su “njihove sigurnosne prakse izvanredne”. Ostala rješenja predstavljaju više posla ili manju sigurnost. Provjeravati CVE po CVE kako bi se u obzir uzeli samo oni važni za infrastrukturu? To se može učiniti automatski kako bi se provjerilo što se nalazi na presjeku datoteka koje CVE-ovi ciljaju i datoteka koje se stvarno koriste u upravljanom okruženju. Ali vraćamo se na prijedlog Jana Schaumanna, a ne mogu si sve organizacije priuštiti takav upravljački cjevovod.
Drugim riječima, najbolje rješenje ostaje preuzimanje novih kernela kada postanu dostupni, ali eksplozija broja CVE-ova – vrlo vjerojatno potaknuta sve većom upotrebom LLM-ova – otežava čitanje. Ipak, za Grega Kroah-Hartmana nema stvarnog problema: 432 CVE pripremala su se tjednima, nitko ne bi trebao biti iznenađen.