Cohere AI Terrarium의 샌드박스: 작동 방식, 위험 요소 및 주요 취약점

인포매텍 디지털 » Recursos » Cohere AI Terrarium의 샌드박스: 작동 방식, 위험 요소 및 주요 취약점

신뢰할 수 없거나 AI가 생성한 파이썬 코드를 실행할 때 가장 큰 과제 중 하나는 이를 안전 하고 신속하게, 그리고 인프라 비용 부담 없이 실행하는 방법입니다. 바로 이러한 맥락에서 Cohere AI가 개발한 Terrarium이 등장했습니다. Terrarium은 클라우드, 특히 Google Cloud Run에 배포된 컨테이너 내에서 이러한 유형의 코드를 호스팅하고 실행하기 위한 샌드박스 역할을 하도록 설계되었습니다.

이러한 접근 방식 덕분에 개발자와 기업은 테라리움을 격리된 환경으로 활용하여 합리적인 비용과 우수한 성능으로 사용자 코드 또는 LLM 모델을 배포할 수 있었습니다 . 그러나 시간이 지남에 따라 매우 심각한 취약점들이 드러났는데 , 그중 하나는 CVE 식별자를 통해 샌드박스 보안의 치명적인 결함을 노출시켜 테라리움을 주목받게 했습니다.

테라리움이란 무엇이며, 어떤 용도로 만들어졌을까요?

Terrarium은 기본적으로 파이썬을 위한 격리된 런타임 환경으로 , 예를 들어 Google Cloud Run에 배포 가능한 Docker 컨테이너 로 작동하도록 설계되었습니다 . 주요 목적은 잠재적으로 위험하거나 알려지지 않은 코드(예: 사용자가 제출한 스크립트 또는 언어에서 생성된 코드 조각)를 메인 인프라에 직접적인 위험을 초래하지 않고 배포할 수 있는 샌드박스를 제공하는 것입니다.

이 프로젝트의 핵심 철학은 기존 워크플로에 쉽게 통합할 수 있는 저렴하고 지연 시간이 짧은 서비스를 제공하는 것입니다 . Terrarium은 HTTP 요청을 통해 호출되도록 설계되었으며, 실행할 Python 코드와 선택적으로 입력 파일을 전송하고 실행 결과와 생성된 파일을 다시 수신합니다.

실제로 이는 외부 시스템, API 또는 내부 도구가 파이썬 코드 실행을 테라리움에 위임하여 해당 코드를 리소스, 실행 시간 및 허용된 기능에 대한 명확한 규칙이 있는 비교적 제한된 환경 내에 유지할 수 있음을 의미합니다.

Terrarium의 핵심 설계 특징 중 하나는 Node.js 프로세스 내에서 실행되는 CPython을 WebAssembly로 변환하는 Pyodide 에 의존한다는 점입니다 . 이러한 접근 방식은 Python 코드가 호스트 시스템에서 네이티브로 실행되는 것이 아니라 캡슐화된 인터프리터 내에서 실행됨으로써 이론적으로 격리성을 강화한다는 것을 의미합니다.

샌드박스의 성능, 비용 및 주요 기능

Terrarium의 가장 큰 장점 중 하나는 낮은 운영 비용과 적절한 성능 의 조합이었습니다 . Google Cloud Run에 실제 배포했을 때, 일반적인 구성(메모리 2GB, vCPU 1개, 온디맨드 자동 확장 기능을 갖춘 상시 가동 인스턴스 최소 1개)에서 내부 주석 작업 단계 동안 보고된 월 비용은 약 30달러였습니다.

속도 측면에서, 앞서 설명한 테스트 결과에 따르면 Terrarium은 예를 들어 간단한 matplotlib 플롯의 200dpi PNG 이미지를 약 900ms의 실행 시간 내에 생성할 수 있으며, SVG 버전은 약 500ms 만에 생성할 수 있습니다. 이러한 시간은 Cloud Run에서 호스팅되는 코드와 서비스의 일반적인 호출 주기를 기준으로 합니다.

