Cohere AI Terrariumin hiekkalaatikko: toiminta, riskit ja kriittiset haavoittuvuudet

Informatec Digital » Resurssit » Cohere AI Terrariumin hiekkalaatikko: toiminta, riskit ja kriittiset haavoittuvuudet

Kun puhumme toteuttamisesta Epäluotettava tai tekoälyn luoma Python-koodiYksi suurimmista päänsäryistä on se, miten se tehdään turvallisestiNopea ja ilman infrastruktuurin suuria kustannuksia. Tässä yhteydessä syntyi Terrarium, Cohere AI:n ratkaisu, joka on suunniteltu hiekkalaatikoksi tämän tyyppisen koodin isännöimiseksi ja suorittamiseksi pilvessä, erityisesti Google Cloud Runissa, sijaitsevissa säilöissä.

Tämä lähestymistapa mahdollisti kehittäjille ja yrityksille Terrariumin hyödyntämisen erillisenä ympäristönä, jossa julkaisun käyttäjä tai mallikoodi LLMmelko kohtuullisin kustannuksin ja kohtuullisen hyvällä suorituskyvyllä. Ajan myötä on kuitenkin ilmennyt myös muita ongelmia erittäin vakavia haavoittuvuuksiamukaan lukien yksi, jonka CVE-tunniste paljastaa kriittisiä tietoturva-aukkoja hiekkalaatikossa ja on nostanut Terrariumin parrasvaloihin.

Mikä on terraario ja mihin se on suunniteltu?

Terraario on pohjimmiltaan ns. eristetty Python-ajonaikainen ympäristö, suunniteltu toimimaan käyttöönotettava Docker-konttiEsimerkiksi Google Cloud Runissa. Sen päätavoitteena on tarjota hiekkalaatikko, jossa mahdollisesti vaarallista tai tuntematonta koodia (kuten käyttäjien lähettämiä skriptejä tai kielen luomia mallifragmentteja) voidaan käynnistää vaarantamatta suoraan pääinfrastruktuuria.

Projektin taustalla oleva filosofia keskittyy siihen, että kustannustehokas, pieniviiveinen ja helposti integroitava palvelu olemassa olevissa työnkuluissa. Terrarium suunniteltiin kutsuttavaksi HTTP-pyyntöjen kautta, jolloin se lähettää suoritettavan Python-koodin – ja valinnaisesti syötetiedostot – ja vastaanottaa takaisin suorituksen tuloksen sekä luodut tiedostot.

Käytännössä tämä tarkoittaa, että ulkoinen järjestelmä, API tai jopa sisäinen työkalu voi Python-koodin suorituksen delegointi Terrariumissa, pitämällä koodin suhteellisen rajoitetussa ympäristössä, jossa on selkeät säännöt resursseille, suoritusajalle ja sallituille ominaisuuksille.

Yksi keskeisistä suunnittelukohdista on, että Terrarium luottaa Pyodide, CPythonista WebAssemblyyn käännettävä versio suoritetaan Node.js-prosessin sisällä. Tämän lähestymistavan ansiosta Python-koodi ei toimi natiivisti isäntäjärjestelmässä, vaan kapseloidun tulkin sisällä, mikä teoriassa vahvistaa eristämistä.

Hiekkalaatikon suorituskyky, kustannukset ja tärkeimmät ominaisuudet

Yksi Terrariumin puolesta puhuvista argumenteista oli sen yhdistelmä alhaiset käyttökustannukset ja hyväksyttävä suorituskykyTodellisissa Google Cloud Run -käyttöönotoissa, joissa tyypillinen kokoonpano on 2 Gt muistia, 1 vCPU ja vähintään yksi aina päällä oleva instanssi automaattisella skaalauksella tarvittaessa, raportoidut kuukausikustannukset olivat noin 30 dollaria sisäisten annotointivaiheiden aikana.

Nopeuden suhteen kuvatut testit osoittavat, että Terrarium voisi tuottaa esimerkiksi PNG-kuva 200 dpi:n tarkkuudella yksinkertaisesta matplotlib-graafista noin 900 ms suoritusaika tai SVG-versio noin 500 ms:ssa. Nämä ajat viittaavat Cloud Runissa isännöityyn koodiin, mukaan lukien palvelun tyypillinen kutsusykli.

Suorituskyvyn lisäksi Terrarium kehuskeli olevansa täysin lokeroitu kutsujen välilläJokaisen kutsun jälkeen hiekkalaatikko kierrätettiin kokonaan: Pyodiden virtuaalinen tiedostojärjestelmä, globaalit muuttujat, ladatut kirjastot ja kaikki sisäiset tilat hylättiin. Tavoitteena oli estää kutsuja perimästä tietoja tai kontekstia edellisestä suorituksesta, mikä vähentäisi tietovuotojen riskiä.

