- Terrarium — це пісочниця Python, заснована на Pyodide та розгортається в Cloud Run, розроблена для запуску ненадійного коду з низькою вартістю та прийнятною затримкою.
- Середовище пропонує компартменталізацію на основі викликів, підтримку кількох наукових бібліотек та обробку вхідних і вихідних файлів через віртуальну файлову систему.
- Його архітектура поєднує WebAssembly, Node.js, Docker та Cloud Run для ізоляції коду, але були виявлені проблеми зі стабільністю та управлінням справністю сервісів.
- Критична вразливість CVE-2026-5752 дозволяє виконання коду з правами root, без запланованого оновлення, тому рекомендується оцінити засоби пом'якшення та альтернативи.
Коли ми говоримо про запуск ненадійного або згенерованого штучним інтелектом коду Python , однією з найбільших проблем є те, як зробити це безпечно , швидко та без великих витрат на інфраструктуру. Саме в цьому контексті з'явився Terrarium, рішення від Cohere AI, розроблене як пісочниця для розміщення та запуску такого типу коду в контейнерах, розгорнутих у хмарі, особливо в Google Cloud Run.
Такий підхід дозволив розробникам і компаніям використовувати Terrarium як ізольоване середовище для розгортання користувацького коду або моделей LLM за розумною ціною та з досить хорошою продуктивністю. Однак з часом також виявилися дуже серйозні вразливості , зокрема одна з ідентифікатором CVE, яка виявляє критичні недоліки в безпеці пісочниці та поставила Terrarium у центр уваги.
Що таке тераріум і для чого він призначений?
Terrarium — це, по суті, ізольоване середовище виконання для Python , розроблене для функціонування як розгортаний контейнер Docker , наприклад, на Google Cloud Run. Його головне призначення — забезпечити пісочницю, де можна розгортати потенційно небезпечний або невідомий код (наприклад, скрипти, надіслані користувачем, або фрагменти коду, згенеровані мовою програмування), не наражаючи безпосередньо на ризик основну інфраструктуру.
Філософія проєкту зосереджена на наданні доступного сервісу з низькою затримкою, який легко інтегрувати в існуючі робочі процеси. Terrarium був розроблений для виклику через HTTP-запити, надсилання коду Python для виконання — і, за бажанням, вхідних файлів — та отримання результатів виконання разом зі згенерованими файлами.
На практиці це означає, що зовнішня система, API або навіть внутрішній інструмент можуть делегувати виконання коду Python Terrarium , зберігаючи цей код у відносно обмеженому середовищі з чіткими правилами щодо ресурсів, часу виконання та дозволених можливостей.
Однією з ключових особливостей дизайну Terrarium є його залежність від Pyodide, збірки CPython для WebAssembly, що виконується в процесі Node.js. Такий підхід означає, що код Python не працює безпосередньо на хост-системі, а в інкапсульованому інтерпретаторі, що теоретично посилює його ізоляцію.
Продуктивність, вартість та основні характеристики пісочниці
Однією з найсильніших переваг Terrarium було поєднання низьких експлуатаційних витрат і прийнятної продуктивності . У реальних розгортаннях на Google Cloud Run, з типовою конфігурацією 2 ГБ пам'яті, 1 віртуальним процесором і принаймні одним постійно увімкненим екземпляром з автоматичним масштабуванням на вимогу, заявлена щомісячна вартість становила близько 30 доларів США під час фаз внутрішнього анотування.
Що стосується швидкості, описані тести показують, що Terrarium може генерувати, наприклад, зображення PNG з роздільною здатністю 200 dpi простого графіка matplotlib приблизно за 900 мс під час виконання або версію SVG приблизно за 500 мс. Цей час стосується коду, розміщеного на Cloud Run, включаючи типовий цикл виклику сервісу.
Окрім продуктивності, Terrarium міг похвалитися повним розділенням викликів . Після кожного виклику пісочниця повністю перероблялася: віртуальна файлова система Pyodide, глобальні змінні, завантажені бібліотеки та будь-який внутрішній стан відкидалися. Метою було запобігти успадкуванню будь-яким викликом даних або контексту від попереднього виконання, тим самим зменшуючи ризик витоку інформації.
Ще один важливий момент полягає в тому, що, хоча метою була надійна ізоляція, Cohere чітко дав зрозуміти, що не пропонує абсолютних гарантій щодо цілісності пісочниці . Це вже натякало на те, що, незважаючи на рівні захисту, існує ймовірність виявлення слабких місць, особливо в такому складному середовищі, як WebAssembly та його інтеграція з Node.js.
Terrarium було розроблено для зручного використання з інших сервісів: просто надішліть HTTP-запит до кінцевої точки, розгорнутої на Cloud Run, разом із кодом для виконання та токеном авторизації (якщо це потрібно конфігурацією). У відповідь ви отримаєте JSON-файл з результатами та, якщо потрібно, згенерованими файлами, закодованими в base64.
Виконання файлів та підтримка бібліотек у Pyodide
Однією з привабливих особливостей Terrarium була його здатність працювати з вхідними та вихідними файлами безпосередньо в додатку . API дозволяв додавати кілька файлів будь-якого типу разом із кодом Python у запиті; вони розміщувалися у віртуальній файловій системі, яку Pyodide надає інтерпретатору Python.
Під час виконання код Python міг зчитувати та маніпулювати цими файлами так, ніби вони були локальними в межах пісочниці. Після завершення виконання Terrarium збирав усі створені або змінені файли та повертав їх у відповіді клієнту, зазвичай закодовані для безперебійної передачі через HTTP.
Щодо екосистеми бібліотеки, будучи заснованим на Pyodide, Terrarium успадкував досить великий набір наукових пакетів та пакетів для аналізу даних . Безпосередньо підтримувані пакети включають: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy та sqlite3 (останній не ввімкнено за замовчуванням, але з можливістю його завантаження за потреби).
У конкретному випадку matplotlib існували деякі обмеження: plt.show() не підтримувався в цьому середовищі, але використання plt.savefig() для створення зображень працювало правильно, якщо не було примусово встановлених надмірних параметрів, таких як надзвичайно висока роздільна здатність, яка б збільшувала використання ресурсів.
Цей набір бібліотек зробив Terrarium особливо корисним для таких завдань, як аналіз даних, візуалізація, створення прототипів моделей машинного навчання та маніпулювання структурованою інформацією, все це виконується в теоретично контрольованій пісочниці.
Внутрішня архітектура: рівні ізоляції та розгортання
Архітектура Terrarium побудована з кількох шарів, розроблених для зменшення поверхні атаки та максимальної ізоляції ненадійного коду . Перший шар – це сам процес Node.js, який виступає в ролі хоста та завантажує Pyodide, тобто CPython, скомпільований у WebAssembly.
Код Python, надісланий користувачем, аналізується, компілюється та виконується в середовищі WebAssembly , а не безпосередньо на хост-системі. Такий підхід по суті обмежує можливості коду, оскільки Pyodide використовує віртуальну файлову систему в пам'яті, не має прямого доступу до хост-диска та не має традиційних можливостей фонової обробки.
Серед найважливіших обмежень: відсутність доступу до реальної файлової системи (лише до внутрішньої віртуальної файлової системи Pyodide), повна відсутність потоків та багатопроцесорності, неможливість запуску підпроцесів, відсутність доступу до пам'яті хоста, на якому запущено Node.js, відсутність обміну станом між викликами (оскільки все середовище перезапускається) та, за задумом, відсутність доступу до мережі чи Інтернету . Це останнє обмеження було задумано як проектне рішення, яке може бути переглянуте в майбутньому, але спочатку додало ще один рівень суперечок.
Другий рівень ізоляції – це саме хмарне розгортання: процес Node.js виконується всередині контейнера Docker , який розгорнуто на Google Cloud Run. Це не лише обмежує час виконання та доступні ресурси, але й відокремлює контейнер, що виконує код, від будь-якої іншої частини інфраструктури організації у разі гіпотетичного порушення пісочниці.
Підсумовуючи, оригінальний дизайн Terrarium спирається на комбінацію WebAssembly, Docker та Cloud Run для створення відносно безпечного середовища для виконання Python, з послідовними бар'єрами, які ускладнюють вихід з пісочниці до хост-системи та внутрішньої мережі.
Локальне розгортання, розгортання Docker та розгортання Google Cloud Run
Для використання Terrarium у середовищі розробки необхідно було встановити Node.js на машині . Після виконання цієї вимоги звичайна процедура полягала у встановленні залежностей проекту та запуску локального сервера разом із функцією, яка обробляє запити на виконання коду.
Коли сервер працював, можна було надсилати запити до локальної кінцевої точки для надсилання тестових файлів та скриптів Python , що дозволяло розробникам перевіряти поведінку пісочниці перед розгортанням у робочих середовищах. Були доступні скрипти для запуску набору тестів для всіх файлів .py у тестовому каталозі, що спрощувало перевірку середовища.
У контейнерних середовищах Terrarium можна було зібрати як образ Docker та запускати як окремий контейнер . Типові інструкції включали кроки збірки, запуску та зупинки, а також команди для пошуку ідентифікатора запущеного контейнера та керування ним вручну, якщо це необхідно.
Коли Terrarium мігрував до Google Cloud Run, його було розгорнуто як автоматично масштабований HTTP-сервіс із налаштовуваними параметрами ресурсів та паралельної роботи. Було доцільно налаштувати ці значення, щоб збалансувати продуктивність, вартість та безпеку . Наприклад, для інтенсивних робочих навантажень можна було виділити більше процесора та пам'яті, а паралельну роботу на екземпляр можна було обмежити, щоб запобігти блокуванню.
Важливо зазначити, що Pyodide, коли його налаштовано для Terrarium, працює в основному процесі Node.js. Це означає, що якщо ваш код Python стає особливо ресурсомістким або потрапляє у складні цикли, це може заблокувати здатність Node.js відповідати на інші запити. Pyodide пропонує використовувати Workers для сценаріїв, де необхідно переривати або додатково ізолювати виконання, але такий підхід ускладнює інтеграцію та, в деяких випадках, обмежує підтримку бібліотек, таких як matplotlib.
Проблеми управління медичними послугами та їхньої стабільності
Під час розгортання на Google Cloud Run однією з практичних проблем був моніторинг справності сервісу та відновлення після збоїв . Cloud Run за замовчуванням безпосередньо не підтримує перевірки справності, визначені в Dockerfiles за допомогою HEALTHCHECK, тому знадобилося невелике додаткове коригування.
Звичайна процедура включала опис сервісу Cloud Run за допомогою gcloud та експорт конфігурації у файл service.yaml. У цьому YAML було додано конфігурацію livenessProbe, пов'язану з образом контейнера, щоб Cloud Run міг виявляти, коли сервіс перестав відповідати належним чином.
Після зміни конфігурації існуючий сервіс було замінено відповідною командою gcloud, щоб Cloud Run активно відстежував стан контейнера та перезапускав його, якщо перевірка в режимі реального часу не вдалася. Ця операція була необхідною лише під час першого розгортання нового сервісу з цим конкретним образом.
На чистому рівні Docker існує додаткове обмеження: сам рушій Docker не пропонує автоматичних перезапусків виключно на основі HEALTHCHECK . Крім того, процес з PID 1 у контейнері особливо захищений і його не так легко завершити зсередини. Тому в деяких середовищах розглядається використання сторонніх інструментів, таких як docker-autoheal, які контролюють стан контейнера та примусово перезапускають його при виявленні проблем.
Щодо стабільності виконання, команда помітила, що такі помилки, як «RangeError: Maximum call stack size exceeded» (Перевищено максимальний розмір стека викликів), часто з'являлися в Pyodide під час обробки особливо великих навантажень. Це частіше траплялося при використанні дуже високих значень dpi під час генерації PNG за допомогою matplotlib або при виконанні особливо складних операцій pandas, що свідчить про внутрішні обмеження в управлінні стеком у середовищі WebAssembly.
Критична вразливість CVE-2026-5752 у Terrarium
З часом у Terrarium було виявлено критичну вразливість , ідентифіковану як CVE-2026-5752 та оцінену як 9,3 за шкалою CVSS. Такий рівень серйозності вказує на недолік із потенційно дуже високим впливом на безпеку систем, що використовують цю пісочницю.
Ця вразливість дозволяє зловмиснику виконувати довільний код з правами root у хост-процесі . Вектор атаки спирається на шкідливий обхід ланцюжка прототипів у середовищі Pyodide WebAssembly, ефективно обходячи обмеження пісочниці.
Найбільше занепокоєння викликає те, що для використання цієї вразливості не потрібні спеціальні привілеї чи додаткова взаємодія з користувачем . Зловмисник, який може впровадити код у пісочницю (наприклад, використовуючи функціональність виконання коду в інструменті, що використовує Terrarium), може скористатися цією вразливістю, щоб вийти з контрольованого середовища.
Після використання ця вразливість може дозволити несанкціонований доступ до конфіденційних системних файлів , таких як /etc/passwd або інших внутрішніх ресурсів контейнера , і навіть дозволити ескалацію на хост або інші служби, що використовують ту саму інфраструктуру, залежно від загальної конфігурації безпеки.
Ця ситуація становить значний ризик для всіх організацій, які використовують Terrarium як середовище виконання користувацького коду або моделі штучного інтелекту . Це не просто теоретична вразливість, а сценарій, коли порушення "пісочниці" може призвести до витоку даних, компрометації внутрішніх сервісів та горизонтального руху в мережі.
Вплив на бізнес, розробників та кінцевих користувачів
Виявлення цієї вразливості безпосередньо впливає на будь-яку компанію чи розробника, які інтегрували Terrarium у свою інфраструктуру для запуску ненадійного коду Python . Інструменти спільної розробки, навчальні платформи, сервіси аналітики на вимогу або продукти допомоги з кодом на основі штучного інтелекту можуть бути викриті, якщо вони використовують Terrarium як рівень середовища виконання.
З точки зору кінцевого користувача, ризик полягає не лише в тому, що інфраструктура постачальника послуг може бути скомпрометована, але й у тому, що особиста чи професійна інформація, що зберігається на цих платформах, може бути розголошена або маніпульована без попереднього повідомлення, якщо зловмиснику вдасться скористатися цією вразливістю.
Ситуація ще більше ускладнюється тим фактом, що Terrarium більше не підтримується активно . Це означає, що офіційного патчу для виправлення проблеми не очікується, залишаючи організації, які продовжують покладатися на це рішення, з відомою вразливістю та відсутністю підтримки.
У цьому контексті подальше використання Terrarium без додаткових заходів становить значний ризик для безпеки . Зловмисники, які знають про вектор експлойту, можуть цілеспрямовано атакувати сервіси, що продовжують використовувати цю технологію, шукаючи слабкі місця в загальній безпеці системи.
Крім того, в середовищах, де кілька сервісів використовують одну внутрішню мережу або навіть один кластер контейнерів, витік з Terrarium може відкрити шлях для латерального проникнення в інші, здавалося б, ізольовані системи , посилюючи потенційний вплив успішної атаки.
Стратегії пом'якшення наслідків та альтернативи, які слід розглянути
З огляду на вразливість такого масштабу та відсутність активного обслуговування, перша рекомендація для організацій полягає в тому, щоб терміново оцінити своє поточне використання Terrarium . Якщо він використовується для запуску стороннього коду або коду, згенерованого моделями штучного інтелекту, ризик більший і вимагає негайних дій.
Короткострокові заходи включають тимчасове вимкнення функцій, що дозволяють виконання довільного коду у продакшені, поки оцінюється безпечніша альтернатива. Інші варіанти включають посилення мережевих політик, подальшу сегментацію сервісів, що використовують Terrarium, та обмеження доступу до контейнера з інших систем.
У середньостроковій перспективі може бути розумнішим перейти на інші рішення для ізольованого виконання або тих, що мають активну підтримку та спільноту чи постачальника послуг для виправлення вразливостей. Це може включати керовані сервіси, безсерверні середовища виконання з більш жорсткими обмеженнями або архітектури мікросервісів, спеціально розроблені з урахуванням безпеки за замовчуванням.
У будь-якому разі, цей інцидент підкреслює важливість інтеграції належних практик безпеки в життєвий цикл розробки : регулярні аудити залежностей, огляд сторонніх компонентів, що використовуються в архітектурі, моніторинг відповідних CVE та плани швидкого реагування у разі виявлення критичного збою.
Компанії, що створюють інструменти на основі штучного інтелекту, що дозволяють кінцевим користувачам запускати або генерувати код, повинні ретельно проаналізувати дизайн своїх пісочниць , забезпечити оновлення процесів ізоляції та уникати використання покинутих проектів для таких конфіденційних функцій, як виконання ненадійного коду.
Все в Terrarium відображає ступінь, до якої виконання користувацького коду та моделей LLM вимагає екстремального підходу до безпеки . Високопродуктивна, недорога пісочниця може здаватися дуже привабливою, але якщо з'являється критична вразливість без жодного виправлення, баланс порушується, і ризик стає неприйнятним для багатьох серйозних випадків використання.
