Sandkasse i Cohere AI Terrarium: Funksjon, risikoer og kritiske sårbarheter

Informatec Digital » Ressurser » Sandkasse i Cohere AI Terrarium: Funksjon, risikoer og kritiske sårbarheter

Når vi snakker om å kjøre upålitelig eller AI-generert Python-kode , er en av de største utfordringene hvordan man gjør det sikkert , raskt og uten å tømme budsjettet på infrastruktur. Det var i denne sammenhengen at Terrarium dukket opp, en løsning fra Cohere AI designet som en sandkasse for å hoste og kjøre denne typen kode i containere distribuert i skyen, spesielt på Google Cloud Run.

Denne tilnærmingen tillot utviklere og selskaper å utnytte Terrarium som et isolert miljø for å distribuere brukerkode eller LLM-modeller til en rimelig kostnad og med rimelig god ytelse. Over tid har imidlertid også svært alvorlige sårbarheter dukket opp , inkludert en med en CVE-identifikator som avslører kritiske feil i sandkassens sikkerhet og har satt Terrarium i søkelyset.

Hva er et terrarium, og hva ble det laget for?

Terrarium er i hovedsak et isolert kjøretidsmiljø for Python , designet for å fungere som en utplasserbar Docker-container , for eksempel på Google Cloud Run. Hovedformålet er å tilby en sandkasse der potensielt farlig eller ukjent kode (som brukerinnleverte skript eller språkgenererte kodesnutter) kan distribueres uten å sette hovedinfrastrukturen direkte i fare.

Filosofien bak prosjektet fokuserer på å tilby en rimelig tjeneste med lav latens som er enkel å integrere i eksisterende arbeidsflyter. Terrarium ble designet for å bli kalt via HTTP-forespørsler, sende Python-koden som skal kjøres – og eventuelt inndatafiler – og motta tilbake kjøreresultatene sammen med de genererte filene.

I praksis betyr dette at et eksternt system, et API eller til og med et internt verktøy kan delegere kjøringen av Python-kode til Terrarium , og holde den koden innenfor et relativt begrenset miljø, med klare regler for ressurser, kjøringstid og tillatte funksjoner.

En av de viktigste designfunksjonene til Terrarium er avhengigheten av Pyodide, en CPython til WebAssembly-bygging utført i en Node.js-prosess. Denne tilnærmingen betyr at Python-koden ikke kjører naturlig på vertssystemet, men snarere i en innkapslet tolk, noe som teoretisk sett styrker isolasjonen.

Ytelse, kostnader og hovedfunksjoner i sandkassen

Et av Terrariums sterkeste salgsargumenter var kombinasjonen av lave driftskostnader og akseptabel ytelse . I reelle distribusjoner på Google Cloud Run, med en typisk konfigurasjon på 2 GB minne, 1 vCPU og minst én alltid-på-instans med autoskalering på forespørsel, var den rapporterte månedlige kostnaden rundt $30 i interne annoteringsfaser.

Når det gjelder hastighet, viser testene som er beskrevet at Terrarium for eksempel kan generere et 200 dpi PNG-bilde av et enkelt matplotlib-plott på rundt 900 ms kjøretid, eller en SVG-versjon på omtrent 500 ms. Disse tidene refererer til kode som ligger på Cloud Run, inkludert tjenestens typiske aktiveringssyklus.

I tillegg til ytelse, kunne Terrarium skryte av fullstendig oppdeling mellom kall . Etter hvert kall ble sandkassen fullstendig resirkulert: Pyodides virtuelle filsystem, globale variabler, lastede biblioteker og eventuell intern tilstand ble forkastet. Målet var å forhindre at kall arvet data eller kontekst fra en tidligere utførelse, og dermed redusere risikoen for informasjonslekkasjer.

Et annet viktig poeng er at selv om målet var en robust isolasjon, gjorde Cohere det klart at de ikke ga absolutte garantier for sandkassens integritet . Dette antydet allerede at til tross for beskyttelseslagene var det en mulighet for at svakheter kunne oppdages, spesielt i et så komplekst miljø som WebAssembly og integrasjonen med Node.js.

Terrarium ble designet for å være enkelt å bruke fra andre tjenester: Bare send en HTTP-forespørsel til endepunktet som er distribuert på Cloud Run, sammen med koden som skal kjøres og et autorisasjonstoken (hvis konfigurasjonen krever det). Til gjengjeld mottar du en JSON-fil med resultatene og, hvis aktuelt, de genererte filene kodet i base64.