Terrarium은 성능 향상 외에도 각 실행 간의 완벽한 격리를 자랑했습니다 . 각 실행 후 샌드박스는 완전히 재활용되었습니다. Pyodide의 가상 파일 시스템, 전역 변수, 로드된 라이브러리 및 모든 내부 상태가 폐기되었습니다. 이는 어떤 실행도 이전 실행의 데이터나 컨텍스트를 상속받지 않도록 하여 정보 유출 위험을 줄이는 것을 목표로 했습니다.

또 하나 중요한 점은, 강력한 격리가 목표였지만 Cohere는 샌드박스의 무결성에 대해 절대적인 보장을 제공하지는 않는다고 분명히 밝혔다 는 것입니다. 이는 여러 겹의 보호 장치에도 불구하고, 특히 WebAssembly와 Node.js의 통합처럼 복잡한 환경에서는 취약점이 발견될 가능성이 있음을 시사합니다.

Terrarium은 다른 서비스에서 쉽게 사용할 수 있도록 설계되었습니다. Cloud Run에 배포된 엔드포인트로 실행할 코드와 인증 토큰 (구성에서 필요한 경우)을 함께 HTTP 요청으로 전송하기만 하면 됩니다. 그러면 결과가 담긴 JSON 파일과, 필요한 경우 생성된 파일들이 base64로 인코딩된 파일을 받게 됩니다.

Pyodide의 파일 실행 및 라이브러리 지원

Terrarium의 매력적인 기능 중 하나는 입력 및 출력 파일을 기본적으로 지원한다는 점이었습니다 . API를 통해 요청에 파이썬 코드와 함께 모든 유형의 파일을 여러 개 첨부할 수 있었고, 이러한 파일들은 Pyodide가 파이썬 인터프리터에 노출하는 가상 파일 시스템에 저장되었습니다.

실행 중에 파이썬 코드는 샌드박스 내의 로컬 파일처럼 이러한 파일을 읽고 조작 할 수 있었습니다 . 실행이 완료되면 Terrarium은 생성되거나 수정된 ​​모든 파일을 수집하여 클라이언트에 응답으로 반환했는데, 일반적으로 HTTP를 통한 원활한 전송을 위해 인코딩된 형태로 전달되었습니다.

라이브러리 생태계 측면에서, Pyodide를 기반으로 하는 Terrarium은 상당히 광범위한 과학 및 데이터 분석 패키지 세트를 계승했습니다 . 직접 지원되는 패키지에는 numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy 및 sqlite3(후자는 기본적으로 활성화되어 있지 않지만 필요한 경우 로드할 수 있는 옵션이 있음)가 포함됩니다.

matplotlib의 경우 몇 가지 제약 사항이 있었습니다. plt.show()는 이 환경에서 지원되지 않았지만 , plt.savefig()를 사용하여 이미지를 생성하는 것은 과도한 매개변수(예: 리소스 사용량을 증가시키는 매우 높은 해상도)를 강제로 사용하지 않는 한 제대로 작동했습니다.

이러한 라이브러리 세트 덕분에 Terrarium은 데이터 분석, 시각화, 머신 러닝 모델 프로토타이핑, 구조화된 정보 조작과 같은 작업 에 특히 유용했으며 , 이 모든 작업은 이론적으로 제어된 샌드박스 내에서 실행되었습니다.

내부 아키텍처: 격리 및 배포 계층

Terrarium의 아키텍처는 공격 표면을 줄이고 신뢰할 수 없는 코드를 최대한 격리 하도록 설계된 여러 계층으로 구성되어 있습니다 . 첫 번째 계층은 호스트 역할을 하며 Pyodide, 즉 WebAssembly로 컴파일된 CPython을 로드하는 Node.js 프로세스 자체입니다.

사용자가 제출한 파이썬 코드는 호스트 시스템에서 네이티브로 실행되는 것이 아니라 WebAssembly 환경 내에서 파싱, 컴파일 및 실행됩니다 . 이러한 접근 방식은 Pyodide가 메모리의 가상 파일 시스템을 사용하고 호스트 디스크에 직접 접근할 수 없으며 기존의 백그라운드 처리 기능이 없기 때문에 코드의 기능을 본질적으로 제한합니다.

