GitLab AI vārtejas aizsardzība pret attālinātu koda izpildi

Lieli uzņēmumi tērē miljonus, lai izolētu savas mākslīgā intelekta (MI) darba slodzes aiz privātiem ugunsmūriem un pašu mitinātām vārtejām. Tie sagaida pilnīgu kontroli pār savu datu plūsmu un nostiprinātu perimetru pret ārējiem draudiem. GitLab AI Gateway 19.4 versijas faktiskā ievainojamība rāda, ka pat visizolētākās vides joprojām ir uzņēmīgas pret vienkāršām ievades kļūdām. Viens pieteicies lietotājs ar piekļuvi Duo Agent Platform var apiet smilškasti (sandbox), kurai būtu jāierobežo MI uzvednes. Šī izkļūšana tieši noved pie patvaļīgas komandu izpildes serverī, kas pārvalda organizācijas savienojumu ar lielajiem valodu modeļiem.

Esmu pavadījis gadus, analizējot, kā izstrādātāji pret veidņu dzinējiem izturas kā pret drošām zonām. Pastāv izplatīts maldīgs priekšstats, ka, ja lietotājs jau ir autentificēts, smilškastes izkļūšanas risks ir sekundārs. Šāds domāšanas veids ir bīstams. CVE-2026-90970 gadījumā GitLab novērtēja kļūdu ar 9,9 no 10 ballēm CVSS skalā. Šis rādītājs ir skaidrs indikators tam, ka drošības kopiena to uzskata par kritisku kļūmi. Kļūda nav smalka atmiņas korupcija vai sarežģīts laika uzbrukums. Tā ir kļūme pielāgotas plūsmas uzvednes veidnē — funkcijā, kas paredzēta daudzpakāpju uzdevumu automatizēšanai.

Sensitīvu parakstīšanas atslēgu arhitektūras risks

GitLab AI Gateway darbojas kā neplīstošs digitālais seifs savienojumam starp iekšējo GitLab instanci un ārējiem MI pakalpojumu sniedzējiem. Pēc konstrukcijas šī vārteja glabā JSON Web Tokens (JWT) parakstīšanas atslēgas. Šīs atslēgas ir sensitīvi akreditācijas dati, kas atvieglo drošu saziņu. Ja uzbrucējs izpilda komandas vārtejā, viņš vairs nav tikai lietotājs smilškastē. Viņam ir tādas pašas atļaujas kā pašam vārtejas pakalpojumam. Šāds piekļuves līmenis ļauj ļaundarim pārtvert pieprasījumus vai potenciāli manipulēt ar MI atbildēm, uz kurām paļaujas citi uzņēmuma izstrādātāji koda ģenerēšanai un drošības skenēšanai.

No riska viedokļa ietekme ir sistēmiska. Pašmitināta vārteja bieži tiek izvēlēta tieši tāpēc, lai saglabātu datus kontrolētā vidē. Kad šī vārteja tiek kompromitēta, pats rīks, kas paredzēts privātuma uzlabošanai, kļūst par placdarmu plašākam iebrukumam. Vārteja savienojas ar organizācijas MI modeļu sniedzējiem un galveno GitLab instanci. Kompromitēšana šeit ir uzticības attiecību kompromitēšana starp izstrādes vidi un inteliģences slāni, kas to nodrošina.

Uzvednes injekcijas smilškastes izkļūšanas dekonstrukcija

Šīs kļūdas tehniskā realitāte slēpjas CWE-1336, kas attiecas uz nepareizu direktīvu neitralizāciju tīmekļa lapu veidnēs. GitLab ļauj lietotājiem izveidot pielāgotas plūsmas Duo Agent Platformā. Šīs plūsmas izmanto uzvedņu veidnes, lai strukturētu, kā MI apstrādā informāciju. Lietotājs ar leģitīmu piekļuvi var izveidot plūsmas konfigurāciju, kas piemāna veidņu dzinēju izpildīt kodu ārpus tā paredzētajām robežām. Šī ir klasiska izkļūšana no smilškastes. Sistēma uzbrucēja ļaunprātīgo ievadi uztver kā komandu, nevis kā datus.

