„GitLab AI Gateway“ apsauga nuo nuotolinio kodo vykdymo

Didelės įmonės išleidžia milijonus, kad izoliuotų savo dirbtinio intelekto (DI) darbo krūvius už privačių užkardų ir savarankiškai priglobtų šliuzų. Jos tikisi visiškos duomenų srauto kontrolės ir sustiprinto perimetro prieš išorines grėsmes. Faktinis „GitLab AI Gateway“ 19.4 versijos pažeidžiamumas rodo, kad net ir labiausiai izoliuotos aplinkos išlieka jautrios paprastoms įvesties klaidoms. Vienas prisijungęs vartotojas, turintis prieigą prie „Duo Agent Platform“, gali apeiti izoliuotąją aplinką (angl. sandbox), kuri turėtų apriboti DI užklausas. Šis pabėgimas tiesiogiai leidžia vykdyti savavališkas komandas serveryje, kuris valdo organizacijos ryšį su dideliais kalbos modeliais.

Daugelį metų analizavau, kaip programuotojai vertina šablonų variklius kaip saugias zonas. Vyrauja klaidinga nuomonė, kad jei vartotojas jau yra autentifikuotas, rizika pabėgti iš izoliuotos aplinkos yra antraeilė. Toks mąstymas yra pavojingas. CVE-2026-90970 atveju „GitLab“ įvertino klaidą 9,9 balo iš 10 pagal CVSS skalę. Šis balas yra aiškus rodiklis, kad saugumo bendruomenė tai laiko kritiniu gedimu. Klaida nėra subtilus atminties sugadinimas ar sudėtinga laiko ataka. Tai klaida pasirinktinio srauto užklausos šablone – funkcijoje, skirtoje automatizuoti daugiapakopes užduotis.

Architektūrinė jautrių pasirašymo raktų rizika

„GitLab AI Gateway“ veikia kaip nedūžtantis skaitmeninis seifas ryšiui tarp vidinės „GitLab“ instancijos ir išorinių DI teikėjų. Pagal konstrukciją šis šliuzas saugo JSON žiniatinklio žetonų (JWT) pasirašymo raktus. Šie raktai yra jautrūs duomenys, palengvinantys saugų ryšį. Jei užpuolikas vykdo komandas šliuze, jis nebėra tik vartotojas izoliuotoje aplinkoje. Jis turi tas pačias teises kaip ir pati šliuzo paslauga. Toks prieigos lygis leidžia piktavaliui perimti užklausas arba potencialiai manipuliuoti DI atsakymais, kuriais pasikliauja kiti įmonės programuotojai generuodami kodą ar atlikdami saugumo skenavimą.

Rizikos požiūriu poveikis yra sisteminis. Savarankiškai priglobtas šliuzas dažnai pasirenkamas būtent tam, kad duomenys būtų laikomi kontroliuojamoje aplinkoje. Kai tas šliuzas yra pažeidžiamas, pati priemonė, skirta privatumui didinti, tampa placdarmu didesnei invazijai. Šliuzas jungiasi prie organizacijos DI modelių teikėjų ir pagrindinės „GitLab“ instancijos. Kompromitacija čia yra pasitikėjimo santykių tarp kūrimo aplinkos ir ją maitinančio intelekto sluoksnio kompromitacija.

Užklausų injekcijos ir pabėgimo iš izoliuotos aplinkos dekonstravimas

Techninė šios klaidos realybė slypi CWE-1336, kuri apima netinkamą direktyvų neutralizavimą tinklalapių šablonuose. „GitLab“ leidžia vartotojams kurti pasirinktinius srautus „Duo Agent Platform“. Šie srautai naudoja užklausų šablonus, kad struktūrizuotų, kaip DI apdoroja informaciją. Vartotojas, turintis teisėtą prieigą, gali sukurti srauto konfigūraciją, kuri apgauna šablonų variklį vykdyti kodą už numatytų ribų. Tai klasikinė pabėgimo iš izoliuotos aplinkos situacija. Sistema užpuoliko piktavališką įvestį traktuoja kaip komandą, o ne kaip duomenis.