가장 중요한 제약 사항으로는 실제 파일 시스템에 접근할 수 없고 (Pyodide의 내부 가상 파일 시스템에만 접근 가능), 스레딩 및 멀티프로세싱을 전혀 사용할 수 없으며, 서브프로세스를 실행할 수 없고, Node.js를 실행하는 호스트의 메모리에 접근할 수 없으며, 호출 간 상태 공유가 불가능하고(전체 환경이 재시작되기 때문), 설계상 네트워크나 인터넷에 접근할 수 없다는 점 등 이 있습니다. 마지막 제약 사항은 향후 수정될 수 있는 설계상의 결정이었지만, 초기에는 또 다른 난제를 야기했습니다.

두 번째 격리 계층은 클라우드 배포 자체입니다. Node.js 프로세스는 Google Cloud Run에 배포된 Docker 컨테이너 내부에서 실행됩니다. 이는 런타임 및 사용 가능한 리소스를 제한할 뿐만 아니라, 가상의 샌드박스 침해 사고 발생 시 코드가 실행되는 컨테이너를 조직 인프라의 다른 부분과 분리하는 효과도 있습니다.

요약하자면, 테라리움의 초기 설계는 웹어셈블리, 도커, 클라우드 런을 조합하여 파이썬 실행을 위한 비교적 안전한 환경을 구축하는 데 기반을 두고 있으며, 샌드박스에서 호스트 시스템 및 내부 네트워크로 탈출하는 것을 어렵게 만드는 여러 단계의 보안 장벽을 갖추고 있습니다.

로컬 배포, Docker 배포 및 Google Cloud Run 배포

Terrarium을 개발 환경에서 사용하려면 먼저 컴퓨터에 Node.js가 설치되어 있어야 했습니다 . 이 요구 사항이 충족되면 일반적인 절차에 따라 프로젝트 종속성을 설치하고 로컬 서버를 실행하며 코드 실행 요청을 처리하는 함수를 실행하면 됩니다.

서버가 실행 중인 상태에서 로컬 엔드포인트로 테스트 파일과 파이썬 스크립트를 전송하는 요청을 보낼 수 있어 개발자는 프로덕션 환경에 배포하기 전에 샌드박스의 동작을 검증할 수 있었습니다. 테스트 디렉터리에 있는 모든 .py 파일에 대해 일련의 테스트를 실행하는 스크립트가 제공되어 환경 검증이 간소화되었습니다.

컨테이너 환경에서 Terrarium은 Docker 이미지로 빌드하여 독립 실행형 컨테이너로 실행할 수 있습니다 . 일반적인 지침에는 빌드, 실행 및 중지 단계뿐만 아니라 실행 중인 컨테이너의 식별자를 찾고 필요한 경우 수동으로 관리하는 명령도 포함됩니다.

Terrarium이 Google Cloud Run으로 마이그레이션되었을 때, 구성 가능한 리소스 및 동시 접속 매개변수를 갖춘 자동 확장 HTTP 서비스로 배포되었습니다. 성능, 비용 및 보안의 균형을 맞추기 위해 이러한 값을 조정하는 것이 권장되었습니다 . 예를 들어, 집약적인 워크로드의 경우 더 많은 CPU와 메모리를 할당하고, 인스턴스별 동시 접속 수를 제한하여 블로킹을 방지할 수 있었습니다.

Pyodide를 Terrarium에 맞게 구성하면 메인 Node.js 프로세스에서 실행된다는 점에 유의해야 합니다 . 즉, Python 코드가 특히 리소스를 많이 사용하거나 복잡한 반복문을 실행하는 경우 Node.js가 다른 요청에 응답하는 것을 방해할 수 있습니다. Pyodide는 실행을 중단하거나 더욱 격리해야 하는 시나리오에서 Workers를 사용할 것을 권장하지만, 이 방식은 통합을 복잡하게 만들고 경우에 따라 matplotlib과 같은 라이브러리 지원을 제한할 수 있습니다.

보건 서비스 관리 및 안정성 문제

Google Cloud Run에 배포할 때 실질적인 어려움 중 하나는 서비스 상태 모니터링 및 충돌 복구 였습니다 . Cloud Run은 기본적으로 Dockerfile에서 HEALTHCHECK를 사용하여 정의된 상태 확인을 직접 지원하지 않으므로 약간의 추가 조정이 필요했습니다.