Aizkulisēs vārteja nespēj pienācīgi validēt uzvednes veidnes struktūru. Es atceros līdzīgu gadījumu, ko pagājušajā gadā apspriedu ar "balto cepuru" hakeri, izmantojot Signal savienojumu. Mēs aplūkojām veidņu dzinēju, kas ļāva lietotājiem izsaukt sistēmas funkcijas, ja tie ievietoja iekavas noteiktā veidā. Tā bija vienkārša neuzmanība analizatorā. GitLab nesenā vēsture liecina, ka šī ir atkārtota tēma. Februārī viņi izlaboja CVE-2026-1868 — vēl vienu 9,9 līmeņa kļūdu, kas arī bija saistīta ar izstrādātām plūsmu definīcijām. Šīs ievainojamības klases atkārtošanās norāda, ka veidņu drošība joprojām ir grūts šķērslis MI integrētajām platformām.

Uzbrukuma virsmas novērtēšana pašmitinātām instancēm

Rīkoties nepieciešams tikai tām organizācijām, kuras pašas mitina savu AI Gateway. GitLab pārvalda vārteju klientiem vietnēs GitLab.com un GitLab Dedicated. Proaktīvi runājot, šie klienti jau ir aizsargāti, jo GitLab atjaunināja savu infrastruktūru pirms publiskā paziņojuma. Aizsardzības slogs tagad gulstas uz sistēmas administratoru pleciem, kuri pārvalda savus Docker attēlus vai Helm shēmas.

Arhitektūras līmenī vārteja ir atsevišķs pakalpojums. Tā netiek atjaunināta automātiski, kad atjaunināt galveno GitLab instanci. Šī nošķirtība ir svarīga. Izplatīta kļūda ir pieņemt, ka salabota GitLab Rails lietojumprogramma nozīmē salabotu MI vidi. Vārteja ir atsevišķs Docker attēls ar savu versiju noteikšanu un dzīves ciklu. Ja izmantojat versiju starp 18.1.6 un 19.2.4 vai jebkuru versiju 19.3 un 19.4 līnijās pirms jaunākajiem laidieniem, jūs esat ievainojami.

Manuālie atjaunināšanas soļi Docker un Helm vidēm

Labošana ir vienīgais efektīvais pretpasākums, jo GitLab nav sniedzis pagaidu risinājumu. Lai nodrošinātu uz Docker balstītu izvietošanu, jums jāaptur esošais konteiners un jānoņem tas. Pēc tam jūs lejupielādējat atjaunināto attēla tagu. Lielākajai daļai uzņēmuma lietotāju tas būs self-hosted-v19.4.1-ee tags vai tā ekvivalents 19.2 un 19.3 līnijām.

Tiem, kas izmanto Kubernetes, process ietver attēla iestatījuma atjaunināšanu Helm shēmā. Zemāk esošajā tabulā ir apkopoti nepieciešamie atjaunināšanas ceļi ietekmētajām versijām:

GitLab uzturēšanas politika parasti aptver pašreizējo un divus iepriekšējos mazos laidienus. Līdz ar to labojumi ir pieejami 19.2, 19.3 un 19.4 līnijām. Ja izmantojat vecāku versiju, piemēram, 19.1, oficiāls labojums nav norādīts. Šis atbalsta trūkums vecākām versijām ir būtiska detaļa, kuru administratori nedrīkst ignorēt. Neatbalstītas vārtejas versijas darbināšana faktiski nozīmē digitālā seifa atstāšanu atslēgtu.

Tiesu medicīnas ierobežojumi un ekspluatācijas trūkums

Līdz šodienai ASV Kiberdrošības un infrastruktūras drošības aģentūra (CISA) šīs kļūdas ekspluatāciju norāda kā "nav konstatēta". Nav publiska koncepcijas pierādījuma un nav liecību par aktīvu ekspluatāciju reālajā vidē. Tomēr paziņojumā nav sniegta metode, kā pārbaudīt, vai vārtejai tika uzbrukts pirms atjaunināšanas. Šis tiesu medicīnas redzamības trūkums ir ievērojama plaisa. Bez konkrētiem žurnālu parakstiem vai kompromitēšanas indikatoriem administratoriem atliek tikai minēt, vai viņu parakstīšanas atslēgām tika piekļūts ievainojamības loga laikā.