Užkulisiuose šliuzas nesugeba tinkamai patvirtinti užklausos šablono struktūros. Prisimenu panašų atvejį, kurį praėjusiais metais aptariau su etišku įsilaužėliu per „Signal“ ryšį. Nagrinėjome šablonų variklį, kuris leido vartotojams kviesti sistemos funkcijas, jei jie tam tikru būdu įdėdavo skliaustus. Tai buvo paprastas aplaidumas analizatoriuje (angl. parser). Pastaroji „GitLab“ istorija rodo, kad tai pasikartojanti tema. Vasario mėnesį jie ištaisė CVE-2026-1868 – kitą 9,9 balo klaidą, kuri taip pat buvo susijusi su suklastotais srauto apibrėžimais. Šios pažeidžiamumų klasės pasikartojimas rodo, kad šablonų saugumas išlieka sudėtinga kliūtis DI integruotoms platformoms.

Savarankiškai priglobtų instancijų atakos paviršiaus vertinimas

Veiksmų turi imtis tik tos organizacijos, kurios pačios prigloba savo „AI Gateway“. „GitLab“ valdo šliuzą klientams, besinaudojantiems „GitLab.com“ ir „GitLab Dedicated“. Kalbant proaktyviai, tie klientai jau yra apsaugoti, nes „GitLab“ atnaujino savo infrastruktūrą prieš viešą pranešimą. Gynybos našta dabar tenka sistemų administratoriams, kurie valdo savo „Docker“ atvaizdus arba „Helm“ schemas.

Architektūriniu lygmeniu šliuzas yra atskira paslauga. Jis neatnaujinamas automatiškai, kai atnaujinama pagrindinė „GitLab“ instancija. Šis atskyrimas yra svarbus. Dažna klaida yra manyti, kad ištaisyta „GitLab Rails“ programa reiškia ištaisytą DI aplinką. Šliuzas yra atskiras „Docker“ atvaizdas su savo versijų kūrimu ir gyvavimo ciklu. Jei naudojate versiją nuo 18.1.6 iki 19.2.4 arba bet kurią 19.3 ir 19.4 linijų versiją iki naujausių leidimų, esate pažeidžiami.

Rankiniai „Docker“ ir „Helm“ atnaujinimo žingsniai

Atnaujinimas yra vienintelė veiksminga priešpriemonė, nes „GitLab“ nepateikė jokio laikino sprendimo. Norėdami apsaugoti „Docker“ pagrindu veikiantį diegimą, turite sustabdyti esamą konteinerį ir jį pašalinti. Tada atsisiųskite atnaujintą atvaizdo žymą. Daugumai įmonių vartotojų tai bus „self-hosted-v19.4.1-ee“ žyma arba jos atitikmuo 19.2 ir 19.3 linijoms.

Naudojantiems „Kubernetes“, procesas apima atvaizdo nustatymo atnaujinimą „Helm“ schemoje. Žemiau esančioje lentelėje apibendrinami būtini atnaujinimo keliai paveiktoms versijoms:

„GitLab“ priežiūros politika paprastai apima dabartinį ir du ankstesnius nedidelius leidimus. Todėl pataisymai yra prieinami 19.2, 19.3 ir 19.4 linijoms. Jei naudojate senesnę versiją, pavyzdžiui, 19.1, oficialaus pataisymo nėra. Šis paramos trūkumas senesnėms versijoms yra detalė, kurios administratoriai neturi pamiršti. Naudoti nepalaikomą šliuzo versiją yra tas pats, kas palikti skaitmeninį seifą neužrakintą.

Teismo ekspertizės apribojimai ir išnaudojimo nebuvimas

