Drošības pētnieks Juhans Vu (Yuhang Wu) no uzņēmuma depthfirst 24. jūlijā publicēja darbojošos uzbrukuma kodu, kas uz nelāpīta pašuzturēta GitLab 18.11.3 servera izpilda komandas ar git sistēmas konta tiesībām. Uzbrucējam nevajag administratora tiesības, piekļuvi CI izpildītājam vai kāda cita lietotāja līdzdalību. Pietiek ar parastu kontu, kas drīkst iesūtīt izmaiņas kaut vienā projektā.
Gaita ir īsa. Uzbrucējs iesūta divus sagatavotus Jupyter piezīmju grāmatas failus un atver to izmaiņu skatu. GitLab .ipynb failus pirms attēlošanas pārstrādā salasāmā izmaiņu skatā. Tieši šī pārstrāde palaiž ķēdi.
Divas kļūdas piecus gadus vecā JSON parsētājā
Ķēde balstās uz divām atmiņas kļūdām bibliotēkā Oj. Tas ir ātrs JSON parsētājs Ruby videi, lielākoties uzrakstīts C valodā. Kļūdainais kods repozitorijā nonāca 2021. gada augustā. GitLab attiecīgo parsēšanas ceļu sāka lietot 2022. gada jūlijā.
Pirmā kļūda ir ligzdošanas steka pārrakstīšana funkcijā Oj::Parser.usual.parse. Steks ir 1024 baitus liels un garuma pārbaudes tam nav. Pietiekami dziļi ligzdots JSON raksta tam garām līdz vietai, kur glabājas parsētāja start atsauces funkcijas adrese.
Otrā kļūda ir atslēgas garuma sašaurināšana līdz 16 bitu laukam ar zīmi. Ja atslēga ir 65 565 baitus gara, skaitlis pārpildās un paliek 29 baiti. Atbildē tad nonāk dzīvs kaudzes atmiņas rādītājs, ko GitLab godprātīgi attēlo izmaiņu skatā.
Pārējais ir rutīna. Uzbrucējs nolasa noplūdušo adresi un atkārto gājienu tik reižu, cik vajag libc atrašanās vietas aprēķinam. Ar to krīt ASLR aizsardzība. Trešais solis novirza start atsauci uz system().
Ielāps, kas neizskatījās pēc drošības ielāpa
GitLab caurumu aizvēra 10. jūnijā, pusotru mēnesi pirms koda publicēšanas. Labojums ir Oj versijas paaugstināšana uz 3.17.3. Laidiena piezīmēs tas parādījās pie parastajiem kļūdu labojumiem. Drošības labojumu tabulā tā nav, CVE numura nav, CVSS vērtējuma nav, piezīmju grāmatas ķēde nav pieminēta nemaz.
The Hacker News raksta, ka CVE numuru nav saņēmušas ne Oj kļūdas, ne GitLab ķēde. GitLab uz jautājumu par CVE piešķiršanu nav atbildējis.
Administratoram, kurš laidiena piezīmes lasa pa diagonāli un steidzas tikai ar drošības ierakstiem, 18.10.8 izskatījās pēc kārtējā uzturēšanas laidiena.
Kuras versijas ir skartas
- 15.2.0 līdz 18.10.7: labots 18.10.8
- 18.11.0 līdz 18.11.4: labots 18.11.5
- 19.0.0 līdz 19.0.1: labots 19.0.2
Skarti ir visi izdevumi, arī bezmaksas Community Edition un Enterprise Edition līdz Ultimate. Oj pusē problēma ir versijās no 3.13.0 līdz 3.17.1. Labotā versija 3.17.3 iznāca 4. jūnijā. Ruby lietotnēs ārpus GitLab der pārbaudīt, ko rāda bundle list | grep oj.
Serverī, kur atjaunināšana kaut kāda iemesla dēļ velkas, palīdz sašaurināt loku. Uzbrukumam vajag kontu ar tiesībām iesūtīt izmaiņas, tāpēc vērts pārskatīt, cik daudz ārēju lietotāju sēž Developer līmenī publiskos projektos. Atvērta pašreģistrācija bez apstiprināšanas šo caurumu pataisa par faktiski attālinātu.
Pēdas meklējamas izmaiņu vēsturē. Aizdomīgs ir .ipynb fails ar desmitiem tūkstošu baitu garu JSON atslēgu vai ar simtiem ligzdošanas līmeņu. Parasta piezīmju grāmata tāda neizskatās.
Komandas izpildās ar git konta tiesībām. Šis konts redz repozitoriju pirmkodu, Rails noslēpumu failus, CI/CD datus un iekšējos servisus. Rails noslēpumu fails ļauj parakstīt sesijas sīkdatnes, bet CI/CD mainīgie mēdz glabāt izvietošanas atslēgas uz ražošanas vidi. Vu norāda, ka kods nav piesiets vienai konkrētai versijai.
Lai to pavērstu pret citu GitLab būvējumu tajā pašā arhitektūrā, parasti pietiek ar nelielu nobīžu labošanu.
Kļūdas atrada automāts
Oj bibliotēku pārbaudīja depthfirst automatizētā analīzes sistēma Open Defense Initiative ietvaros. Tā izcēla 18 prioritāras problēmas, no tām septiņas ir atmiņas drošības kļūdas. Divas no šīm septiņām bibliotēkā bija nostāvējušas gandrīz piecus gadus. Ķēdi no tām salika pētnieki ar rokām, kā apraksta Cybersecurity News.
Oj Ruby ekosistēmā ir viena no biežāk lietotajām JSON bibliotēkām, jo strādā manāmi ātrāk par standarta parsētāju. Tāpēc kļūda vienā gem pakotnē izaug par problēmu produktos, kas ar JSON parsēšanu paši tieši nenodarbojas.
Tas ir otrs šāda veida gadījums itn.lv redzeslokā šomēnes. Jūlija sākumā Gemini 3.5 Flash Cyber V8 dzinī atrada 55 ievainojamības. Atšķirība ir tā, ka Oj gadījumā automāta atradumi tika savērpti līdz galam strādājošā uzbrukumā.
Laika grafiks
- 21. maijs: Oj kļūdas paziņotas bibliotēkas uzturētājam
- 27. maijs: labojumi ielieti
- 4. jūnijs: iznāk Oj 3.17.3
- 5. jūnijs: GitLab saņem ziņojumu par ķēdi
- 8. jūnijs: GitLab to apstiprina
- 10. jūnijs: iznāk ielāpotās GitLab versijas
- 24. jūlijs: publiskots darbojošs uzbrukuma kods
Starp ielāpa iznākšanu un uzbrukuma koda publiskošanu pagāja 44 dienas. Publicētais paraugs mērķē uz versiju 18.11.3.
Mākoņa instances gitlab.com uztur pats GitLab un tās ir ielāpotas. Uzbrukums skar pašuzturētus serverus, kuru administrators jūnija laidienu izlaida. Serverī, kas vēl darbina 18.10.7, viena 65 565 baitus gara atslēga vienā .ipynb failā joprojām nostrādā.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.