Filutførelse og bibliotekstøtte i Pyodide

En av Terrariums attraktive funksjoner var muligheten til å jobbe med input- og output-filer direkte . API-et tillot at flere filer av alle typer ble lagt ved sammen med Python-koden i forespørselen; disse ble plassert i det virtuelle filsystemet som Pyodide eksponerer for Python-tolkeren.

Under kjøringen kunne Python-koden lese og manipulere disse filene som om de var lokale i sandkassen. Når kjøringen var fullført, ville Terrarium samle inn alle de opprettede eller modifiserte filene og returnere dem som svar til klienten, vanligvis kodet for sømløs overføring over HTTP.

Når det gjelder bibliotekøkosystemet, arvet Terrarium, som er basert på Pyodide, et ganske omfattende sett med vitenskapelige pakker og dataanalysepakker . Direkte støttede pakker inkluderer: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy og sqlite3 (sistnevnte er ikke aktivert som standard, men med mulighet for å laste den inn om nødvendig).

I det spesifikke tilfellet med matplotlib var det noen begrensninger: plt.show() ble ikke støttet i dette miljøet, men bruken av plt.savefig() for å generere bilder fungerte riktig, så lenge for mange parametere ikke ble tvunget frem, for eksempel ekstremt høye oppløsninger som ville øke ressursbruken.

Dette settet med biblioteker gjorde Terrarium spesielt nyttig for oppgaver som dataanalyse, visualisering, prototyping av maskinlæringsmodeller og manipulering av strukturert informasjon, alt utført i en teoretisk kontrollert sandkasse.

Intern arkitektur: lag med isolasjon og distribusjon

Terrariums arkitektur er bygget i flere lag, designet for å redusere angrepsflaten og isolere upålitelig kode så mye som mulig . Det første laget er selve Node.js-prosessen, som fungerer som vert og laster Pyodide, det vil si CPython kompilert til WebAssembly.

Python-koden som sendes inn av brukeren blir analysert, kompilert og utført i WebAssembly-miljøet , ikke direkte på vertssystemet. Denne tilnærmingen begrenser iboende hva koden kan gjøre, siden Pyodide bruker et virtuelt filsystem i minnet, mangler direkte tilgang til vertsdisken og ikke har tradisjonelle bakgrunnsbehandlingsmuligheter.

Blant de mest relevante begrensningene er: ingen tilgang til det virkelige filsystemet (kun Pyodides interne virtuelle filsystem), fullstendig fravær av tråding og flerprosessering, manglende evne til å starte delprosesser, ingen tilgang til minnet til verten som kjører Node.js, ingen deling av tilstand mellom kall (siden hele miljøet startes på nytt), og, per design, ingen tilgang til nettverket eller internett . Denne siste begrensningen var ment som en designbeslutning som kunne revideres i fremtiden, men la i utgangspunktet til et nytt lag med strid.

Det andre isolasjonslaget er selve skydistribusjonen: Node.js-prosessen kjører inne i en Docker-container , som er distribuert på Google Cloud Run. Dette begrenser ikke bare kjøretid og tilgjengelige ressurser, men kobler også containeren som kjører koden fra enhver annen del av organisasjonens infrastruktur i tilfelle et hypotetisk sandkassebrudd.

Oppsummert er Terrariums originale design avhengig av en kombinasjon av WebAssembly, Docker og Cloud Run for å bygge et relativt sikkert miljø for Python-kjøring, med påfølgende barrierer som kompliserer evakuering fra sandkassen til vertssystemet og det interne nettverket.

Lokal distribusjon, Docker-distribusjon og Google Cloud Run-distribusjon

For å bruke Terrarium i et utviklingsmiljø, var det nødvendig å ha Node.js installert på maskinen . Når dette kravet var oppfylt, bestod den vanlige prosedyren av å installere prosjektavhengighetene og kjøre den lokale serveren, sammen med funksjonen som håndterer kodeutførelsesforespørsler.

Med serveren i gang kunne det sendes forespørsler til det lokale endepunktet om å sende testfiler og Python-skript , slik at utviklere kunne validere sandkassens oppførsel før de ble distribuert til produksjonsmiljøer. Skript var tilgjengelige for å kjøre en serie tester på alle .py-filer i en testkatalog, noe som forenklet miljøverifisering.