Pārkāpuma gadījumā, kas saistīts ar šādu rīku, mērķis bieži ir slepena noturība. Uzbrucējs varētu neizraisīt vārtejas avāriju. Tā vietā viņš varētu klusi eksportēt JWT parakstīšanas atslēgas, lai vēlāk atvieglotu neautorizētu piekļuvi MI modeļiem. Tāpēc tūlītēja sensitīvu akreditācijas datu rotācija pēc ielāpa uzstādīšanas ir standarta nozares prakse. Cauruma aizlāpīšana kuģa korpusā ir pirmais solis, taču jums ir arī jāpārbauda, vai kāda krava netika izmesta pār bortu, kamēr caurums bija vaļā.

Cilvēciskais faktors MI drošībā

Mēs bieži uztveram MI kā futūristisku slāni, kas atrodas virs mūsu esošā koda. Patiesībā MI pakalpojumi, piemēram, GitLab Gateway, ir tikai vēl viena programmatūra. Uz tiem attiecas tās pašas vecās skolas ievainojamības, piemēram, komandu injekcija un veidņu izkļūšana. Cilvēka ugunsmūris joprojām ir pirmā aizsardzības līnija. Lietotāji, kuriem ir piekļuve Duo Agent Platform, ir tie, kuri var sasniegt šo kļūdu. Piekļuves ierobežošana šīm platformām tikai tiem, kam tā ir stingri nepieciešama, atbilst minimālo privilēģiju principam.

Nulles uzticēšanās (Zero trust) ir VIP kluba apsargs pie katrām iekšējām durvīm. Pat ja lietotājs atrodas ēkas iekšpusē, apsargam būtu jāpārbauda viņa akreditācijas dati, pirms ļaut viņam tuvoties veidņu dzinēja konfigurācijai. Ja jūsu organizācija ļauj katram izstrādātājam izveidot pielāgotas MI plūsmas bez uzraudzības, jūs palielināt savu uzbrukuma virsmu. Šo MI integrāciju sarežģītība padara granulētu piekļuves kontroli par prasību, nevis ieteikumu.

Galvenie secinājumi tūlītējai seku mazināšanai

Lai novērstu šo kritisko kļūdu, administratoriem jāievēro noteikta darbību secība. Pirmkārt, identificējiet precīzu AI Gateway attēla versiju, kas pašlaik darbojas vidē. Nepieņemiet, ka versija sakrīt ar galveno GitLab lietojumprogrammu. Otrkārt, nekavējoties lietojiet attiecīgo ielāpu, izmantojot GitLab sniegtās Docker vai Helm procedūras. Treškārt, apsveriet iespēju rotēt JWT parakstīšanas atslēgas, ja vārteja bija pieejama neuzticamiem iekšējiem lietotājiem pirms ielāpa uzstādīšanas.

Visbeidzot, auditējiet to lietotāju sarakstu, kuriem ir atļauja konfigurēt pielāgotas plūsmas Duo Agent Platformā. Ja lietotājam nav kritiska iemesla mainīt šīs konfigurācijas, noņemiet viņa piekļuvi. To cilvēku skaita samazināšana, kuri var sasniegt ievainojamību, ir tikpat svarīga kā paša koda labošana. Drošība ir nepārtraukts uzlabošanas process, nevis vienreizējs atjauninājums.

Avoti

• GitLab Security Advisory (CVE-2026-90970)
• CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
• CWE-1336: Improper Neutralization of Directives in Web Page Templates
• NIST Guide to Enterprise Patch Management Strategies

Atruna: Šis raksts ir paredzēts tikai informatīviem un izglītojošiem mērķiem. Tas neaizstāj profesionālu kiberdrošības auditu vai incidentu reaģēšanas pakalpojumu. Pirms sistēmas atjaunināšanas vienmēr konsultējieties ar oficiālo pārdevēja dokumentāciju.