Toinen tärkeä seikka on, että vaikka kiinteää eristystä pyrittiinkin, Cohere teki selväksi, että Se ei tarjonnut ehdottomia takeita hiekkalaatikon eheydestäTämä jo vihjasi siihen, että suojauskerroksista huolimatta oli mahdollista, että heikkouksia voitaisiin löytää, erityisesti WebAssemblyn ja sen Node.js-integraation kaltaisessa monimutkaisessa ympäristössä.

Terrarium suunniteltiin helpoksi käyttää muista palveluista: tee vain HTTP-pyyntö Cloud Runissa käyttöönotettuun päätepisteeseen, suoritettavan koodin ja valtuutustunnuksen lähettäminen (jos kokoonpano sitä vaati). Vastineeksi saatiin JSON-tiedosto tuloksineen ja tarvittaessa luodut tiedostot base64-koodattuna.

Tiedostojen suorittaminen ja kirjastotuki Pyodidessa

Yksi Terrariumin vetovoimatekijöistä oli sen kyky työskennellä natiivit syöte- ja tulostiedostotAPI salli useiden minkä tahansa tyyppisten tiedostojen liittämisen Python-koodin mukana pyyntöön; nämä sijoitettiin virtuaaliseen tiedostojärjestelmään, jonka Pyodide paljastaa Python-tulkille.

Suorituksen aikana Python-koodi voisi lukea ja käsitellä näitä tiedostoja ikään kuin ne olisivat paikallisia hiekkalaatikossa. Kun suoritus oli valmis, Terrarium keräsi kaikki luodut tai muokatut tiedostot ja palautti ne vastauksena asiakkaalle, yleensä koodattuina siirrettäväksi HTTP:n kautta ongelmitta.

Kirjastoekosysteemin osalta Terrarium peri Pyodideen perustuen melko laaja valikoima tieteellisiä ja data-analyysipakettejaSuoraan tuettuihin kuuluvat: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy ja sqlite3 (jälkimmäinen ei ole oletuksena käytössä, mutta sen voi ladata tarvittaessa).

Matplotlibin erityistapauksessa oli joitakin rajoituksia: plt.show()-funktiota ei tuettu Tässä ympäristössä plt.savefig()-funktion käyttö kuvien luomiseen toimi oikein, kunhan ei pakotettu liian suuria parametreja, kuten erittäin korkeita resoluutioita, jotka lisäisivät resurssien käyttöä.

Tämä kirjastosarja teki Terrariumista erityisen hyödyllisen Tehtäviin kuuluu data-analyysi, visualisointi ja koneoppimismallien prototyyppien luonti. ja strukturoidun tiedon manipulointi, kaikki toteutettuna teoreettisesti kontrolloidussa hiekkalaatikossa.

Sisäinen arkkitehtuuri: eristämisen ja käyttöönoton kerrokset

Terraarion arkkitehtuuri on rakennettu useista kerroksista, jotka on suunniteltu pienennä hyökkäyspinta-alaa ja eristä epäluotettava koodi mahdollisimman hyvinEnsimmäinen kerros on itse Node.js-prosessi, joka toimii isäntänä ja lataa Pyodiden eli WebAssemblyksi käännetyn CPythonin.

Käyttäjän lähettämä Python-koodi on jäsentää, kääntää ja suorittaa kyseisessä WebAssembly-ympäristössäei natiivisti isäntäjärjestelmässä. Tämä lähestymistapa rajoittaa luonnostaan ​​koodin mahdollisuuksia, koska Pyodide-ohjelmalla on virtuaalinen tiedostojärjestelmä muistissa, ei suoraa pääsyä isäntälevylle eikä perinteisiä taustaprosessointiominaisuuksia.

Merkittävimpiä rajoituksia ovat: ilman pääsyä varsinaiseen tiedostojärjestelmään (vain Pyodiden sisäiseen virtuaaliympäristöön), säikeiden ja moniprosessoinnin täydellinen puuttuminen, kyvyttömyys käynnistää aliprosesseja, ei pääsyä Node.js:ää suorittavan isännän muistiin, ei tilan jakamista kutsujen välillä (koska ympäristö on käynnistetty kokonaan uudelleen) ja rakenteensa vuoksi ilman verkkoyhteyttä tai internetiäTämä viimeinen rajoitus esitettiin suunnittelupäätöksenä, jota voitaisiin tarkastella tulevaisuudessa, mutta joka aluksi lisäsi uuden suojakerroksen.

