- Terrarium je Python sandbox baziran na Pyodide-u i prilagodljiv na Cloud Run, dizajniran za pokretanje nepouzdanog koda s niskom cijenom i prihvatljivom latencijom.
- Okruženje nudi kompartmentalizaciju zasnovanu na pozivanju, podršku za više naučnih biblioteka i rukovanje ulaznim i izlaznim datotekama putem virtuelnog sistema datoteka.
- Njegova arhitektura kombinuje WebAssembly, Node.js, Docker i Cloud Run kako bi izolovala kod, ali su otkriveni problemi sa stabilnošću i upravljanjem stanjem servisa.
- Kritična ranjivost CVE-2026-5752 omogućava izvršavanje koda s root privilegijama, bez planiranih zakrpa, pa se preporučuje procjena ublažavanja i alternativa.
Kada govorimo o pokretanju nepouzdanog ili AI generiranog Python koda , jedan od najvećih izazova je kako to učiniti sigurno , brzo i bez prevelikog opterećenja infrastrukture. U tom kontekstu se pojavio Terrarium, rješenje kompanije Cohere AI dizajnirano kao sandbox za hosting i pokretanje ove vrste koda unutar kontejnera raspoređenih u oblaku, posebno na Google Cloud Run platformi.
Ovaj pristup je omogućio programerima i kompanijama da iskoriste Terrarium kao izolovano okruženje za implementaciju korisničkog koda ili LLM modela po razumnoj cijeni i sa prilično dobrim performansama. Međutim, vremenom su otkrivene i vrlo ozbiljne ranjivosti , uključujući onu sa CVE identifikatorom koja otkriva kritične nedostatke u sigurnosti sandbox-a i stavila Terrarium u centar pažnje.
Šta je terarijum i čemu služi?
Terrarium je u suštini izolirano okruženje za izvršavanje Pythona , dizajnirano da funkcionira kao Docker kontejner koji se može implementirati , na primjer, na Google Cloud Runu. Njegova glavna svrha je osigurati sandbox u kojem se potencijalno opasan ili nepoznati kod (kao što su skripte koje su poslali korisnici ili isječci generirani jezikom) može implementirati bez direktnog ugrožavanja glavne infrastrukture.
Filozofija koja stoji iza projekta fokusira se na pružanje pristupačne usluge s niskom latencijom koju je lako integrirati u postojeće tokove rada. Terrarium je dizajniran da se poziva putem HTTP zahtjeva, šaljući Python kod koji treba izvršiti - i opcionalno ulazne datoteke - i primajući nazad rezultate izvršenja zajedno s generiranim datotekama.
U praksi, ovo znači da eksterni sistem, API ili čak interni alat mogu delegirati izvršavanje Python koda Terrariumu , držeći taj kod unutar relativno ograničenog okruženja, s jasnim pravilima o resursima, vremenu izvršavanja i dozvoljenim mogućnostima.
Jedna od ključnih karakteristika dizajna Terrariuma je njegovo oslanjanje na Pyodide, CPython-WebAssembly build koji se izvršava unutar Node.js procesa. Ovaj pristup znači da se Python kod ne pokreće izvorno na host sistemu, već unutar enkapsuliranog interpretera, teoretski jačajući njegovu izolaciju.
Performanse, troškovi i glavne karakteristike sandbox-a
Jedna od najjačih prodajnih prednosti Terrariuma bila je kombinacija niskih operativnih troškova i prihvatljivih performansi . U stvarnim implementacijama na Google Cloud Runu, s tipičnom konfiguracijom od 2 GB memorije, 1 vCPU-a i barem jednom uvijek uključenom instancom s automatskim skaliranjem na zahtjev, prijavljeni mjesečni trošak je bio oko 30 dolara tokom faza internih anotacija.
Što se tiče brzine, opisani testovi pokazuju da Terrarium može generirati, na primjer, PNG sliku jednostavnog matplotlib grafikona od 200 dpi za oko 900 ms vremena izvođenja ili SVG verziju za približno 500 ms. Ova vremena se odnose na kod hostovan na Cloud Runu, uključujući tipičan ciklus pozivanja servisa.
Pored performansi, Terrarium se mogao pohvaliti potpunom podjelom između poziva . Nakon svakog poziva, sandbox je bio potpuno recikliran: Pyodideov virtuelni datotečni sistem, globalne varijable, učitane biblioteke i svako interno stanje su odbačeni. Cilj je bio spriječiti da bilo koji poziv nasljeđuje podatke ili kontekst iz prethodnog izvršavanja, čime se smanjuje rizik od curenja informacija.
Još jedna važna stvar je da, iako je cilj bio robusna izolacija, Cohere je jasno stavio do znanja da ne nudi apsolutne garancije u pogledu integriteta sandboxa . Ovo je već nagovijestilo da, uprkos slojevima zaštite, postoji mogućnost da se otkriju slabosti, posebno u okruženju složenom kao što je WebAssembly i njegova integracija sa Node.js.
Terrarium je dizajniran da bude jednostavan za korištenje iz drugih servisa: jednostavno pošaljite HTTP zahtjev krajnjoj tački postavljenoj na Cloud Run, zajedno s kodom koji treba izvršiti i tokenom za autorizaciju (ako je to potrebno konfiguracijom). Zauzvrat, dobit ćete JSON datoteku s rezultatima i, ako je primjenjivo, generiranim datotekama kodiranim u base64.
Izvršavanje datoteka i podrška za biblioteke u Pyodideu
Jedna od atraktivnih karakteristika Terrariuma bila je njegova sposobnost da izvorno radi sa ulaznim i izlaznim datotekama . API je omogućavao da se više datoteka bilo koje vrste prilože zajedno sa Python kodom u zahtjevu; one su bile smještene u virtuelni sistem datoteka koji Pyodide izlaže Python interpreteru.
Tokom izvršavanja, Python kod je mogao čitati i manipulirati ovim datotekama kao da su lokalne unutar sandboxa. Nakon što bi izvršavanje bilo završeno, Terrarium bi prikupio sve kreirane ili modificirane datoteke i vratio ih u odgovoru klijentu, obično kodirane za nesmetan prijenos preko HTTP-a.
Što se tiče bibliotečkog ekosistema, budući da je zasnovan na Pyodideu, Terrarium je naslijedio prilično opsežan skup naučnih i paketa za analizu podataka . Direktno podržani paketi uključuju: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy i sqlite3 (potonji nije omogućen po defaultu, ali ima opciju da se učitava ako je potrebno).
U konkretnom slučaju matplotlib-a, postojala su neka ograničenja: plt.show() nije bio podržan u ovom okruženju, ali je korištenje plt.savefig() za generiranje slika ispravno funkcioniralo, sve dok se nisu forsirali prekomjerni parametri, poput ekstremno visokih rezolucija koje bi povećale korištenje resursa.
Ovaj skup biblioteka učinio je Terrarium posebno korisnim za zadatke kao što su analiza podataka, vizualizacija, izrada prototipova modela mašinskog učenja i manipulisanje strukturiranim informacijama, a sve se izvršava unutar teoretski kontrolisanog sandbox-a.
Unutrašnja arhitektura: slojevi izolacije i implementacije
Arhitektura Terrariuma izgrađena je u nekoliko slojeva osmišljenih da smanje površinu za napad i što više izoluju nepouzdani kod . Prvi sloj je sam Node.js proces, koji djeluje kao domaćin i učitava Pyodide, odnosno CPython kompajliran u WebAssembly.
Python kod koji korisnik šalje se parsira, kompajlira i izvršava unutar WebAssembly okruženja , a ne izvorno na host sistemu. Ovaj pristup inherentno ograničava ono što kod može uraditi, budući da Pyodide koristi virtuelni datotečni sistem u memoriji, nema direktan pristup host disku i nema tradicionalne mogućnosti obrade u pozadini.
Među najrelevantnijim ograničenjima su: nema pristupa stvarnom datotečnom sistemu (samo Pyodideov interni virtuelni datotečni sistem), potpuno odsustvo niti i multiprocesiranja, nemogućnost pokretanja podprocesa, nema pristupa memoriji hosta na kojem se izvršava Node.js, nema dijeljenja stanja između poziva (pošto se cijelo okruženje ponovo pokreće) i, po dizajnu, nema pristupa mreži ili internetu . Ovo posljednje ograničenje je zamišljeno kao dizajnerska odluka koja bi se mogla revidirati u budućnosti, ali je u početku dodalo još jedan sloj spora.
Drugi sloj izolacije je samo raspoređivanje u oblaku: Node.js proces se izvršava unutar Docker kontejnera , koji je raspoređen na Google Cloud Run. Ovo ne samo da ograničava vrijeme izvođenja i dostupne resurse, već i odvaja kontejner koji pokreće kod od bilo kojeg drugog dijela infrastrukture organizacije u slučaju hipotetičkog kršenja sandboxa.
Ukratko, originalni dizajn Terrariuma oslanja se na kombinaciju WebAssemblyja, Dockera i Cloud Runa kako bi se izgradilo relativno sigurno okruženje za izvršavanje Pythona, sa sukcesivnim barijerama koje komplikuju bijeg iz sandboxa do host sistema i interne mreže.
Lokalno raspoređivanje, raspoređivanje Dockera i raspoređivanje Google Cloud Runa
Za korištenje Terrariuma u razvojnom okruženju, bilo je potrebno imati Node.js instaliran na mašini . Nakon što je taj zahtjev ispunjen, uobičajena procedura se sastojala od instaliranja zavisnosti projekta i pokretanja lokalnog servera, zajedno s funkcijom koja obrađuje zahtjeve za izvršavanje koda.
Dok je server radio, lokalnoj krajnjoj tački su se mogli slati zahtjevi za slanje testnih datoteka i Python skripti , što je programerima omogućavalo da provjere ponašanje sandbox-a prije implementacije u produkcijska okruženja. Skripte su bile dostupne za pokretanje niza testova na svim .py datotekama u testnom direktoriju, što je pojednostavilo verifikaciju okruženja.
U kontejneriziranim okruženjima, Terrarium se mogao izgraditi kao Docker slika i pokrenuti kao samostalni kontejner . Tipične upute uključivale su korake izgradnje, pokretanja i zaustavljanja, kao i naredbe za lociranje identifikatora pokrenutog kontejnera i ručno upravljanje njime ako je potrebno.
Kada je Terrarium migrirao na Google Cloud Run, implementiran je kao HTTP servis s automatskim skaliranjem i konfiguriranim parametrima resursa i konkurentnosti. Bilo je preporučljivo prilagoditi ove vrijednosti kako bi se uravnotežile performanse, troškovi i sigurnost . Na primjer, za intenzivna opterećenja, moglo bi se dodijeliti više CPU-a i memorije, a konkurentnost po instanci mogla bi se ograničiti kako bi se spriječilo blokiranje.
Važno je napomenuti da se Pyodide, kada je konfigurisan za Terrarium, pokreće u glavnom Node.js procesu . To znači da ako vaš Python kod postane posebno intenzivan u pogledu resursa ili uđe u složene petlje, može blokirati Node.js-ovu sposobnost da odgovori na druge zahtjeve. Pyodide predlaže korištenje Workera za scenarije gdje je potrebno prekinuti ili dodatno izolovati izvršavanja, ali ovaj pristup komplikuje integraciju i, u nekim slučajevima, ograničava podršku za biblioteke poput matplotlib-a.
Problemi upravljanja zdravstvenim uslugama i stabilnosti
Prilikom implementacije na Google Cloud Runu, jedan od praktičnih izazova bio je praćenje stanja servisa i oporavak od rušenja sistema . Cloud Run, prema zadanim postavkama, ne podržava direktno provjere stanja definisane u Dockerfiles-u pomoću HEALTHCHECK-a, tako da je bilo potrebno malo dodatno prilagođavanje.
Uobičajena procedura je uključivala opisivanje Cloud Run servisa pomoću gcloud-a , izvoz konfiguracije u service.yaml datoteku. Unutar tog YAML-a, dodana je konfiguracija livenessProbe-a, povezana sa slikom kontejnera, tako da Cloud Run može detektovati kada servis prestane ispravno reagovati.
Nakon što je konfiguracija izmijenjena, postojeći servis je zamijenjen odgovarajućom gcloud naredbom, tako da bi Cloud Run aktivno pratio status kontejnera i ponovo ga pokrenuo ako provjera uživo ne uspije. Ova operacija je bila potrebna samo prvi put kada je novi servis implementiran s tom specifičnom slikom.
Na čistom Docker nivou, postoji dodatno ograničenje: sam Docker engine ne nudi automatsko ponovno pokretanje isključivo na osnovu HEALTHCHECK-a . Nadalje, proces sa PID-om 1 u kontejneru je posebno zaštićen i nije ga tako lako prekinuti iznutra. Stoga se u nekim okruženjima razmatra korištenje alata trećih strana kao što je docker-autoheal, koji prate zdravlje kontejnera i prisiljavaju ponovno pokretanje kada se otkriju problemi.
Što se tiče stabilnosti izvršavanja, tim je primijetio da se greške poput "RangeError: Maximum call stack size exceeded" često pojavljuju unutar Pyodide-a pri rukovanju posebno velikim opterećenjima. Ovo je bilo češće pri korištenju vrlo visokih dpi vrijednosti u generiranju PNG-a s matplotlib-om ili pri izvršavanju posebno složenih pandas operacija, što ukazuje na interna ograničenja u upravljanju stekom unutar WebAssembly okruženja.
Kritična ranjivost CVE-2026-5752 u Terrariumu
Vremenom je u Terrariumu otkrivena kritična ranjivost , identificirana kao CVE-2026-5752 i ocijenjena sa 9,3 na CVSS skali. Ovaj nivo ozbiljnosti ukazuje na manu sa potencijalno vrlo velikim uticajem na sigurnost sistema koji koriste ovaj sandbox.
Ranjivost omogućava napadaču da izvrši proizvoljno izvršavanje koda s root privilegijama u host procesu . Vektor napada se oslanja na prolazak kroz lanac zlonamjernih prototipova unutar Pyodide WebAssembly okruženja, efektivno zaobilazeći ograničenja sandboxa.
Najzabrinjavajući aspekt je to što iskorištavanje ove ranjivosti ne zahtijeva posebne privilegije ili dodatnu interakciju korisnika . Napadač koji može ubrizgati kod u sandbox (na primjer, iskorištavanjem funkcionalnosti izvršavanja koda u alatu koji koristi Terrarium) može iskoristiti ovu manu kako bi pobjegao iz kontroliranog okruženja.
Nakon što se iskoristi, ranjivost bi mogla omogućiti neovlašteni pristup osjetljivim sistemskim datotekama , kao što su /etc/passwd ili drugi interni resursi kontejnera , pa čak i omogućiti eskalaciju na host ili druge servise koji dijele istu infrastrukturu, ovisno o ukupnoj sigurnosnoj konfiguraciji.
Ova situacija predstavlja značajan rizik za sve organizacije koje koriste Terrarium kao okruženje za izvršavanje korisničkog koda ili AI modela . To nije samo teorijska ranjivost, već scenario u kojem bi kršenje sandboxa moglo dovesti do izlaganja podataka, kompromitovanja internih usluga i lateralnog kretanja unutar mreže.
Uticaj na preduzeća, programere i krajnje korisnike
Otkriće ove ranjivosti direktno utiče na bilo koju kompaniju ili programera koji je integrisao Terrarium u svoju infrastrukturu kako bi pokretao nepouzdani Python kod . Alati za kolaborativni razvoj, platforme za učenje, usluge analitike na zahtjev ili proizvodi za pomoć pri kodiranju zasnovani na vještačkoj inteligenciji mogli bi biti izloženi ako koriste Terrarium kao svoj sloj za izvršavanje.
Sa stanovišta krajnjeg korisnika, rizik nije samo da infrastruktura pružatelja usluga može biti kompromitovana, već i da lični ili profesionalni podaci pohranjeni na tim platformama mogu procuriti ili biti manipulirani bez prethodne najave ako napadač uspije iskoristiti ranjivost.
Situaciju dodatno komplikuje činjenica da se Terrarium više aktivno ne održava . To znači da se ne očekuje zvanična zakrpa za rješavanje problema, ostavljajući organizacije koje se i dalje oslanjaju na ovo rješenje sa poznatom ranjivošću i bez podrške.
U ovom kontekstu, nastavak korištenja Terrariuma bez dodatnih mjera predstavlja značajan sigurnosni rizik . Napadači koji su svjesni vektora iskorištavanja mogu ciljano ciljati servise koji nastavljaju koristiti ovu tehnologiju, tražeći slabosti u ukupnoj sigurnosti sistema.
Nadalje, u okruženjima gdje više servisa dijeli istu internu mrežu ili čak isti klaster kontejnera, curenje iz Terrariuma moglo bi otvoriti vrata lateralnom kretanju u druge naizgled izolirane sisteme , pojačavajući potencijalni utjecaj uspješnog napada.
Strategije ublažavanja i alternative koje treba razmotriti
S obzirom na ranjivost ovog obima i nedostatak aktivnog održavanja, prva preporuka za organizacije je da hitno procijene svoju trenutnu upotrebu Terrariuma . Ako se koristi za pokretanje koda treće strane ili koda generiranog AI modelima, izloženost je veća i zahtijeva hitnu akciju.
Kratkoročne mjere uključuju privremeno onemogućavanje funkcija koje omogućavaju izvršavanje proizvoljnog koda u produkciji dok se ne procijeni sigurnija alternativa. Druge opcije uključuju jačanje mrežnih politika, daljnju segmentaciju servisa koji koriste Terrarium i ograničavanje pristupa kontejneru s drugih sistema.
Srednjoročno gledano, možda bi bilo razumnije preći na druga sandbox ili izolirana rješenja za izvršavanje koja imaju aktivno održavanje i zajednicu ili dobavljača iza sebe za ispravljanje ranjivosti. To bi moglo uključivati upravljane usluge, serverless okruženja za izvršavanje sa jačim ograničenjima ili arhitekture mikroservisa posebno dizajnirane sa sigurnošću po defaultu.
U svakom slučaju, ovaj incident naglašava važnost integracije dobrih sigurnosnih praksi u životni ciklus razvoja : redovne revizije zavisnosti, pregled komponenti trećih strana koje se koriste u arhitekturi, praćenje relevantnih CVE-ova i planovi brzog odgovora kada se otkrije kritičan kvar.
Kompanije koje grade alate zasnovane na vještačkoj inteligenciji koji omogućavaju krajnjim korisnicima pokretanje ili generisanje koda trebale bi pažljivo analizirati dizajn svojih sandbox okruženja , osigurati da se procesi izolacije ažuriraju i izbjegavati oslanjanje na napuštene projekte za osjetljive funkcije poput pokretanja nepouzdanog koda.
Sve u vezi s Terrariumom odražava stepen do kojeg izvršavanje korisničkog koda i LLM modela zahtijeva ekstremni sigurnosni pristup . Visokoperformansni, jeftini sandbox može izgledati vrlo privlačno, ali ako se pojavi kritična ranjivost bez ikakve zakrpe na vidiku, ravnoteža se narušava i rizik postaje neprihvatljiv za mnoge ozbiljne slučajeve upotrebe.
