2 puntos por GN⁺ 2025-03-29 | Aún no hay comentarios. | Compartir por WhatsApp
  • Lupin y Justin investigaron el sandbox de Python de la vista previa de Gemini en el LLM bugSWAT 2024 de Google en Las Vegas, extrajeron /usr/bin/entry/entry_point y la estructura interna de archivos, y ganaron el premio a Most Valuable Hacker por esta vulnerabilidad
  • El sandbox estaba basado en gVisor y GRTE, y tenía bloqueada la red externa, pero como el código del usuario podía recorrer el sistema de archivos con el módulo os, pudieron extraer binarios internos mediante fragmentos de salida por consola
  • El archivo entry_point, de 579 MB, provocaba timeout si se imprimía directamente, así que usaron seek() y codificación base64 para crear fragmentos de 10 MB, repitieron solicitudes con Caido Automate y luego reensamblaron todo localmente
  • El análisis con Binwalk reveló el directorio google3 y código Python relacionado con el sandbox de Gemini; a diferencia del código cuya exposición pública había sido aprobada, classification.proto y varias definiciones de proto de seguridad eran información interna confidencial incluida por error
  • También confirmaron una arquitectura en la que el sandbox se conecta por RPC con herramientas como Google Flights y la posibilidad de acceder a sandboxes de agentes con más privilegios, pero el manejador sospechoso de lectura de archivos internos no podía usarse por RPC y solo era invocable externamente

bugSWAT 2024 y acceso anticipado a la vista previa de Gemini

  • Lupin y Justin obtuvieron acceso anticipado a la vista previa de la siguiente actualización de Gemini durante el evento LLM bugSWAT de Google en Las Vegas en 2024
  • El equipo de Google les proporcionó documentación con nuevas funciones y comportamientos esperados, y el objetivo de los investigadores era explorar y probar esas funciones desde la perspectiva de un atacante
  • Al comenzar con el prompt simple run hello world in python3, Gemini generó código y mostró en la interfaz el botón Run in Sandbox
  • Como resultado de esta investigación de la vulnerabilidad, ambos recibieron el título de Most Valuable Hacker en ese bugSWAT de Las Vegas

Estructura básica del sandbox de Python de Gemini

  • En ese momento, Gemini ofrecía un Python Sandbox Interpreter para ejecutar dentro del entorno de Gemini código Python generado por la IA o scripts escritos directamente por el usuario
  • El sandbox estaba construido sobre gVisor y GRTE (Google Runtime Environment)
    • gVisor es un kernel en espacio de usuario que intercepta llamadas al sistema entre aplicaciones en contenedores y el sistema operativo host
    • En lugar de depender solo del aislamiento tradicional a nivel de sistema operativo, implementa un subconjunto minimizado de funciones del kernel para reducir la superficie de ataque
  • Los investigadores consideraban que escapar del sandbox de gVisor era un problema aparte y de alta dificultad, y una fuga del sandbox podía calificar para una recompensa de hasta $100k
  • En vez de escapar del sandbox, su enfoque fue buscar si dentro del sandbox había datos que no debían quedar expuestos hacia afuera
  • La restricción principal era que el sandbox solo podía ejecutar un binario de Python compilado de forma personalizada

Mapeo del sistema de archivos y hallazgo de entry_point

  • Reescribiendo por completo el código Python desde el frontend, podían ejecutar versiones arbitrarias dentro del sandbox
  • No podían abrir un shell, pero como el binario personalizado de Python incluía el módulo os, sí podían mapear el sistema de archivos
  • Los investigadores escribieron una función de Python para listar recursivamente archivos y directorios e imprimir tamaño y permisos
  • El resultado de llamar a lslR("/usr") mostró un archivo binario en /usr/bin/entry/entry_point
  • Ese archivo medía 579 MB y se convirtió en el objetivo principal del análisis posterior

Cómo filtraron el binario sin red

  • Cuando intentaron codificar entry_point directamente en base64 y mostrarlo en el frontend, el sandbox se colgó y terminó en timeout
  • Todos los intentos de exfiltración externa por TCP, HTTP y DNS fallaron, y el sandbox parecía estar completamente aislado de la red externa
  • Como las llamadas externas estaban bloqueadas, eligieron exfiltrar el binario en partes usando la salida de consola
  • Usaron seek() para mover la posición dentro del binario, leerlo, codificarlo en base64 y luego imprimirlo en fragmentos de 10 MB
  • Usaron Caido como proxy para capturar las solicitudes al sandbox y sus resultados, y repitieron las solicitudes con la función Automate
    • Automate permite enviar solicitudes en masa y cambiar parámetros rápidamente
    • Después de reunir todos los fragmentos base64, reconstruyeron el archivo completo de forma local