일반적인 절차는 gcloud 명령어를 사용하여 Cloud Run 서비스를 정의하고 , 해당 구성을 service.yaml 파일로 내보내는 것이었습니다. 이 YAML 파일에는 컨테이너 이미지와 연결된 livenessProbe 구성이 추가되어 Cloud Run이 서비스가 제대로 응답하지 않을 때를 감지할 수 있도록 했습니다.

구성이 수정되면 기존 서비스는 적절한 gcloud 명령으로 대체되어 Cloud Run 이 컨테이너 상태를 적극적으로 모니터링 하고 실시간 확인에 실패하면 컨테이너를 다시 시작합니다. 이 작업은 해당 이미지로 새 서비스를 처음 배포할 때만 필요했습니다.

순수 Docker 수준에서는 추가적인 제약 사항이 있습니다. Docker 엔진 자체는 HEALTHCHECK에만 의존하여 자동 재시작 기능을 제공하지 않습니다 . 또한 컨테이너 내에서 PID가 1인 프로세스는 특별히 보호되어 있어 내부에서 종료하기가 쉽지 않습니다. 따라서 일부 환경에서는 컨테이너의 상태를 모니터링하고 문제가 감지될 때 강제로 재시작하는 docker-autoheal과 같은 타사 도구를 사용하는 것이 고려됩니다.

실행 안정성과 관련하여, 팀은 특히 부하가 큰 작업을 처리할 때 Pyodide에서 "RangeError: Maximum call stack size exceeded"와 같은 오류가 자주 발생하는 것을 확인했습니다 . 이러한 오류는 matplotlib을 사용하여 PNG를 생성할 때 매우 높은 DPI 값을 사용하거나 특히 복잡한 pandas 연산을 실행할 때 더 자주 발생했으며, 이는 WebAssembly 환경 내 스택 관리의 내부적인 한계를 시사합니다.

Terrarium의 심각한 취약점 CVE-2026-5752

시간이 지남에 따라 Terrarium에서 CVE-2026-5752로 식별되는 심각한 취약점이 발견되었으며 , CVSS 척도에서 9,3 등급을 받았습니다. 이 심각도 수준은 해당 샌드박스를 사용하는 시스템의 보안에 매우 큰 영향을 미칠 수 있는 결함임을 나타냅니다.

이 취약점은 공격자가 호스트 프로세스에서 루트 권한으로 임의 코드 실행을 수행할 수 있도록 합니다 . 공격 방식은 Pyodide WebAssembly 환경 내에서 악의적인 프로토타입 체인 탐색을 이용하며, 이를 통해 샌드박스 제한을 효과적으로 우회합니다.

가장 우려스러운 점은 이 취약점을 악용하는 데 특별한 권한이나 추가적인 사용자 상호 작용이 필요하지 않다는 것 입니다 . 샌드박스에 코드를 삽입할 수 있는 공격자(예를 들어, Terrarium을 사용하는 도구의 코드 실행 기능을 악용하는 경우)는 이 결함을 이용하여 통제된 환경에서 벗어날 수 있습니다.

이 취약점이 악용될 경우, /etc/passwd 와 같은 민감한 시스템 파일 이나 컨테이너 내부 리소스 에 무단으로 접근할 수 있으며 , 전반적인 보안 구성에 따라 호스트 또는 동일한 인프라를 공유하는 다른 서비스로 권한이 상승할 수도 있습니다.

이러한 상황은 Terrarium을 사용자 코드 또는 AI 모델 실행 환경으로 사용하는 모든 조직 에 상당한 위험을 초래합니다 . 이는 단순히 이론적인 취약점이 아니라, 샌드박스 침해로 인해 데이터 유출, 내부 서비스 손상, 네트워크 내 횡적 이동이 발생할 수 있는 시나리오입니다.

기업, 개발자 및 최종 사용자에게 미치는 영향

이번 취약점 발견은 신뢰할 수 없는 파이썬 코드를 실행하기 위해 테라리움을 인프라에 통합한 모든 회사나 개발자에게 직접적인 영향을 미칩니다 . 테라리움을 런타임 레이어로 사용하는 협업 개발 도구, 학습 플랫폼, 온디맨드 분석 서비스 또는 AI 기반 코드 지원 제품은 이러한 취약점에 노출될 수 있습니다.

