Sandbox v Cohere AI Terrarium: Fungování, rizika a kritické zranitelnosti

Informatec Digital » Zdroje » Sandbox v Cohere AI Terrarium: Fungování, rizika a kritické zranitelnosti

Když mluvíme o spouštění nedůvěryhodného nebo umělou inteligencí generovaného kódu v Pythonu , jednou z největších výzev je, jak to udělat bezpečně , rychle a bez zbytečných nákladů na infrastrukturu. Právě v této souvislosti se objevilo Terrarium, řešení od společnosti Cohere AI navržené jako sandbox pro hostování a spouštění tohoto typu kódu v kontejnerech nasazených v cloudu, zejména na Google Cloud Run.

Tento přístup umožnil vývojářům a společnostem využít Terrarium jako izolované prostředí pro nasazení uživatelského kódu nebo modelů LLM za rozumnou cenu a s poměrně dobrým výkonem. Postupem času se však objevily i velmi závažné zranitelnosti , včetně jedné s identifikátorem CVE, která odhaluje kritické nedostatky v zabezpečení sandboxu a dostala Terrarium do centra pozornosti.

Co je terárium a k čemu je určeno?

Terrarium je v podstatě izolované běhové prostředí pro Python , navržené tak, aby fungovalo jako nasaditelný kontejner Dockeru , například na Google Cloud Run. Jeho hlavním účelem je poskytnout sandbox, kde lze nasadit potenciálně nebezpečný nebo neznámý kód (například skripty odeslané uživatelem nebo úryvky generované jazykem), aniž by to přímo ohrozilo hlavní infrastrukturu.

Filozofie projektu se zaměřuje na poskytování cenově dostupné služby s nízkou latencí, kterou lze snadno integrovat do stávajících pracovních postupů. Terrarium bylo navrženo tak, aby bylo voláno prostřednictvím HTTP požadavků, odesílalo kód Pythonu ke spuštění – a volitelně vstupní soubory – a přijímalo zpět výsledky spuštění spolu s vygenerovanými soubory.

V praxi to znamená, že externí systém, API nebo dokonce interní nástroj může delegovat provádění kódu Pythonu na Terrarium a udržet tento kód v relativně omezeném prostředí s jasnými pravidly pro zdroje, dobu provádění a povolené funkce.

Jedním z klíčových designových rysů Terraria je jeho závislost na Pyodide, což je sestavení CPythonu na WebAssembly spouštěné v procesu Node.js. Tento přístup znamená, že kód Pythonu neběží nativně na hostitelském systému, ale v zapouzdřeném interpretu, což teoreticky posiluje jeho izolaci.

Výkon, náklady a hlavní vlastnosti sandboxu

Jedním z nejsilnějších prodejních argumentů Terraria byla kombinace nízkých provozních nákladů a přijatelného výkonu . V reálných nasazeních na Google Cloud Run s typickou konfigurací 2 GB paměti, 1 vCPU a alespoň jednou instancí s automatickým škálováním na vyžádání se hlášené měsíční náklady během fází interních anotací pohybovaly kolem 30 dolarů.

Co se týče rychlosti, popsané testy ukazují, že Terrarium dokázalo vygenerovat například obrázek PNG s rozlišením 200 dpi z jednoduchého grafu z matplotlib za běhu přibližně 900 ms nebo verzi ve formátu SVG za přibližně 500 ms. Tyto časy se vztahují ke kódu hostovanému na Cloud Run, včetně typického cyklu volání služby.

Kromě výkonu se Terrarium pyšnilo úplnou kompartmentalizací mezi voláními . Po každém volání byl sandbox kompletně recyklován: virtuální souborový systém Pyodide, globální proměnné, načtené knihovny a jakýkoli interní stav byly zahozeny. Cílem bylo zabránit tomu, aby jakékoli volání zdědilo data nebo kontext z předchozího spuštění, a tím se snížilo riziko úniku informací.

Dalším důležitým bodem je, že ačkoliv cílem byla robustní izolace, Cohere jasně uvedl, že nenabízí absolutní záruky ohledně integrity sandboxu . To již naznačovalo, že i přes vrstvy ochrany existuje možnost odhalení slabin, zejména v tak komplexním prostředí, jako je WebAssembly a jeho integrace s Node.js.

Terrarium bylo navrženo tak, aby bylo snadné ho využívat z jiných služeb: stačí odeslat HTTP požadavek na koncový bod nasazený na Cloud Run spolu s kódem, který se má spustit, a autorizačním tokenem (pokud to konfigurace vyžaduje). Na oplátku obdržíte soubor JSON s výsledky a případně vygenerovanými soubory kódovanými v base64.