Resultados del análisis de entry_point

  • El comando file identificó el archivo como un binario dinámicamente enlazado en formato ELF 64-bit LSB shared object, x86-64, version 1 (SYSV)
  • En la salida del comando strings aparecían repetidamente referencias a google3, el repositorio interno de Google
  • Estas referencias sugerían la presencia de rutas de datos internas y fragmentos de código, y mostraban rastros de software propietario de Google dentro del binario
  • Binwalk dio la pista decisiva
    • Extrajo una estructura completa de archivos desde dentro del binario
    • El resultado dejó al descubierto el layout del sandbox y sus componentes internos

Directorio google3 y código Python relacionado con Gemini

  • Dentro del directorio extraído con Binwalk había un directorio google3, con subdirectorios como assistant, base, devtools, file, google, net, pyglib, testing, third_party y util
  • En el directorio assistant encontraron código de Gemini relacionado con RPC usado para procesar solicitudes de herramientas como YouTube, Google Flights y Google Maps
  • En particular, bajo google3/assistant/boq/lamda/execution_box/ había archivos Python relacionados con ejecución en sandbox, procesamiento de imágenes, uso de herramientas e interfaces RPC
  • google3/assistant/boq/lamda/execution_box/images/py_interpreter.py incluía código con una cadena que parecía destinada a detectar volcados no autorizados de scripts
    • La cadena era "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh"
  • En una revisión posterior se determinó que la inclusión interna de este código Python de Google3 era una exposición pública aprobada por el Google Security Team antes del lanzamiento
  • Ese código incluía elementos que parecían mecanismos anti-dump, pero su exposición pública en sí estaba autorizada

El sandbox y la arquitectura RPC de herramientas de Google

  • Un análisis más profundo confirmó que el sandbox se comunicaba con servidores externos de Google para obtener datos de servicios como Google Flights
  • Esa comunicación estaba implementada mediante una clase de Python en google3.assistant.boq.lamda.execution_box.sandbox_interface
  • Funciones como _set_reader_and_writer configuraban los handles de reader y writer para RPC
    • El comportamiento predeterminado parecía usar /dev/fd/3 y /dev/fd/4
  • run_tool(name, operation_id, parameters) recibía el nombre de la herramienta, el ID de operación y los parámetros, construía un RunToolRequest y lo enviaba como solicitud RPC
  • Las funciones serializaban los datos en un formato compatible con protobuf, luego escribían al descriptor de archivo local 5 y leían la respuesta desde el descriptor 7
  • Usando los proto encontrados dentro del gran binario, los investigadores pudieron construir mensajes para el servidor RPC y llamar directamente a herramientas de Google

Sandbox de agentes y diferencias de privilegios

  • No todos los sandboxes podían acceder al mismo conjunto de servicios de Google
  • La diferencia dependía de si el sandbox había sido creado por el frontend para ejecutar código fuente Python o por un Google Agent
  • El equipo de Google mostró como base de Gemini la investigación REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS
  • El enfoque ReAct alterna entre generar trazas de razonamiento y ejecutar acciones específicas
    • El modelo resuelve el problema, construye un plan e interactúa con fuentes externas para obtener los datos necesarios
    • Se presenta como un framework aplicable a tareas como preguntas y respuestas, verificación de hechos, juegos basados en texto y navegación web
  • Si un usuario preguntara por el vuelo más temprano entre Toronto y Nueva York, Gemini podría seguir aproximadamente este flujo
    • Interpretar la intención del usuario como una búsqueda de vuelos
    • Planear código Python para conectarse a la herramienta de Google Flights
    • Generar código que busque vuelos de YYZ a JFK desde hoy hasta la próxima semana y los ordene por fecha
    • Crear un sandbox con los permisos necesarios y ejecutar el código
    • Procesar el resultado y responder al usuario

Experimentos de inyección secundaria de prompts y límites

  • Los investigadores probaron si podían usar inyección secundaria de prompts en la fase de planificación de Gemini para acceder a un sandbox con más privilegios
  • Con ayuda del Google Security Team, confirmaron en pruebas que, dependiendo de factores probabilísticos como la semilla de generación y la temperatura, a veces podían acceder a un entorno que parecía un sandbox con más privilegios
  • Aquí, un sandbox con más privilegios significaba un entorno capaz de usar dos nuevos descriptores de archivo para acceder a funciones extendidas
    • Los descriptores de archivo siempre existían, pero no siempre estaban realmente en escucha
    • Cuando un agente invocaba el sandbox, podía monitorear llamadas de extensión a servicios de Google e interactuar con la API
    • Desde el intérprete de Python no se podía acceder a esas funciones extendidas
  • Los investigadores pensaron que un manejador de mensajes específico podía permitir lectura de archivos dentro de la infraestructura interna de Google y esperaban que fuera un posible P0
  • La revisión del Google Security Team confirmó que ese manejador sospechoso no podía usarse por RPC y solo podía llamarse externamente
  • Aunque el experimento fue limitado, la ejecución de código podía abrir varias posibilidades
    • Reliability: ejecutar código puede disparar comportamientos de forma más consistente
    • Chaining/Complexity: permite componer control de múltiples herramientas o ajustes de parámetros de manera más compleja que con texto
    • Tool Output Poisoning: facilita intentos más efectivos de manipular la salida de herramientas
    • Leaks: si se exponen partes ocultas del entorno, eso puede dar ventajas adicionales