최종 사용자의 관점에서 볼 때, 위험은 서비스 제공업체의 인프라가 손상될 수 있다는 것뿐만 아니라, 공격자가 취약점을 악용할 경우 해당 플랫폼에 저장된 개인 정보나 업무 정보가 사전 고지 없이 유출되거나 조작될 수 있다는 점입니다.

테라리움이 더 이상 활발하게 유지보수되지 않는다는 사실 때문에 상황은 더욱 복잡해집니다 . 이는 문제를 해결하는 공식 패치가 제공될 가능성이 낮다는 것을 의미하며, 따라서 이 솔루션에 계속 의존하는 조직들은 알려진 취약점에 대한 지원도 받지 못한 채 방치될 수밖에 없습니다.

이러한 맥락에서, 추가적인 조치 없이 테라리움을 계속 사용하는 것은 상당한 보안 위험을 초래합니다 . 공격 경로를 알고 있는 공격자는 이 기술을 계속 사용하는 서비스를 표적으로 삼아 시스템 전체 보안의 취약점을 찾아 공격할 수 있습니다.

또한, 여러 서비스가 동일한 내부 네트워크 또는 동일한 컨테이너 클러스터를 공유하는 환경에서는 Terrarium에서 정보 유출이 발생할 경우 겉으로는 격리된 것처럼 보이는 다른 시스템으로의 측면 이동이 가능해져 공격 성공 시 잠재적 영향이 증폭될 수 있습니다.

고려해야 할 완화 전략 및 대안

이처럼 심각한 취약점과 미흡한 유지보수 상황을 고려할 때, 조직은 우선 테라리움(Terrarium)의 현재 사용 현황을 시급히 평가해야 합니다 . 특히 타사 코드나 AI 모델이 생성한 코드를 실행하는 데 테라리움을 사용하고 있다면, 위험 노출 정도가 더욱 크므로 즉각적인 조치가 필요합니다.

단기적인 조치로는 보다 안전한 대안을 검토하는 동안 운영 환경에서 임의 코드 실행을 허용하는 기능을 일시적으로 비활성화하는 것이 있습니다 . 다른 옵션으로는 네트워크 정책 강화, Terrarium을 사용하는 서비스의 추가 분리, 다른 시스템에서 컨테이너에 대한 접근 제한 등이 있습니다.

중기적으로는 활발한 유지 관리가 이루어지고 취약점 패치를 제공하는 커뮤니티 또는 공급업체가 있는 다른 샌드박싱 또는 격리된 실행 솔루션으로 마이그레이션하는 것이 더 현명할 수 있습니다 . 여기에는 관리형 서비스, 더 강력한 제한이 있는 서버리스 실행 환경 또는 기본적으로 보안을 고려하여 설계된 마이크로서비스 아키텍처가 포함될 수 있습니다.

어쨌든 이번 사건은 개발 수명주기에 우수한 보안 관행을 통합하는 것이 얼마나 중요한지 보여줍니다 . 정기적인 종속성 감사, 아키텍처에 사용되는 타사 구성 요소 검토, 관련 CVE 모니터링, 그리고 심각한 오류가 감지되었을 때 신속한 대응 계획 수립 등이 여기에 포함됩니다.

최종 사용자가 코드를 실행하거나 생성할 수 있도록 하는 AI 기반 도구를 개발하는 기업은 샌드박스 설계 방식을 신중하게 분석하고 , 격리 프로세스를 최신 상태로 유지하며, 신뢰할 수 없는 코드 실행과 같은 민감한 기능에 더 이상 사용되지 않는 프로젝트를 활용하지 않도록 해야 합니다.

Terrarium의 모든 것은 사용자 코드와 LLM 모델을 실행하는 데 있어 극단적인 보안 접근 방식이 얼마나 중요한지를 보여줍니다 . 고성능 저비용 샌드박스는 매우 매력적으로 보일 수 있지만, 패치가 보이지 않는 심각한 취약점이 발생하면 균형이 깨지고 많은 중요한 사용 사례에서 위험을 감수할 수 없게 됩니다.