Toinen eristyskerros on itse pilvikäyttöönotto: Node.js-prosessi suoritetaan Docker-kontin sisällä.joka puolestaan ​​otetaan käyttöön Google Cloud Runissa. Tämä ei ainoastaan ​​rajoita suoritusaikaa ja käytettävissä olevia resursseja, vaan myös irrottaa koodia suorittavan säilön organisaation infrastruktuurin muista osista hypoteettisen hiekkalaatikkovuodon sattuessa.

Yhteenvetona voidaan todeta, että alkuperäinen terraariosuunnittelu perustuu yhdistelmään WebAssembly, Docker ja Cloud Run rakentaa suhteellisen turvallinen ympäristö Pythonin suoritusta varten, jossa on peräkkäisiä esteitä, jotka vaikeuttavat pääsyä hiekkalaatikosta isäntäjärjestelmään ja sisäiseen verkkoon.

Paikallinen käyttöönotto, Docker-käyttöönotto ja Google Cloud Run -käyttöönotto

Terrariumin käyttämiseksi kehitysympäristössä oli välttämätöntä Node.js asennettuna koneelleKun tuo vaatimus oli täytetty, tavanomainen menettelytapa oli asentaa projektin riippuvuudet ja suorittaa paikallinen palvelin sekä funktio, joka käsittelee koodin suorituspyyntöjä.

Palvelimen ollessa käynnissä pyyntöjä voitiin tehdä paikalliseen päätepisteeseen lähetä testitiedostoja ja Python-skriptejäTämä mahdollisti kehittäjille hiekkalaatikon toiminnan validoinnin ennen siirtymistä tuotantoympäristöihin. Oli olemassa skriptejä, jotka pystyivät suorittamaan sarjan testejä kaikille testihakemiston .py-tiedostoille, mikä yksinkertaisti ympäristön varmennusta.

Konttiympäristöissä terraario voisi Rakenna Docker-kuvana ja suorita itsenäisenä säilönäTyypillisiin ohjeisiin sisältyivät rakennus-, suoritus- ja pysäytysvaiheet sekä komennot suoritettavan säilön tunnisteen paikantamiseksi ja sen manuaaliseksi hallitsemiseksi tarvittaessa.

Kun siirryttiin Google Cloud Runiin, Terrarium otettiin käyttöön automaattisesti skaalautuvana HTTP-palveluna, jossa oli konfiguroitavat resurssi- ja samanaikaisuusparametrit. Oli suositeltavaa säätää näitä arvoja tasapainottamalla suorituskykyä, kustannuksia ja turvallisuuttaEsimerkiksi intensiivisille työkuormille voitaisiin varata enemmän suorittimen ja muistin tehoa sekä rajoittaa samanaikaisuutta instanssia kohden estojen välttämiseksi.

On huomattava, että Pyodide terraariokokoonpanossa Se toimii Node.js-pääprosessissaTämä tarkoittaa, että jos Python-koodista tulee erityisen suuri tai se joutuu monimutkaisiin silmukoihin, se voi estää Node.js:n kyvyn vastata muihin pyyntöihin. Pyodide ehdottaa Worker-lomakkeiden käyttöä tilanteissa, joissa on tarpeen keskeyttää suoritukset tai eristää ne entisestään, mutta tämä lähestymistapa monimutkaistaa integrointia ja joissakin tapauksissa rajoittaa tukea kirjastoille, kuten matplotlib.

Terveyspalvelujen hallintaan ja vakauteen liittyvät kysymykset

Google Cloud Runin käyttöönotoissa yksi käytännön haasteista oli hallinta palvelun terveys ja toipuminen esteistäCloud Run ei oletusarvoisesti tue suoraan Dockerfilessä HEALTHCHECK-funktiolla määriteltyjä terveystarkistuksia, joten pieni lisämuutos oli tarpeen.

Tavanomainen menettely koostui Kuvaile Cloud Run -palvelua gcloudillakonfiguraation vienti service.yaml-tiedostoon. YAML-tiedostoon lisättiin livenessProbe-konfiguraatio, joka liittyi säilön kuvaan, jotta Cloud Run pystyi havaitsemaan, milloin palvelu lakkasi vastaamasta oikein.