I containeriserte miljøer kunne Terrarium bygges som et Docker-image og kjøres som en frittstående container . Typiske instruksjoner inkluderte trinn for bygging, kjøring og stopp, samt kommandoer for å finne identifikatoren til den kjørende containeren og administrere den manuelt om nødvendig.

Da Terrarium migrerte til Google Cloud Run, ble det distribuert som en autoskalerende HTTP-tjeneste med konfigurerbare ressurs- og samtidighetsparametere. Det var lurt å justere disse verdiene for å balansere ytelse, kostnad og sikkerhet . For eksempel, for intensive arbeidsbelastninger, kunne mer CPU og minne allokeres, og samtidighet per instans kunne begrenses for å forhindre blokkering.

Det er viktig å merke seg at Pyodide, når den er konfigurert for Terrarium, kjører i hovedprosessen Node.js. Dette betyr at hvis Python-koden din blir spesielt ressurskrevende eller går inn i komplekse løkker, kan den blokkere Node.js' evne til å svare på andre forespørsler. Pyodide foreslår å bruke Workers for scenarier der det er nødvendig å avbryte eller ytterligere isolere kjøringer, men denne tilnærmingen kompliserer integrasjon og begrenser i noen tilfeller støtte for biblioteker som matplotlib.

Helsetjenestehåndtering og stabilitetsproblemer

I implementeringer på Google Cloud Run var en av de praktiske utfordringene å overvåke tjenestens tilstand og gjenoppretting etter krasj . Cloud Run støtter som standard ikke direkte helsekontroller definert i Dockerfiles ved hjelp av HEALTHCHECK, så en liten tilleggsjustering var nødvendig.

Den vanlige prosedyren involverte å beskrive Cloud Run-tjenesten med gcloud , og eksportere konfigurasjonen til en service.yaml-fil. Innenfor denne YAML-filen ble en livenessProbe-konfigurasjon lagt til, knyttet til containeravbildningen, slik at Cloud Run kunne oppdage når tjenesten sluttet å svare riktig.

Etter at konfigurasjonen var endret, ble den eksisterende tjenesten erstattet med den aktuelle gcloud-kommandoen, slik at Cloud Run aktivt overvåket containerens status og startet den på nytt hvis live-sjekken mislyktes. Denne operasjonen var bare nødvendig første gang en ny tjeneste ble distribuert med det spesifikke bildet.

På rent Docker-nivå finnes det en ytterligere begrensning: selve Docker-motoren tilbyr ikke automatiske omstarter basert utelukkende på HEALTHCHECK . Videre er prosessen med PID 1 i containeren spesielt beskyttet og ikke så enkel å avslutte innenfra. Derfor vurderes bruk av tredjepartsverktøy som docker-autoheal i noen miljøer, som overvåker containerens helse og tvinger frem omstarter når det oppdages problemer.

Når det gjelder utførelsesstabilitet, observerte teamet at feil som "RangeError: Maximum call stack size exceeded" ofte dukket opp i Pyodide ved håndtering av spesielt tunge arbeidsbelastninger. Dette var mer vanlig ved bruk av svært høye dpi-verdier i PNG-generering med matplotlib eller ved utførelse av spesielt komplekse pandas-operasjoner, noe som tyder på interne begrensninger i stakkhåndtering i WebAssembly-miljøet.

Kritisk sårbarhet CVE-2026-5752 i Terrarium

Over tid har det blitt oppdaget en kritisk sårbarhet i Terrarium , identifisert som CVE-2026-5752 og vurdert til 9,3 på CVSS-skalaen. Dette alvorlighetsnivået indikerer en feil med potensielt svært stor innvirkning på sikkerheten til systemer som bruker denne sandkassen.

Sårbarheten lar en angriper utføre vilkårlig kodekjøring med rotrettigheter i vertsprosessen . Angrepsvektoren er avhengig av ondsinnet prototypekjedetraversering i Pyodide WebAssembly-miljøet, og omgår effektivt sandkassebegrensninger.

Det mest bekymringsfulle aspektet er at utnyttelse av denne sårbarheten ikke krever spesielle rettigheter eller ytterligere brukerinteraksjon . En angriper som kan injisere kode i sandkassen (for eksempel ved å utnytte kodekjøringsfunksjonalitet i et verktøy som bruker Terrarium) kan utnytte denne feilen til å unnslippe det kontrollerte miljøet.

Når sårbarheten utnyttes, kan den tillate uautorisert tilgang til sensitive systemfiler , for eksempel /etc/passwd eller andre interne containerressurser , og til og med muliggjøre eskalering til verten eller andre tjenester som deler samme infrastruktur, avhengig av den generelle sikkerhetskonfigurasjonen.

