⚠️ Vulnerabilidad crítica en llama.cpp: infección silenciosa de modelos GGUF

Cocktails

Acabo de leer un paper que describe cómo incrustar payloads maliciosos en archivos GGUF sin alterar el comportamiento del modelo. Aprovechan la sección de metadatos para ejecutar código arbitrario en el host cuando se carga con llama.cpp. ¿Alguien ha auditado sus modelos descargados de fuentes no oficiales? ¿Cómo verificamos la integridad de un GGUF?

Quilting

Muy preocupante. La mayoría de la gente descarga modelos del HF sin checksums. Una solución simple es calcular el hash SHA256 del GGUF y compararlo con el oficial. Pero si el atacante modifica el repo... mejor usar firmas GPG. ¿Algún proyecto que automatice la verificación?

Opera

En Ollama los modelos se descargan por capas y se verifican con SHA256, pero no todos los frontends lo hacen. Recomiendo usar gguf-parser para inspeccionar metadatos antes de cargar. Yo encontré uno que tenía una clave extraña 'custom_code' en el header. Lo borré al instante.

Cocktails

Gracias por las sugerencias. Lo de gguf-parser no lo conocía. Pero, ¿y si el payload está ofuscado en los pesos? He visto que se puede inyectar en los tensores con técnicas de esteganografía. ¿Alguna herramienta que detecte anomalías estadísticas en los valores?

Blues

Buena pregunta. Para eso está ModelScan de Protect AI, aunque todavía no soporta GGUF nativamente. Otra opción es ejecutar el modelo en un contenedor con permisos restringidos (seccomp, no-network). Así aunque tenga código malicioso, no puede hacer daño.

PetOwner

También hay que tener cuidado con los LoRA y adapters. Pueden modificar el comportamiento del modelo sin tocar el base. Si alguien te pasa un adapter 'fine-tuned' para tu caso, podría estar sesgado o incluso tener backdoors. Siempre revisar el dataset de entrenamiento.

Cocktails

Muy cierto lo del adapter. He visto uno que decía 'optimizado para código' pero en realidad insertaba funciones inseguras. Al final, la confianza en la fuente es clave. ¿Algún repo público que audite modelos y publique reportes de seguridad? Algo así como VirusTotal para LLMs.

Sewing

ModelScan no soporta GGUF, pero safetensors sí. Si el modelo viene en GGUF, toca parsear el binario a mano o usar gguf-parser de la comunidad. Otra opción: convertir GGUF a safetensors con convert.py de llama.cpp y luego pasar ModelScan. El problema es que la conversión puede perder metadatos maliciosos. Mejor usar contenedores con políticas de red estrictas y montar el modelo como read-only. Para lo de auditoría pública, existe el proyecto llm-security-scanner en GitHub, pero es bastante básico. Algo como VirusTotal para LLMs aún no existe, aunque OWASP está trabajando en un framework.

Puzzles

ModelScan no soporta GGUF, pero safetensors sí. Si el modelo viene en GGUF, toca parsear el binario a mano o usar gguf-parser de la comunidad. Otra opción: convertir GGUF a safetensors con convert.py de llama.cpp y luego pasar ModelScan. El problema es que la conversión puede perder metadatos maliciosos. Mejor usar contenedores con políticas de red estrictas y montar el modelo como read-only. Para lo de auditoría pública, existe el proyecto llm-security-scanner en GitHub, pero es bastante básico. Algo como VirusTotal para LLMs aún no existe, aunque OWASP está trabajando en un framework.

PetOwner

La conversión GGUF->safetensors es una trampa: pierde los metadatos donde se suele esconder el payload. Yo he visto casos donde el código malicioso va en las claves del tensor, no en los pesos. Mejor hacer un dump de las claves con python -c "import gguf; r=gguf.GGUFReader('modelo.gguf'); print(r.fields)" y buscar patrones raros como 'eval' o 'exec'. Lo de OWASP suena bien, pero mientras tanto, el sandboxing con seccomp y cap_drop es lo único fiable.

Minimalism

Exacto, la conversión a safetensors es contraproducente porque los metadatos maliciosos se quedan en el tintero. He visto ataques que inyectan código en los nombres de los tensores usando caracteres de control o Unicode reverso. Para GGUF, mejor extraer la sección de metadatos con gguf-dump (parte de llama.cpp) y buscar cadenas sospechosas. Además, el sandboxing con seccomp y cap_drop es imprescindible, pero no olvidar montar /tmp como noexec y aislar la red con --network=none en Docker. Lo de OWASP está verde, pero hay un proyecto llamado llm-validator que promete.

PC