Šiai dienai JAV Kibernetinio saugumo ir infrastruktūros saugumo agentūra (CISA) nurodo, kad šios klaidos išnaudojimo atvejų nėra. Nėra viešo koncepcijos įrodymo ir nėra įrodymų apie aktyvų išnaudojimą realioje aplinkoje. Tačiau patarime nepateikiamas metodas, kaip patikrinti, ar šliuzas buvo užpultas prieš atnaujinimą. Šis teismo ekspertizės matomumo trūkumas yra didelė spraga. Be specifinių žurnalų parašų ar kompromitacijos indikatorių, administratoriams telieka spėlioti, ar jų pasirašymo raktai buvo pasiekti pažeidžiamumo laikotarpiu.

Įsilaužimo į tokį įrankį atveju tikslas dažnai yra slaptas išlikimas sistemoje. Užpuolikas gali nesugadinti šliuzo. Vietoj to jis gali tyliai eksportuoti JWT pasirašymo raktus, kad vėliau palengvintų neteisėtą prieigą prie DI modelių. Štai kodėl neatidėliotinas jautrių kredencialų rotavimas po pataisymo yra standartinė pramonės praktika. Skylės laivo korpuse užtaisymas yra pirmas žingsnis, tačiau taip pat turite patikrinti, ar koks nors krovinys nebuvo išmestas už borto, kol skylė buvo atvira.

Žmogiškasis faktorius DI saugume

Mes dažnai vertiname DI kaip futuristinį sluoksnį, kuris yra virš mūsų esamo kodo. Tikrovėje DI paslaugos, tokios kaip „GitLab Gateway“, yra tiesiog dar daugiau programinės įrangos. Joms būdingi tie patys senosios mokyklos pažeidžiamumai, tokie kaip komandų injekcija ir pabėgimai iš šablonų. Žmogiškoji užkarda išlieka pirmoji gynybos linija. Vartotojai, turintys prieigą prie „Duo Agent Platform“, yra tie, kurie gali pasiekti šią klaidą. Prieigos prie šių platformų ribojimas tik tiems, kuriems jos griežtai reikia, atitinka mažiausių privilegijų principą.

Nulinis pasitikėjimas (angl. Zero trust) yra kaip VIP klubo apsauginis prie kiekvienų vidinių durų. Net jei vartotojas yra pastato viduje, apsauginis turėtų patikrinti jo kredencialus prieš įleisdamas prie šablonų variklio konfigūracijos. Jei jūsų organizacija leidžia kiekvienam programuotojui be priežiūros kurti pasirinktinius DI srautus, jūs didinate savo atakos paviršių. Šių DI integracijų sudėtingumas paverčia granuliuotą prieigos kontrolę reikalavimu, o ne pasiūlymu.

Pagrindinės įžvalgos skubiam rizikos mažinimui

Norėdami pašalinti šią kritinę klaidą, administratoriai turėtų atlikti tam tikrą veiksmų seką. Pirmiausia nustatykite tikslią šiuo metu aplinkoje veikiančio „AI Gateway“ atvaizdo versiją. Nemanykite, kad versija sutampa su pagrindine „GitLab“ programa. Antra, nedelsdami pritaikykite atitinkamą pataisą naudodami „GitLab“ pateiktas „Docker“ arba „Helm“ procedūras. Trečia, apsvarstykite galimybę rotuoti JWT pasirašymo raktus, jei šliuzas buvo prieinamas nepatikimiems vidiniams vartotojams prieš pritaikant pataisą.

Galiausiai peržiūrėkite vartotojų, turinčių leidimą konfigūruoti pasirinktinius srautus „Duo Agent Platform“, sąrašą. Jei vartotojas neturi kritinės priežasties keisti šias konfigūracijas, panaikinkite jo prieigą. Žmonių, galinčių pasiekti pažeidžiamumą, skaičiaus mažinimas yra toks pat svarbus kaip ir paties kodo taisymas. Saugumas yra nenutrūkstamas tobulinimo procesas, o ne vienkartinis atnaujinimas.

Šaltiniai

• 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

Atsakomybės apribojimas: Šis straipsnis yra skirtas tik informaciniams ir švietimo tikslams. Jis nepakeičia profesionalaus kibernetinio saugumo audito ar reagavimo į incidentus paslaugos. Prieš atlikdami sistemos atnaujinimus, visada vadovaukitės oficialia gamintojo dokumentacija.