Kun kokoonpanoa oli muokattu, olemassa oleva palvelu korvattiin asianmukaisella gcloud-komennolla, jotta Cloud Run Sen jälkeen se alkoi aktiivisesti seurata säiliön tilaa. Se käynnistyisi uudelleen, jos elävyystarkistus epäonnistuisi. Tämä toiminto oli tarpeen vain, kun uusi palvelu otettiin käyttöön ensimmäisen kerran kyseisellä levykuvalla.

Puhtaan Dockerin tasolla on lisärajoitus: itse Docker-moottori. Se ei tarjoa automaattisia uudelleenkäynnistyksiä pelkästään HEALTHCECK-ominaisuuden perusteella.Lisäksi prosessi, jonka PID on säiliössä 1, on erityisen suojattu, eikä sitä ole niin helppo lopettaa sisältäpäin. Siksi joissakin ympäristöissä harkitaan kolmannen osapuolen työkalujen, kuten docker-autohealin, käyttöä; nämä työkalut valvovat säiliön tilaa ja pakottavat uudelleenkäynnistykset, kun ne havaitsevat ongelmia.

Teloitusten vakauden osalta tiimi havaitsi, että jonkin verran useammin Virheitä, kuten "RangeError: Kutsupinon enimmäiskoko ylitetty", ilmestyi. Pyodide-ympäristössä käsiteltäessä erityisen raskaita työkuormia. Tämä oli yleisempää käytettäessä erittäin korkeita dpi-arvoja PNG-kuvien luonnissa matplotlibin avulla tai suoritettaessa erityisen monimutkaisia ​​pandas-operaatioita, mikä viittaa WebAssembly-ympäristön pinonhallinnan sisäisiin rajoituksiin.

Kriittinen haavoittuvuus CVE-2026-5752 Terrariumissa

Ajan myötä Erittäin vakava haavoittuvuus terraariossaTunnistettu nimellä CVE-2026-5752 ja saanut CVSS-luokitusjärjestelmässä pistemäärän 9,3. Tämä kriittisyystaso osoittaa, että kyseessä on haavoittuvuus, jolla voi olla erittäin suuri vaikutus tätä hiekkalaatikkoa käyttävien järjestelmien tietoturvaan.

Heikkous antaa hyökkääjälle mahdollisuuden suorittaa mielivaltaisen koodin suorittaminen pääkäyttäjän oikeuksilla isäntäprosessissaHyökkäysvektori perustuu JavaScript-prototyyppiketjun haitalliseen läpikulkuun Pyodide-ympäristössä WebAssemblyssa, mikä käytännössä avaa oven hiekkalaatikon asettamien rajoitusten ohittamiseen.

Huolestuttavinta on, että tätä haavoittuvuutta käytetään hyväksi Ei erityisoikeuksia tai käyttäjän toimia vaaditaHyökkääjä, joka voi syöttää koodia hiekkalaatikkoon (esimerkiksi hyödyntämällä Terrariumia käyttävän työkalun koodin suoritustoimintoa), voi hyödyntää tätä haavoittuvuutta paetakseen kontrolloidusta ympäristöstä.

Kun haavoittuvuutta on hyödynnetty, se voi mahdollistaa luvattoman pääsyn arkaluontoiset järjestelmätiedostotKuin /etc/passwd tai muita sisäisiä säilöresurssejaja jopa mahdollistaa eskaloinnin isäntäpalvelimelle tai muille saman infrastruktuurin jakaville palveluille yleisestä suojauskokoonpanosta riippuen.

Tämä tilanne aiheuttaa merkittävän riskin kaikki organisaatiot, jotka käyttävät Terrariumia käyttäjäkoodina tai tekoälymallin suoritusympäristönäTämä ei ole vain teoreettinen epäonnistuminen, vaan skenaario, jossa hiekkalaatikkomurto voi johtaa datan paljastumiseen, sisäisten palveluiden vaarantumiseen ja verkon sisäiseen sivuttaisliikkeeseen.

Vaikutus yrityksiin, kehittäjiin ja loppukäyttäjiin

Tämän haavoittuvuuden löytyminen vaikuttaa suoraan kaikkiin yrityksiin ja kehittäjiin, jotka ovat Terrarium on integroitu infrastruktuuriinsa epäluotettavan Python-koodin suorittamiseksi.Yhteistyökehitystyökalut, oppimisalustat, tilausanalytiikkapalvelut tai tekoälypohjaiset koodiaputuotteet voivat altistua, jos ne käyttävät Terrariumia suorituksenaikaisena kerroksenaan.