Podpora spouštění souborů a knihoven v Pyodide

Jednou z atraktivních vlastností Terraria byla jeho schopnost nativní práce se vstupními a výstupními soubory . API umožňovalo připojit k Python kódu v požadavku více souborů libovolného typu; ty byly umístěny do virtuálního souborového systému, který Pyodide zpřístupňuje interpretu Pythonu.

Během provádění mohl kód v Pythonu tyto soubory číst a manipulovat s nimi, jako by se nacházely lokálně v sandboxu. Po dokončení provádění Terrarium shromáždilo všechny vytvořené nebo upravené soubory a vrátilo je klientovi v odpovědi, obvykle zakódované pro bezproblémový přenos přes HTTP.

Pokud jde o ekosystém knihoven, jelikož je založen na Pyodide, Terrarium zdědilo poměrně rozsáhlou sadu vědeckých a datově-analytických balíčků . Mezi přímo podporované balíčky patří: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy a sqlite3 (druhý jmenovaný není ve výchozím nastavení povolen, ale s možností jeho načtení v případě potřeby).

V konkrétním případě matplotlib existovala určitá omezení: plt.show() nebyl v tomto prostředí podporován, ale použití plt.savefig() pro generování obrázků fungovalo správně, pokud nebyly vynuceny nadměrné parametry, například extrémně vysoké rozlišení, které by zvýšilo využití zdrojů.

Díky této sadě knihoven bylo Terrarium obzvláště užitečné pro úkoly, jako je analýza dat, vizualizace, prototypování modelů strojového učení a manipulace se strukturovanými informacemi, to vše prováděné v teoreticky řízeném sandboxu.

Vnitřní architektura: vrstvy izolace a nasazení

Architektura Terraria je postavena v několika vrstvách, které jsou navrženy tak, aby se minimalizovala plocha pro útok a co nejvíce se izoloval nedůvěryhodný kód . První vrstvou je samotný proces Node.js, který funguje jako hostitel a načítá Pyodide, tedy CPython zkompilovaný do WebAssembly.

Kód Pythonu odeslaný uživatelem je analyzován, kompilován a spuštěn v prostředí WebAssembly , nikoli nativně na hostitelském systému. Tento přístup ze své podstaty omezuje možnosti kódu, protože Pyodide používá virtuální souborový systém v paměti, postrádá přímý přístup k hostitelskému disku a nemá žádné tradiční možnosti zpracování na pozadí.

Mezi nejvýznamnější omezení patří: žádný přístup ke skutečnému souborovému systému (pouze interní virtuální souborový systém Pyodide), úplná absence vláken a multiprocessingu, nemožnost spouštět podprocesy, žádný přístup k paměti hostitele, na kterém běží Node.js, žádné sdílení stavu mezi voláními (protože celé prostředí je restartováno) a ze své podstaty žádný přístup k síti nebo internetu . Toto poslední omezení bylo zamýšleno jako konstrukční rozhodnutí, které by mohlo být v budoucnu revidováno, ale zpočátku přidalo další vrstvu sváru.

Druhou vrstvou izolace je samotné nasazení v cloudu: proces Node.js běží uvnitř kontejneru Docker , který je nasazen na Google Cloud Run. To nejen omezuje běhovou dobu a dostupné zdroje, ale také odděluje kontejner, na kterém běží kód, od jakékoli jiné části infrastruktury organizace v případě hypotetického narušení sandboxu.

Stručně řečeno, původní návrh Terraria se spoléhá na kombinaci WebAssembly, Dockeru a Cloud Run , aby vytvořil relativně bezpečné prostředí pro spuštění Pythonu, s postupnými bariérami, které komplikují únik z sandboxu do hostitelského systému a interní sítě.

Lokální nasazení, nasazení Dockeru a nasazení Google Cloud Run

Pro použití Terraria ve vývojovém prostředí bylo nutné mít na počítači nainstalovaný Node.js. Jakmile byl tento požadavek splněn, obvyklý postup spočíval v instalaci závislostí projektu a spuštění lokálního serveru spolu s funkcí, která zpracovává požadavky na spuštění kódu.

S běžícím serverem bylo možné lokálnímu koncovému bodu zasílat požadavky na odeslání testovacích souborů a skriptů Pythonu , což vývojářům umožňovalo ověřit chování sandboxu před nasazením do produkčního prostředí. K dispozici byly skripty pro spuštění sady testů na všech souborech .py v testovacím adresáři, což zjednodušilo ověřování prostředí.