Archivos proto realmente expuestos

  • Los investigadores confirmaron que podían exfiltrar archivos proto de varias maneras
  • Los archivos proto son archivos de Protocol Buffer que actúan como planos para definir la estructura de mensajes y la forma en que un sistema intercambia información
  • Tras ejecutar strings entry_point > stringsoutput.txt, buscaron Dogfood y encontraron parte de proto internos
  • Parte del contenido extraído incluía descripciones de metadatos de proto muy sensibles
    • No incluía datos de usuarios en sí
    • Eran categorías internas usadas por Google para clasificar datos de usuarios
  • Dogfood se refiere a la práctica en Google de usar internamente sus propios productos y prototipos antes del lanzamiento público para probarlos y mejorarlos
  • Uno de los archivos expuestos era privacy/data_governance/attributes/proto/classification.proto
    • Ese archivo trata sobre cómo se clasifican los datos dentro de Google
    • También incluía referencias a documentación relacionada, pero esos documentos son confidenciales y no están destinados al acceso público

Exposición de definiciones internas de proto de seguridad

  • En la misma salida de strings también aparecieron varios archivos proto internos que no debían hacerse públicos
  • Con el comando cat stringsoutput.txt| grep '\.proto' | grep 'security' aparecieron rutas sensibles como las siguientes
    • security/thinmint/proto/core/thinmint_core.proto
    • security/thinmint/proto/thinmint.proto
    • security/credentials/proto/authenticator.proto
    • security/data_access/proto/standard_dat_scope.proto
    • security/loas/l2/proto/credstype.proto
    • security/credentials/proto/end_user_credentials.proto
    • security/loas/l2/proto/usertype.proto
    • security/credentials/proto/iam_request_attributes.proto
    • security/util/proto/permission.proto
    • security/loas/l2/proto/common.proto
    • ops/security/sst/signalserver/proto/ss_data.proto
    • security/credentials/proto/data_access_token_scope.proto
    • security/loas/l2/proto/identity_types.proto
    • security/credentials/proto/principal.proto
    • security/loas/l2/proto/instance.proto
    • security/credentials/proto/justification.proto
  • Al revisar security/credentials/proto/authenticator.proto dentro de las cadenas del binario, pudieron comprobar que esos datos sí se habían expuesto realmente

Por qué los proto terminaron dentro del binario

  • El Google Security Team revisó el contenido del sandbox y había aprobado su divulgación pública
  • Sin embargo, el pipeline de compilación del binario del sandbox tenía un paso automático que añadía archivos proto de seguridad al binario si determinaba que podían ser necesarios para aplicar reglas internas
  • En este caso ese paso no era necesario, pero terminó incluyendo por error proto internos altamente confidenciales
  • Como los investigadores sabían que Google trata estos proto como información extremadamente sensible que no debe hacerse pública, lo reportaron como bug
  • Para identificar y reportar este tipo de exposición sutil hace falta entender a fondo las reglas de negocio y las prioridades de seguridad de la organización objetivo

Conclusión e implicaciones prácticas

  • Los sistemas avanzados de IA antes de su lanzamiento deben probarse a fondo no solo por su comportamiento funcional, sino también por sus artefactos internos
  • Incluso un sandbox que parece simple puede abrir rutas de exposición inesperadas cuando está conectado a múltiples funciones extendidas
  • Cuando varios componentes operan juntos, una omisión pequeña puede crear una nueva vía de problemas
  • En este caso se distinguió entre código interno cuya exposición estaba aprobada y proto confidenciales incluidos de forma no intencional; esto último fue el núcleo real del reporte de seguridad
  • En entornos donde se combinan agentes de IA, ejecución en sandbox, invocación de herramientas y RPC interno, hay que revisar no solo el aislamiento de ejecución, sino también los activos dentro del sandbox y los artefactos generados en el build

Aún no hay comentarios.

Aún no hay comentarios.