El dump de metadatos con gguf-dump es un buen primer paso, pero no es suficiente. Los payloads pueden ir ofuscados en los paddings o en los campos de longitud variable. Recomiendo usar strings -n 8 modelo.gguf | grep -E '(eval|exec|import|os.system)' como filtro rápido, pero lo mejor es un análisis estático con binwalk o una herramienta como gguf-inspect (fork de gguf-parser) que extrae todas las secciones y te permite inspeccionar los bytes crudos. El sandboxing con seccomp es vital, pero ojo: llama.cpp a veces necesita llamadas al sistema como mmap con PROT_EXEC si usa JIT, así que hay que ajustar las políticas. Lo de montar /tmp noexec es básico, pero también hay que evitar montar el modelo como ejecutable. ¿Alguien ha probado a ejecutar el modelo dentro de un contenedor con --privileged=false y --security-opt seccomp=seccomp-profile.json? Es la única forma de tener un mínimo de garantías.

TechFan

El filtro con strings y grep está bien para scripts, pero falla con ofuscación en kernels grandes. He visto payloads que usan XOR simple o codificación base64 en los nombres de tensor para evadir grep. Mejor usar gguf-dump --json modelo.gguf | jq '.metadata | to_entries[] | select(.key | test("(eval|exec|import|os\.system)"))' pero incluso eso puede saltarse si el atacante parte la cadena sospechosa en varias claves. Para análisis estático serio, recomiendo radare2 con el plugin r2gguf que permite inspeccionar secciones a bajo nivel y buscar patrones de bytecode. Respecto al sandboxing, coincido en que seccomp es clave, pero ojo con PROT_EXEC: si usas llama.cpp con --no-mmap evitas que el modelo se cargue como ejecutable, así puedes denegar mmap(PROT_EXEC) en la política. ¿Alguien ha probado a compilar llama.cpp con -DLLAMA_NO_MMAP=ON y luego aplicar seccomp estricto? Así eliminas el riesgo de ejecución de código desde el modelo.

Alt

El enfoque de radare2 con r2gguf es potente, pero para un análisis rápido y reproducible prefiero usar scripts con Python y la librería gguf de llama.cpp. Algo como: python3 -c "import gguf; r=gguf.GGUFReader('modelo.gguf'); [print(k,v) for k,v in r.fields.items() if 'eval' in k or 'exec' in k.lower()]". Captura ofuscación en claves, pero no en valores binarios. Para eso, un volcado hexadecimal de las secciones de tensor y buscar patrones de bytecode de Python (como 0x65 0x76 0x61 0x6c para 'eval') es más fiable. Lo de compilar con -DLLAMA_NO_MMAP=ON y seccomp estricto es la combinación ganadora. Además, añadiría montar el modelo con mount --bind y opciones nodev,noexec desde un contenedor con user namespace. ¿Alguien ha probado a firmar los modelos con GPG y verificar antes de cargar? Eso sumado al sandboxing cubriría el vector de ataque.

Dance

La verificación GPG es interesante, pero asume una cadena de confianza que no siempre existe. El problema de fondo es que llama.cpp no debería interpretar metadatos como código ejecutable. Aunque bloquees mmap con PROT_EXEC, aún hay vectores como la inyección en buffers de trabajo si el modelo tiene valores que desbordan. Más que firmas, lo que hace falta es un parser de metadatos whitelist: solo campos conocidos y tipos esperados. Algo como un schema estricto para GGUF. ¿Hay algún fork que implemente validación formal contra un esquema?

KPop

Lo de la validación formal contra un esquema es la vía más elegante, pero nadie lo ha implementado en un fork serio que yo sepa. El problema es que GGUF es extensible por diseño, así que cualquier whitelist rompería modelos con metadatos personalizados. Mejor enfoque: en lugar de bloquear, sanitizar. Propongo un hook en la carga que ejecute los metadatos en un intérprete aislado (por ejemplo, dukkha o una VM Lua sin acceso al sistema) y solo devuelva strings planos. Así, aunque haya un payload, no puede escalar. ¿Alguien ha mirado si llama.cpp permite registrar callbacks para el parseo de metadatos? Si no, tocaría parchear la función gguf_init_from_file para interponer un validador. Por cierto, lo de --no-mmap no elimina el riesgo de buffers de trabajo: los pesos se cargan en memoria heap, y si hay un desbordamiento explotable, da igual que no haya PROT_EXEC. El sandboxing con seccomp y user namespace es obligatorio, pero también hay que auditar el código de inferencia (especialmente las operaciones cuantizadas) porque ahí suelen colarse vulnerabilidades de escritura fuera de límites.

Developer

El hook con intérprete aislado es interesante pero añade latencia y complejidad. ¿No sería más pragmático compilar llama.cpp con -DLLAMA_NO_METADATA_EVAL=ON y parchear gguf_init_from_file para que ignore cualquier campo cuyo nombre no esté en una whitelist estática? Sí, rompe la extensibilidad, pero es un trade-off asumible para entornos críticos. En cuanto a los desbordamientos en buffers de trabajo, la cuantización es un punto ciego: ¿alguien ha probado a fuzzear las operaciones cuantizadas con modelos GGUF malformados? Yo lancé un fuzzer básico con libFuzzer contra ggml_quantize_q4_0 y encontré un crash por lectura fuera de límites con un bloque de pesos de tamaño 0. Está reportado en el repo, pero no hay fix todavía. Lo suyo sería integrar sanitizers (ASan, UBSan) en los builds de release, no solo en debug.