- Terrarium ir Python smilškaste, kuras pamatā ir Pyodide un ko var izvietot Cloud Run platformā, un kas paredzēta neuzticama koda palaišanai ar zemām izmaksām un pieņemamu latentumu.
- Vide piedāvā uz izsaukumiem balstītu nodalījumu veidošanu, atbalstu vairākām zinātniskām bibliotēkām un ievades un izvades failu apstrādi, izmantojot virtuālu failu sistēmu.
- Tās arhitektūra apvieno WebAssembly, Node.js, Docker un Cloud Run, lai izolētu kodu, taču ir konstatētas stabilitātes un pakalpojumu veselības pārvaldības problēmas.
- Kritiskā ievainojamība CVE-2026-5752 ļauj izpildīt kodu ar root privilēģijām, un nav plānots veikt nekādus ielāpus, tāpēc ieteicams izvērtēt mazināšanas pasākumus un alternatīvas.
Runājot par neuzticama vai mākslīgā intelekta ģenerēta Python koda palaišanu , viens no lielākajiem izaicinājumiem ir tas, kā to izdarīt droši , ātri un neiztērējot pārāk daudz infrastruktūras. Tieši šajā kontekstā radās Terrarium — Cohere AI risinājums, kas izstrādāts kā smilškaste šāda veida koda mitināšanai un palaišanai mākonī izvietotos konteineros, īpaši pakalpojumā Google Cloud Run.
Šī pieeja ļāva izstrādātājiem un uzņēmumiem izmantot Terrarium kā izolētu vidi lietotāja koda vai LLM modeļu izvietošanai par saprātīgām izmaksām un ar samērā labu veiktspēju. Tomēr laika gaitā ir atklājušās arī ļoti nopietnas ievainojamības , tostarp viena ar CVE identifikatoru, kas atklāj kritiskus trūkumus smilškastes drošībā un ir nostādījis Terrarium uzmanības centrā.
Kas ir terārijs un kādam nolūkam tas tika izstrādāts?
Terrarium būtībā ir izolēta Python izpildlaika vide , kas paredzēta darbībai kā izvietojams Docker konteiners , piemēram, pakalpojumā Google Cloud Run. Tās galvenais mērķis ir nodrošināt “smilškasti”, kur var izvietot potenciāli bīstamu vai nezināmu kodu (piemēram, lietotāja iesniegtus skriptus vai valodas ģenerētus fragmentus), tieši neapdraudot galveno infrastruktūru.
Projekta filozofija ir nodrošināt pieejamu, zemas latentuma pakalpojumu, ko ir viegli integrēt esošajās darbplūsmās. Terrarium tika izstrādāts tā, lai to varētu izsaukt, izmantojot HTTP pieprasījumus, nosūtot izpildāmo Python kodu — un pēc izvēles ievades failus — un saņemot atpakaļ izpildes rezultātus kopā ar ģenerētajiem failiem.
Praksē tas nozīmē, ka ārēja sistēma, API vai pat iekšējs rīks var deleģēt Python koda izpildi Terrarium , saglabājot šo kodu relatīvi ierobežotā vidē ar skaidriem noteikumiem par resursiem, izpildes laiku un atļautajām iespējām.
Viena no Terrarium galvenajām dizaina iezīmēm ir tā atkarība no Pyodide — CPython uz WebAssembly būvējuma, kas tiek izpildīts Node.js procesā. Šī pieeja nozīmē, ka Python kods nedarbojas lokāli resursdatora sistēmā, bet gan iekapsulētā interpretētājā, teorētiski pastiprinot tā izolāciju.
Smilškastes veiktspēja, izmaksas un galvenās iezīmes
Viens no Terrarium spēcīgākajiem pārdošanas argumentiem bija zemo ekspluatācijas izmaksu un pieņemamas veiktspējas kombinācija . Reālās pasaules izvietojumos pakalpojumā Google Cloud Run ar tipisku konfigurāciju 2 GB atmiņas, 1 vCPU un vismaz vienu vienmēr ieslēgtu instanci ar automātisko mērogošanu pēc pieprasījuma ziņotās ikmēneša izmaksas iekšējās anotācijas fāzēs bija aptuveni 30 USD.
Runājot par ātrumu, aprakstītie testi liecina, ka Terrarium varēja ģenerēt, piemēram, vienkārša matplotlib diagrammas 200 dpi PNG attēlu aptuveni 900 ms izpildlaikā vai SVG versiju aptuveni 500 ms. Šie laiki attiecas uz kodu, kas tiek mitināts Cloud Run, ieskaitot pakalpojuma tipisko izsaukšanas ciklu.
Papildus veiktspējai Terrarium lepojās ar pilnīgu nodalījumu starp izsaukumiem . Pēc katra izsaukuma smilškaste tika pilnībā pārstrādāta: Pyodide virtuālā failu sistēma, globālie mainīgie, ielādētās bibliotēkas un jebkurš iekšējais stāvoklis tika atmesti. Mērķis bija novērst datu vai konteksta mantojumu no iepriekšējās izpildes jebkuram izsaukumam, tādējādi samazinot informācijas noplūdes risku.
Vēl viens svarīgs aspekts ir tas, ka, lai gan mērķis bija stabila izolācija, Cohere skaidri norādīja, ka tas nepiedāvā absolūtas garantijas attiecībā uz smilškastes integritāti . Tas jau lika domāt, ka, neskatoties uz aizsardzības slāņiem, pastāv iespēja atklāt ievainojamības, īpaši tik sarežģītā vidē kā WebAssembly un tā integrācija ar Node.js.
Terrarium tika izstrādāts tā, lai to būtu viegli lietot no citiem pakalpojumiem: vienkārši nosūtiet HTTP pieprasījumu uz Cloud Run izvietoto galapunktu kopā ar izpildāmo kodu un autorizācijas marķieri (ja to pieprasa konfigurācija). Apmaiņā pret to jūs saņemat JSON failu ar rezultātiem un, ja piemērojams, ģenerētajiem failiem, kas kodēti base64.
Failu izpilde un bibliotēkas atbalsts valodā Pyodide
Viena no Terrarium pievilcīgajām funkcijām bija tā spēja strādāt ar ievades un izvades failiem dabiski . API ļāva pievienot vairākus jebkura veida failus kopā ar Python kodu pieprasījumā; tie tika ievietoti virtuālajā failu sistēmā, ko Pyodide atklāj Python interpretētājam.
Izpildes laikā Python kods varēja nolasīt un manipulēt ar šiem failiem tā, it kā tie atrastos lokāli smilškastē. Kad izpilde bija pabeigta, Terrarium apkopoja visus izveidotos vai modificētos failus un atgrieza tos klientam atbildē, parasti kodētus nemanāmai pārsūtīšanai, izmantojot HTTP.
Runājot par bibliotēkas ekosistēmu, Terrarium, kas ir balstīta uz Pyodide, ir mantojis diezgan plašu zinātnisko un datu analīzes pakotņu komplektu . Tieši atbalstītās pakotnes ietver: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy un sqlite3 (pēdējā pēc noklusējuma nav iespējota, bet ar iespēju to ielādēt, ja nepieciešams).
Konkrētajā matplotlib gadījumā bija daži ierobežojumi: plt.show() šajā vidē netika atbalstīts , bet plt.savefig() izmantošana attēlu ģenerēšanai darbojās pareizi, ja vien netika uzspiesti pārmērīgi parametri, piemēram, ārkārtīgi augsta izšķirtspēja, kas palielinātu resursu izmantošanu.
Šis bibliotēku kopums padarīja Terrarium īpaši noderīgu tādiem uzdevumiem kā datu analīze, vizualizācija, mašīnmācīšanās modeļu prototipu veidošana un strukturētas informācijas manipulēšana, kas visi tika veikti teorētiski kontrolētā smilškastē.
Iekšējā arhitektūra: izolācijas un izvietošanas slāņi
Terrarium arhitektūra ir veidota vairākos slāņos, kas paredzēti, lai samazinātu uzbrukuma virsmu un pēc iespējas vairāk izolētu neuzticamu kodu . Pirmais slānis ir pats Node.js process, kas darbojas kā resursdators un ielādē Pyodide, tas ir, CPython, kas kompilēts WebAssembly formātā.
Lietotāja iesniegtais Python kods tiek parsēts, kompilēts un izpildīts WebAssembly vidē , nevis tieši resursdatora sistēmā. Šī pieeja pēc būtības ierobežo koda iespējas, jo Pyodide izmanto virtuālu failu sistēmu atmiņā, tam nav tiešas piekļuves resursdatora diskam un tam nav tradicionālu fona apstrādes iespēju.
Starp atbilstošākajiem ierobežojumiem ir: piekļuves neesamība reālajai failu sistēmai (tikai Pyodide iekšējai virtuālajai failu sistēmai), pilnīga pavedienu un vairāku apstrādes procesu neesamība, nespēja palaist apakšprocesus, piekļuves neesamība resursdatora, kurā darbojas Node.js, atmiņai, stāvokļa koplietošanas neesamība starp izsaukumiem (jo visa vide tiek restartēta) un, pēc būtības, piekļuves neesamība tīklam vai internetam . Šis pēdējais ierobežojums bija paredzēts kā dizaina lēmums, ko varētu pārskatīt nākotnē, taču sākotnēji tas radīja vēl vienu strīdus slāni.
Otrais izolācijas līmenis ir pati izvietošana mākonī: Node.js process darbojas Docker konteinerā , kas tiek izvietots pakalpojumā Google Cloud Run. Tas ne tikai ierobežo izpildlaiku un pieejamos resursus, bet arī atvieno konteineru, kurā darbojas kods, no jebkuras citas organizācijas infrastruktūras daļas hipotētiskas smilškastes drošības pārkāpuma gadījumā.
Rezumējot, Terrarium sākotnējais dizains balstās uz WebAssembly, Docker un Cloud Run kombināciju , lai izveidotu relatīvi drošu vidi Python izpildei, ar secīgām barjerām, kas sarežģī izkļūšanu no smilškastes uz resursdatora sistēmu un iekšējo tīklu.
Lokālā izvietošana, Docker izvietošana un Google Cloud Run izvietošana
Lai Terrarium izmantotu izstrādes vidē, datorā bija jāinstalē Node.js. Kad šī prasība bija izpildīta, parastā procedūra ietvēra projekta atkarību instalēšanu un lokālā servera palaišanu, kā arī funkciju, kas apstrādā koda izpildes pieprasījumus.
Kamēr serveris darbojās, lokālajam galapunktam varēja veikt pieprasījumus nosūtīt testa failus un Python skriptus , ļaujot izstrādātājiem pārbaudīt smilškastes darbību pirms izvietošanas ražošanas vidē. Bija pieejami skripti, lai veiktu testu komplektu visiem .py failiem testa direktorijā, vienkāršojot vides verifikāciju.
Konteinerizētās vidēs Terrarium varēja veidot kā Docker attēlu un darboties kā atsevišķu konteineru . Tipiskas instrukcijas ietvēra izveides, palaišanas un apturēšanas darbības, kā arī komandas, lai atrastu darbojošā konteinera identifikatoru un nepieciešamības gadījumā to manuāli pārvaldītu.
Kad Terrarium migrēja uz Google Cloud Run, tas tika izvietots kā automātiski mērogojošs HTTP pakalpojums ar konfigurējamiem resursu un vienlaicības parametriem. Bija ieteicams pielāgot šīs vērtības, lai līdzsvarotu veiktspēju, izmaksas un drošību . Piemēram, intensīvām darba slodzēm varēja piešķirt vairāk centrālā procesora un atmiņas, un vienlaicīgumu katrā instancē varēja ierobežot, lai novērstu bloķēšanu.
Ir svarīgi atzīmēt, ka Pyodide, konfigurējot to Terrarium, darbojas galvenajā Node.js procesā . Tas nozīmē, ka, ja jūsu Python kods kļūst īpaši resursu ietilpīgs vai nonāk sarežģītās cilpās, tas var bloķēt Node.js spēju reaģēt uz citiem pieprasījumiem. Pyodide iesaka izmantot Workers scenārijos, kad ir nepieciešams pārtraukt vai vēl vairāk izolēt izpildi, taču šī pieeja sarežģī integrāciju un dažos gadījumos ierobežo atbalstu tādām bibliotēkām kā matplotlib.
Veselības aprūpes pakalpojumu pārvaldības un stabilitātes jautājumi
Izvietojumos pakalpojumā Google Cloud Run viena no praktiskajām problēmām bija pakalpojumu veselības uzraudzība un atkopšana pēc avārijām . Cloud Run pēc noklusējuma tieši neatbalsta veselības pārbaudes, kas definētas Dockerfiles, izmantojot HEALTHCHECK, tāpēc bija nepieciešama neliela papildu korekcija.
Parastā procedūra ietvēra Cloud Run pakalpojuma aprakstīšanu ar gcloud un konfigurācijas eksportēšanu uz service.yaml failu. Šajā YAML failā tika pievienota livenessProbe konfigurācija, kas saistīta ar konteinera attēlu, lai Cloud Run varētu noteikt, kad pakalpojums pārstāj pareizi reaģēt.
Kad konfigurācija bija modificēta, esošais pakalpojums tika aizstāts ar atbilstošo gcloud komandu, lai Cloud Run aktīvi uzraudzītu konteinera statusu un restartētu to, ja tiešsaistes pārbaude neizdotos. Šī darbība bija nepieciešama tikai pirmo reizi, kad jauns pakalpojums tika izvietots ar šo konkrēto attēlu.
Tīrā Docker līmenī pastāv papildu ierobežojums: pats Docker dzinējs nepiedāvā automātisku restartēšanu, pamatojoties tikai uz HEALTHCHECK . Turklāt process ar PID 1 konteinerā ir īpaši aizsargāts un to nav tik viegli pārtraukt no iekšpuses. Tāpēc dažās vidēs tiek apsvērta trešo pušu rīku, piemēram, docker-autoheal, izmantošana, kas uzrauga konteinera veselību un piespiedu restartēšanu, ja tiek konstatētas problēmas.
Runājot par izpildes stabilitāti, komanda novēroja, ka , apstrādājot īpaši lielas darba slodzes, Pyodide vidē bieži parādījās tādas kļūdas kā "RangeError: Maximum call steck size exceeded". Tas bija biežāk sastopams, izmantojot ļoti augstas dpi vērtības PNG ģenerēšanā ar matplotlib vai veicot īpaši sarežģītas pandas darbības, kas liecina par iekšējiem ierobežojumiem steka pārvaldībā WebAssembly vidē.
Kritiska ievainojamība CVE-2026-5752 Terrarium vidē
Laika gaitā Terrarium ir atklāta kritiska ievainojamība , kas identificēta kā CVE-2026-5752 un novērtēta ar 9,3 ballēm CVSS skalā. Šis nopietnības līmenis norāda uz trūkumu, kam var būt ļoti liela ietekme uz sistēmu drošību, kas izmanto šo smilškasti.
Šī ievainojamība ļauj uzbrucējam veikt patvaļīgu koda izpildi ar root privilēģijām resursdatora procesā . Uzbrukuma vektors balstās uz ļaunprātīgu prototipa ķēdes šķērsošanu Pyodide WebAssembly vidē, efektīvi apejot smilškastes ierobežojumus.
Visbažīgākais aspekts ir tas, ka šīs ievainojamības izmantošanai nav nepieciešamas īpašas privilēģijas vai papildu lietotāja mijiedarbība . Uzbrucējs, kurš var ievadīt kodu smilškastē (piemēram, izmantojot koda izpildes funkcionalitāti rīkā, kas izmanto Terrarium), var izmantot šo trūkumu, lai izkļūtu no kontrolētās vides.
Kad ievainojamība tiek izmantota, tā var nodrošināt nesankcionētu piekļuvi sensitīviem sistēmas failiem , piemēram , /etc/passwd vai citiem iekšējiem konteinera resursiem , un pat nodrošināt eskalāciju uz resursdatoru vai citiem pakalpojumiem, kas koplieto to pašu infrastruktūru, atkarībā no vispārējās drošības konfigurācijas.
Šī situācija rada ievērojamu risku visām organizācijām, kas izmanto Terrarium kā lietotāja kodu vai mākslīgā intelekta modeļa izpildes vidi . Tā nav tikai teorētiska ievainojamība, bet gan scenārijs, kurā smilškastes pārkāpums var izraisīt datu izpaušanu, iekšējo pakalpojumu apdraudēšanu un sānu pārvietošanos tīklā.
Ietekme uz uzņēmumiem, izstrādātājiem un gala lietotājiem
Šīs ievainojamības atklāšana tieši ietekmē jebkuru uzņēmumu vai izstrādātāju, kas ir integrējis Terrarium savā infrastruktūrā, lai palaistu neuzticamu Python kodu . Sadarbības izstrādes rīki, mācību platformas, pieprasījuma analīzes pakalpojumi vai uz mākslīgo intelektu balstīti koda palīdzības produkti var tikt pakļauti ievainojamībai, ja tie izmanto Terrarium kā savu izpildlaika slāni.
No gala lietotāja viedokļa risks ir ne tikai tas, ka var tikt apdraudēta pakalpojumu sniedzēja infrastruktūra, bet arī tas, ka šajās platformās glabātā personiskā vai profesionālā informācija var tikt nopludināta vai manipulēta bez iepriekšēja brīdinājuma, ja uzbrucējam izdodas izmantot ievainojamību.
Situāciju vēl vairāk sarežģī fakts, ka Terrarium vairs netiek aktīvi uzturēts . Tas nozīmē, ka oficiāls ielāps problēmas novēršanai nav gaidāms, atstājot organizācijas, kas turpina paļauties uz šo risinājumu, ar zināmu ievainojamību un bez atbalsta.
Šajā kontekstā Terrarium lietošanas turpināšana bez papildu pasākumiem rada ievērojamu drošības risku . Uzbrucēji, kas ir informēti par izmantošanas vektoru, var īpaši mērķēt uz pakalpojumiem, kas turpina izmantot šo tehnoloģiju, meklējot vājās vietas sistēmas vispārējā drošībā.
Turklāt vidēs, kur vairākiem pakalpojumiem ir viens un tas pats iekšējais tīkls vai pat viens un tas pats konteineru klasteris, noplūde no Terrarium varētu pavērt durvis sāniskai kustībai uz citām šķietami izolētām sistēmām , pastiprinot veiksmīga uzbrukuma potenciālo ietekmi.
Mazināšanas stratēģijas un alternatīvas, kas jāapsver
Ņemot vērā šāda mēroga ievainojamību un aktīvas uzturēšanas trūkumu, pirmais ieteikums organizācijām ir steidzami novērtēt pašreizējo Terrarium lietojumu . Ja tas tiek izmantots trešo pušu koda vai mākslīgā intelekta modeļu ģenerēta koda palaišanai, atkarību risks ir lielāks un nepieciešama tūlītēja rīcība.
Īstermiņa pasākumi ietver tādu funkciju īslaicīgu atspējošanu, kas ļauj izpildīt patvaļīgu kodu ražošanas vidē, kamēr tiek izvērtēta drošāka alternatīva. Citas iespējas ietver tīkla politikas stiprināšanu, pakalpojumu, kas izmanto Terrarium, turpmāku segmentēšanu un piekļuves ierobežošanu konteineram no citām sistēmām.
Vidējā termiņā varētu būt saprātīgāk migrēt uz citiem smilškastes vai izolētiem izpildes risinājumiem , kuriem ir aktīva uzturēšana un kopiena vai pakalpojumu sniedzējs, kas aiz tiem novērš ievainojamības. Tas varētu ietvert pārvaldītus pakalpojumus, bezserveru izpildes vides ar stingrākiem ierobežojumiem vai mikropakalpojumu arhitektūras, kas īpaši izstrādātas ar noklusējuma drošību.
Jebkurā gadījumā šis incidents uzsver labas drošības prakses integrēšanas nozīmi izstrādes dzīves ciklā : regulāras atkarību revīzijas, arhitektūrā izmantoto trešo pušu komponentu pārskatīšana, attiecīgo CVE uzraudzība un ātras reaģēšanas plāni kritiskas kļūmes atklāšanas gadījumā.
Uzņēmumiem, kas izstrādā uz mākslīgo intelektu balstītus rīkus, kas ļauj lietotājiem palaist vai ģenerēt kodu, rūpīgi jāanalizē savu smilškastes dizains , jānodrošina, ka izolācijas procesi tiek atjaunināti, un jāizvairās no paļaušanās uz pamestiem projektiem tādām sensitīvām funkcijām kā neuzticama koda palaišana.
Viss Terrarium platformā atspoguļo to, cik lielā mērā lietotāja koda un LLM modeļu palaišana prasa ārkārtēju drošības pieeju . Augstas veiktspējas un lēta “sandbox” vide var šķist ļoti pievilcīga, taču, ja parādās kritiska ievainojamība bez redzama labojuma, līdzsvars tiek izjaukts un risks daudziem nopietniem lietošanas gadījumiem kļūst nepieņemams.