Denne situasjonen utgjør en betydelig risiko for alle organisasjoner som bruker Terrarium som et brukerkode- eller AI-modellutførelsesmiljø . Det er ikke bare en teoretisk sårbarhet, men et scenario der et sandkassebrudd kan føre til dataeksponering, kompromittering av interne tjenester og sideveis bevegelse i nettverket.

Innvirkning på bedrifter, utviklere og sluttbrukere

Oppdagelsen av dette sikkerhetsproblemet påvirker direkte ethvert selskap eller enhver utvikler som har integrert Terrarium i infrastrukturen sin for å kjøre upålitelig Python-kode . Samarbeidsutviklingsverktøy, læringsplattformer, analysetjenester på forespørsel eller AI-baserte kodehjelpsprodukter kan bli eksponert hvis de bruker Terrarium som kjøretidslag.

Fra sluttbrukerens synspunkt er risikoen ikke bare at tjenesteleverandørens infrastruktur kan bli kompromittert, men også at personlig eller profesjonell informasjon som er lagret på disse plattformene kan lekkes eller manipuleres uten forvarsel hvis en angriper klarer å utnytte sårbarheten.

Situasjonen kompliseres ytterligere av at Terrarium ikke lenger aktivt vedlikeholdes . Dette betyr at det ikke forventes en offisiell oppdatering for å fikse problemet, noe som etterlater organisasjoner som fortsetter å stole på denne løsningen med en kjent sårbarhet og ingen støtte.

I denne sammenhengen utgjør det en betydelig sikkerhetsrisiko å fortsette å bruke Terrarium uten ytterligere tiltak . Angripere som er klar over angrepsvektoren kan spesifikt målrette tjenester som fortsetter å bruke denne teknologien, og se etter svakheter i systemets generelle sikkerhet.

Videre, i miljøer der flere tjenester deler det samme interne nettverket eller til og med den samme containerklyngen, kan en lekkasje fra Terrarium åpne døren for lateral bevegelse inn i andre tilsynelatende isolerte systemer , noe som forsterker den potensielle effekten av et vellykket angrep.

Avbøtende strategier og alternativer å vurdere

Gitt en sårbarhet av denne størrelsesordenen og mangelen på aktivt vedlikehold, er den første anbefalingen til organisasjoner å raskt vurdere sin nåværende bruk av Terrarium . Hvis det brukes til å kjøre tredjepartskode eller kode generert av AI-modeller, er eksponeringen større og krever umiddelbar handling.

Kortsiktige tiltak inkluderer midlertidig deaktivering av funksjoner som tillater kjøring av vilkårlig kode i produksjon mens et sikrere alternativ evalueres. Andre alternativer inkluderer styrking av nettverkspolicyer, ytterligere segmentering av tjenester som bruker Terrarium og begrensning av tilgang til containeren fra andre systemer.

På mellomlang sikt kan det være mer fornuftig å migrere til andre sandkasse- eller isolerte utførelsesløsninger som har aktivt vedlikehold og et fellesskap eller en leverandør bak seg for å rette opp sårbarheter. Dette kan innebære administrerte tjenester, serverløse utførelsesmiljøer med strengere restriksjoner eller mikrotjenestearkitekturer som er spesielt designet med sikkerhet som standard.

Uansett understreker denne hendelsen viktigheten av å integrere god sikkerhetspraksis i utviklingslivssyklusen : regelmessige avhengighetsrevisjoner, gjennomgang av tredjepartskomponenter som brukes i arkitekturen, overvåking av relevante CVE-er og raske responsplaner når en kritisk feil oppdages.

Selskaper som bygger AI-baserte verktøy som lar sluttbrukere kjøre eller generere kode, bør nøye analysere designet til sandkassene sine , sørge for at isolasjonsprosesser holdes oppdaterte og unngå å stole på forlatte prosjekter for så sensitive funksjoner som å kjøre upålitelig kode.

Alt ved Terrarium gjenspeiler i hvilken grad det å kjøre brukerkode og LLM-modeller krever en ekstrem sikkerhetstilnærming . En sandkasse med høy ytelse og lav kostnad kan virke veldig attraktiv, men hvis en kritisk sårbarhet dukker opp uten en oppdatering i sikte, forstyrres balansen og risikoen blir uakseptabel for mange alvorlige brukstilfeller.