V kontejnerových prostředích bylo možné Terrarium sestavit jako obraz Dockeru a spustit jako samostatný kontejner . Typické instrukce zahrnovaly kroky sestavení, spuštění a zastavení, stejně jako příkazy pro nalezení identifikátoru spuštěného kontejneru a jeho ruční správu v případě potřeby.

Když Terrarium migrovalo do Google Cloud Run, bylo nasazeno jako automaticky škálovatelná HTTP služba s konfigurovatelnými parametry zdrojů a souběžnosti. Bylo vhodné upravit tyto hodnoty tak, aby se vyvážil výkon, náklady a zabezpečení . Například pro intenzivní úlohy bylo možné alokovat více CPU a paměti a omezit souběžnost na instanci, aby se zabránilo blokování.

Je důležité si uvědomit, že Pyodide, když je nakonfigurován pro Terrarium, běží v hlavním procesu Node.js. To znamená, že pokud se váš kód v Pythonu stane obzvláště náročným na zdroje nebo vstoupí do složitých smyček, může to zablokovat schopnost Node.js reagovat na jiné požadavky. Pyodide doporučuje používat Workery pro scénáře, kde je nutné přerušit nebo dále izolovat provádění, ale tento přístup komplikuje integraci a v některých případech omezuje podporu knihoven, jako je matplotlib.

Problémy s řízením a stabilitou zdravotnických služeb

V nasazeních na Google Cloud Run bylo jednou z praktických výzev monitorování stavu služby a zotavení po haváriích . Cloud Run ve výchozím nastavení přímo nepodporuje kontroly stavu definované v Dockerfiles pomocí HEALTHCHECK, takže bylo nutné provést drobnou dodatečnou úpravu.

Obvyklý postup zahrnoval popis služby Cloud Run pomocí příkazu gcloud a export konfigurace do souboru service.yaml. V rámci tohoto souboru YAML byla přidána konfigurace livenessProbe, která byla přidružena k obrazu kontejneru, aby Cloud Run mohl detekovat, kdy služba přestala správně reagovat.

Po úpravě konfigurace byla stávající služba nahrazena příslušným příkazem gcloud, aby Cloud Run aktivně monitoroval stav kontejneru a restartoval jej, pokud by selhala živá kontrola. Tato operace byla nutná pouze při prvním nasazení nové služby s daným obrazem.

Na čisté úrovni Dockeru existuje další omezení: samotný Docker engine nenabízí automatické restarty založené výhradně na HEALTHCHECK . Proces s PID 1 v kontejneru je navíc obzvláště chráněn a není tak snadné jej zevnitř ukončit. Proto se v některých prostředích zvažuje použití nástrojů třetích stran, jako je docker-autoheal, které monitorují stav kontejneru a vynutí restart, když jsou zjištěny problémy.

Pokud jde o stabilitu provádění, tým pozoroval, že chyby jako „RangeError: Maximum call stack size exceeded“ se v Pyodide často vyskytovaly při zpracování obzvláště velkých úloh. To se častěji vyskytovalo při použití velmi vysokých hodnot dpi při generování PNG pomocí matplotlib nebo při provádění obzvláště složitých operací PANDA, což naznačuje vnitřní omezení ve správě zásobníku v prostředí WebAssembly.

Kritická zranitelnost CVE-2026-5752 v Terrarium

V průběhu času byla v Terrarium objevena kritická zranitelnost , identifikovaná jako CVE-2026-5752 a ohodnocená na stupnici CVSS stupněm 9,3. Tato úroveň závažnosti naznačuje chybu s potenciálně velmi vysokým dopadem na bezpečnost systémů používajících tento sandbox.

Tato zranitelnost umožňuje útočníkovi spustit libovolný kód s oprávněními root v hostitelském procesu . Vektor útoku se spoléhá na procházení řetězce prototypů škodlivým kódem v prostředí Pyodide WebAssembly, čímž efektivně obchází omezení sandboxu.

Nejznepokojivějším aspektem je, že zneužití této zranitelnosti nevyžaduje žádná zvláštní oprávnění ani další interakci s uživatelem . Útočník, který může vložit kód do sandboxu (například zneužitím funkce spouštění kódu v nástroji, který používá Terrarium), může tuto chybu využít k úniku z kontrolovaného prostředí.

Jakmile je tato zranitelnost zneužita, může umožnit neoprávněný přístup k citlivým systémovým souborům , jako je /etc/passwd nebo jiné interní kontejnerové prostředky , a dokonce umožnit eskalaci na hostitele nebo jiné služby, které sdílejí stejnou infrastrukturu, v závislosti na celkové konfiguraci zabezpečení.