Loppukäyttäjän näkökulmasta riskinä ei ole ainoastaan ​​palveluntarjoajan infrastruktuurin vaarantuminen, vaan myös se, että näille alustoille tallennetut henkilökohtaiset tai ammatilliset tiedot voi vuotaa tai sitä voidaan manipuloida ilman ennakkoilmoitusta, jos hyökkääjä onnistuu hyödyntämään haavoittuvuutta.

Vakavuus kasvaa, koska on huomautettu, että Terraariota ei enää hoideta aktiivisesti.Tämä tarkoittaa, että virallista korjauspäivitystä ongelman korjaamiseksi ei ole odotettavissa, joten organisaatiot, jotka edelleen luottavat tähän ratkaisuun, kohtaavat työkalun, jolla on tunnettu haavoittuvuus eikä tukea.

Tässä yhteydessä terraarion käytön jatkaminen ilman lisätoimenpiteitä tarkoittaa ottaa huomattavan turvallisuusriskinHyökkääjät, jotka ovat tietoisia hyväksikäyttövektorista, voivat kohdistaa hyökkäyksensä erityisesti palveluihin, jotka käyttävät tätä teknologiaa edelleen, ja etsiä heikkouksia järjestelmän yleisestä suojauksesta.

Lisäksi ympäristöissä, joissa useat palvelut jakavat saman sisäisen verkon tai jopa saman konttiklusterin, Terrariumin vuoto voi avata oven sivuttaisliikkeet kohti muita näennäisesti eristettyjä järjestelmiämikä vahvistaa onnistuneen hyökkäyksen mahdollista vaikutusta.

Lieventämisstrategiat ja harkittavat vaihtoehdot

Ottaen huomioon tämän suuruusluokan haavoittuvuuden ja aktiivisen ylläpidon puuttumisen, organisaatioille suunnattu ensimmäinen suositus on arvioidaan kiireellisesti terraarioiden nykyistä käyttöäJos sitä käytetään kolmannen osapuolen koodin tai tekoälymallien luoman koodin suorittamiseen, altistuminen on suurempi ja vaatii välittömiä toimia.

Lyhyen aikavälin toimenpiteisiin kuuluu mahdollisuus Poista tilapäisesti käytöstä funktiot, jotka sallivat mielivaltaisen koodin suorittamisen Terrariumia otetaan käyttöön tuotannossa samalla kun turvallisempaa vaihtoehtoa arvioidaan. Muita vaihtoehtoja ovat verkkokäytäntöjen vahvistaminen, Terrariumia käyttävien palveluiden segmentointi entisestään ja muiden järjestelmien pääsyn rajoittaminen konttiin.

Keskipitkällä aikavälillä se voi olla järkevämpää siirtyä muihin hiekkalaatikko- tai erillisiin toteutusratkaisuihin joilla on aktiivinen ylläpito ja joiden takana on yhteisö tai palveluntarjoaja, joka huolehtii haavoittuvuuksien korjaamisesta. Tämä voi sisältää hallittuja palveluita, palvelimettomia suoritusympäristöjä tiukemmilla rajoituksilla tai mikropalveluarkkitehtuureja, jotka on erityisesti suunniteltu oletusarvoisesti tietoturvallisilla ominaisuuksilla.

Joka tapauksessa tämä tapaus korostaa sen tärkeyttä, että integroi hyvät tietoturvakäytännöt kehityssykliin: määräaikaistarkastukset riippuvuudet, arkkitehtuurissa käytettyjen kolmansien osapuolten komponenttien tarkastelu, asiaankuuluvien CVE-uhkien seuranta ja nopeat reagointisuunnitelmat kriittisen vian havaitsemisen yhteydessä.

Yritysten, jotka rakentavat tekoälypohjaisia ​​työkaluja, joiden avulla loppukäyttäjät voivat suorittaa tai luoda koodia, tulisi analysoida hiekkalaatikoidensa suunnittelua erittäin huolellisestiVarmista, että eristysprosessit pidetään ajan tasalla, ja vältä hylättyihin projekteihin luottamista sellaisissa arkaluontoisissa toiminnoissa, kuten epäluotettavan koodin suorittamisessa.

Kaikki terraarioon liittyvä heijastaa sitä, missä määrin Käyttäjä- ja LLM-mallikoodin suorittaminen vaatii äärimmäistä turvallisuuslähestymistapaaHyvän suorituskyvyn ja edullisuuden omaava hiekkalaatikko saattaa vaikuttaa erittäin houkuttelevalta, mutta jos ilmenee kriittinen haavoittuvuus, johon ei ole odotuksia korjauksesta, tasapaino rikkoutuu ja riskistä tulee monissa vakavissa käyttötapauksissa kohtuuton.