Tato situace představuje významné riziko pro všechny organizace, které používají Terrarium jako prostředí pro spouštění uživatelského kódu nebo modelů umělé inteligence . Nejde jen o teoretickou zranitelnost, ale o scénář, kdy by narušení sandboxu mohlo vést k úniku dat, ohrožení interních služeb a laterálnímu pohybu v rámci sítě.

Dopad na firmy, vývojáře a koncové uživatele

Objev této zranitelnosti přímo ovlivňuje jakoukoli společnost nebo vývojáře, kteří integrovali Terrarium do své infrastruktury za účelem spouštění nedůvěryhodného kódu Pythonu . Nástroje pro kolaborativní vývoj, vzdělávací platformy, analytické služby na vyžádání nebo produkty pro pomoc s kódem založené na umělé inteligenci by mohly být odhaleny, pokud používají Terrarium jako svou běhovou vrstvu.

Z pohledu koncového uživatele nehrozí pouze ohrožení infrastruktury poskytovatele služeb, ale také únik nebo manipulace osobních nebo profesních informací uložených na těchto platformách bez předchozího upozornění, pokud se útočníkovi podaří zneužít tuto zranitelnost.

Situaci dále komplikuje skutečnost, že Terrarium již není aktivně udržováno . To znamená, že se neočekává oficiální záplata, která by problém vyřešila, takže organizace, které se na toto řešení nadále spoléhají, čelí známé zranitelnosti a nemají žádnou podporu.

V této souvislosti představuje pokračování v používání Terraria bez dalších opatření značné bezpečnostní riziko . Útočníci, kteří si jsou vědomi vektoru zneužití, se mohou cíleně zaměřit na služby, které tuto technologii nadále používají, a hledat slabiny v celkové bezpečnosti systému.

Navíc v prostředích, kde více služeb sdílí stejnou interní síť nebo dokonce stejný kontejnerový cluster, by únik z Terraria mohl otevřít dveře k bočnímu pohybu do dalších zdánlivě izolovaných systémů , což by zesílilo potenciální dopad úspěšného útoku.

Strategie zmírňování dopadů a alternativy, které je třeba zvážit

Vzhledem k zranitelnosti tohoto rozsahu a nedostatku aktivní údržby je prvním doporučením pro organizace, aby naléhavě posoudily své současné používání platformy Terrarium . Pokud je používána ke spouštění kódu třetích stran nebo kódu generovaného modely umělé inteligence, je expozice větší a vyžaduje okamžitý zásah.

Krátkodobá opatření zahrnují dočasné zakázání funkcí, které umožňují spuštění libovolného kódu v produkčním prostředí, zatímco se vyhodnocuje bezpečnější alternativa. Mezi další možnosti patří posílení síťových zásad, další segmentace služeb, které používají Terrarium, a omezení přístupu ke kontejneru z jiných systémů.

Ve střednědobém horizontu může být rozumnější migrovat na jiná sandboxová nebo izolovaná řešení pro spouštění , která mají aktivní údržbu a za nimi stojí komunita nebo poskytovatel, kteří opravují zranitelnosti. To by mohlo zahrnovat spravované služby, bezserverová prostředí pro spouštění s přísnějšími omezeními nebo architektury mikroslužeb speciálně navržené s výchozím zabezpečením.

V každém případě tento incident zdůrazňuje důležitost integrace osvědčených bezpečnostních postupů do životního cyklu vývoje : pravidelné audity závislostí, kontrola komponent třetích stran používaných v architektuře, monitorování relevantních CVE a plány rychlé reakce v případě zjištění kritického selhání.

Společnosti, které vytvářejí nástroje založené na umělé inteligenci, jež koncovým uživatelům umožňují spouštět nebo generovat kód, by měly pečlivě analyzovat návrh svých sandboxů , zajistit, aby izolační procesy byly aktuální, a vyhnout se spoléhání se na opuštěné projekty pro takové citlivé funkce, jako je spouštění nedůvěryhodného kódu.

Všechno na Terrarium odráží míru, do jaké běh uživatelského kódu a modelů LLM vyžaduje extrémní bezpečnostní přístup . Vysoce výkonný a levný sandbox se může zdát velmi atraktivní, ale pokud se objeví kritická zranitelnost bez možnosti záplaty, rovnováha se naruší a riziko se stává pro mnoho seriózních případů použití nepřijatelným.