Codex hackeó un televisor Samsung

Esta publicación documenta nuestra investigación sobre el uso de IA para piratear dispositivos de hardware. Nos gustaría agradecer a OpenAI por asociarse con nosotros en este proyecto.

Ningún televisor resultó gravemente dañado durante esta investigación. Es posible que uno haya experimentado una leve angustia al ser reiniciado repetidamente de forma remota por una IA.

Comenzamos con un shell dentro de la aplicación del navegador en un televisor Samsung y una pregunta bastante simple: si le diéramos a Codex una forma confiable de trabajar con el dispositivo en vivo y la fuente de firmware correspondiente, ¿podría afianzarse hasta llegar a la raíz?

Codex tuvo que enumerar el objetivo, reducir la superficie de ataque alcanzable, auditar la fuente del controlador del proveedor correspondiente, validar una primitiva de memoria física en el dispositivo activo, adaptar sus herramientas a las restricciones de ejecución de Samsung e iterar hasta que el proceso del navegador se convirtiera en raíz en un dispositivo realmente comprometido.

No proporcionamos ningún error ni una receta para explotarlo. Proporcionamos un entorno en el que Codex realmente podría operar, y la forma más sencilla de entenderlo es mirar las piezas por separado.

KantS2 es el nombre de plataforma interna de Samsung para el firmware de Smart TV utilizado en este modelo de dispositivo.

La configuración se veía así:

• [1] Punto de apoyo del navegador: ya teníamos la ejecución de código dentro del propio contexto de seguridad de la aplicación del navegador en el televisor, lo que significaba que la tarea no era “obtener la ejecución del código de alguna manera” sino “convertir la ejecución del código de la aplicación del navegador en raíz”.

• [2] Anfitrión del controlador: Teníamos una máquina separada que podía crear archivos binarios ARM, alojar archivos a través de HTTP y acceder a la sesión de shell que realmente estaba activa en el televisor.

• [3] Oyente de shell: el proyectil objetivo fue atravesado tmux send-keyslo que significó que Codex tuvo que inyectar comandos en un shell que ya se estaba ejecutando y luego recuperar los resultados de los registros en lugar de tratar el televisor como una nueva terminal interactiva.

• [4] Versión de fuente coincidente: tuvimos el KantS2 árbol de fuentes para la familia de firmware correspondiente, que permite a Codex auditar el código del controlador del kernel de Samsung y luego probar esos hallazgos en el dispositivo en vivo.

• [5] Restricciones de ejecución: el objetivo requería archivos binarios ARMv7 estáticos y los programas no firmados no podían ejecutarse simplemente desde el disco debido a la Prevención de ejecución no autorizada (UEP) de Samsung Tizen.

• [6] memfd envoltura: Para solucionar UEP, ya teníamos un asistente que cargaba un programa en un descriptor de archivo anónimo en memoria y lo ejecutaba desde la memoria en lugar de desde una ruta de archivo normal.

Con esa configuración, el ciclo de Codex era simple: inspeccionar los registros de origen y de sesión, enviar comandos al televisor a través del controlador y el tmux-shell impulsado, leer los resultados de los registros y, cuando se necesitara un ayudante, compilarlo en el controlador, hacer que el televisor lo busque y lo ejecute memfd. Unas breves indicaciones hicieron explícito ese bucle operativo:

El mensaje inicial fue intencionalmente amplio:

Fijamos el destino y dejamos la ruta abierta. No señalamos a Codex un controlador, ni sugerimos memoria física ni mencionamos las credenciales del kernel, por lo que tuvo que tratar la sesión como una búsqueda real de escalada de privilegios en lugar de un ejercicio de confirmación.

El segundo mensaje redujo el estándar:

Subimos el listón: el error tenía que existir en la fuente, estar presente en el dispositivo y ser accesible desde el shell del navegador. La producción del Codex rápidamente se redujo a candidatos concretos.

Luego le presentamos al Codex los hechos que sustentarían el resto de la sesión:

Ese paquete hizo la mayor parte del trabajo de encuadre. La identidad del navegador definió el límite de privilegios y luego pasó a formar parte de la firma que Codex utilizó para reconocer las credenciales del núcleo del proceso del navegador en la memoria. La versión del kernel redujo la base del código, los nodos del dispositivo definieron las interfaces accesibles y /p​roc/cmdline Posteriormente proporcionó sugerencias sobre el diseño de la memoria para el escaneo físico.

Codex rápidamente se centró en un conjunto de nodos de dispositivos ntk* con capacidad de escritura mundial expuestos al shell del navegador:

Codex se centró en esa familia de controladores porque estaba cargado en el dispositivo, era accesible desde el shell del navegador y estaba presente en el árbol de fuentes publicado. leyendo el emparejamiento ntkdriver Fuentes es también donde el vínculo de Novatek quedó claro: el árbol está estampado con identificadores de Novatek Microelectronics, por lo que estos ntk* Las interfaces no eran solo nombres opacos de dispositivos en el televisor, sino parte de la pila de Novatek que Samsung había enviado. Eso dio a la sesión una dirección concreta.

En un momento tuvimos que darle a Codex una restricción que fácilmente podría haber descarrilado la sesión:

/proc/iomem Es uno de los lugares normales para razonar sobre el diseño de la memoria física, por lo que perderla era importante. Codex respondió recurriendo a otra fuente de verdad: /p​roc/cmdline:

Esos parámetros de arranque fueron suficientes para reconstruir las ventanas principales de RAM para el análisis posterior.

Con el campo reducido a ntksys y ntkhdmaCodex auditó la correspondencia KantS2 fuente y encontré la primitiva que hizo posible el resto de la sesión.

/dev/ntksys era una interfaz de controlador de kernel de Samsung que aceptaba una dirección física y un tamaño del espacio de usuario, almacenaba esos valores en una tabla y luego asignaba esa memoria física nuevamente al espacio de direcciones de la persona que llama a través de mmap. Eso es lo que entendemos aquí por un physmap primitivo: una ruta que le da al usuario acceso al espacio de la memoria física sin procesar. La consecuencia operativa fue sencilla. Si el shell del navegador pudiera usar ntksys De esta manera, Codex no necesitaría un truco de ejecución de código del kernel. Sólo necesitaría una estructura de datos del kernel confiable para sobrescribir.

A partir de ahí, el camino ya no era un exploit de flujo de control del kernel, sino una escalada de datos basada únicamente en el acceso a la memoria física.

La regla de envío udev otorga acceso de escritura mundial a /dev/ntksys:

Fuente: sources/20_DTV_KantS2/tztv-media-kants/99-tztv-media-kants.rules

Esto ya es un grave error de diseño porque ntksys no es una interfaz de metadatos benigna. Es una interfaz de gestión de memoria.

La interfaz del controlador se basa en ST_SYS_MEM_INFO:

Fuente: ker_sys.h

u32Start y u32Size provienen directamente del espacio del usuario. Esos son los dos únicos valores que un atacante necesita para convertir esta interfaz en un mapa físico sin formato.

La ruta de escritura crítica está en ker_sys.c alrededor de la línea 1158:

El controlador comprueba si el índice de la tabla es válido. No comprueba si el rango físico solicitado pertenece a un búfer propiedad del kernel, si se superpone a la RAM, si cruza regiones privilegiadas o si a la persona que llama se le debe permitir asignarlo.

La ruta del mapa correspondiente está en ker_sys.c alrededor de la línea 1539:

vma->vm_pgoff selecciona la ranura y el contenido de la ranura está controlado por el atacante. Luego, el conductor pasa el PFN elegido por el usuario directamente a vk_remap_pfn_range. En ese momento, el núcleo ya no impone la separación de privilegios para la memoria física.

/dev/ntkhdma proporciona una primitiva de apoyo útil:

Fuente: ker_hdma.c

Este no es el principal error de escalada de privilegios, pero es útil desde el punto de vista operativo. Le entrega al código sin privilegios una dirección física conocida que se puede asignar a través de ntksys para probar los trabajos primitivos antes de tocar la RAM arbitraria.

El Codex no pasó directamente de la auditoría del origen a la explotación final. Construyó una cadena de pruebas por etapas.

Primero escribió un pequeño ayudante con quien hablar. /dev/ntkhdma y solicite la dirección física del búfer DMA (acceso directo a memoria) del dispositivo. Un búfer DMA es la memoria que el controlador utiliza para el acceso directo al hardware, y el punto clave aquí no era el DMA en sí, sino el hecho de que el controlador estaba dispuesto a entregarle a un proceso sin privilegios una dirección física real. El primer éxito conservado tenía este aspecto:

Eso le dio al Codex una página física segura y en buen estado para realizar pruebas. Luego escribió a un segundo ayudante para responder a la pregunta más peligrosa: si registró esa dirección física a través de ntksys¿podría realmente asignar la página al espacio del usuario y leerla o escribirla desde el shell del navegador? La respuesta fue sí:

Antes de ese resultado, el problema todavía era una teoría respaldada por las fuentes; Después, Codex había demostrado que un proceso sin privilegios en la televisión podía leer y escribir una página física elegida. La pregunta restante era qué objeto del kernel corromper.

La hazaña no vino de nosotros. Nunca le dijimos al Codex que parcheara crednunca explicó qué cred lo era, y nunca señaló que el proceso del navegador uid=5001 y gid=100 haría un patrón reconocible en la memoria.

Esa elección se derivaba directamente de la primitiva que ya había demostrado.

Para cualquiera que no dedique tiempo a los aspectos internos de Linux, cred es la estructura del núcleo que almacena las identidades de un proceso: ID de usuario, ID de grupo y campos de credenciales relacionados. Si puedes sobrescribir el derecho credpuedes cambiar quién cree el kernel que es el proceso. Una vez que Codex tuvo acceso arbitrario a la memoria física, el plan restante se volvió sencillo: escanear las ventanas de RAM recuperadas de /p​roc/cmdlinebusque el patrón de credenciales del proceso del navegador, ponga a cero los campos de identidad y luego inicie un shell.

El live shell le había dado a Codex los valores de identidad, la auditoría del código fuente le había dado la primitiva, los primeros ayudantes habían demostrado esa primitiva, y el exploit final conectó esas piezas sin necesidad de ningún truco elaborado de control de flujo del kernel.

Cuando llegamos al tramo final, las partes difíciles ya estaban en su lugar. Teníamos la superficie, la primitiva, la ruta de implementación y el exploit. El último mensaje humano fue:

Codex empujó la cadena final a través de la ruta del controlador, hizo que el televisor la buscara, la pasó por el contenedor en memoria y esperó el resultado. El resultado fue:

El primer reconocimiento conservado del Codex fue:

En ese punto, la cadena ya había pasado por la selección de superficie, auditoría de origen, validación en vivo, desarrollo de PoC, manejo de compilación específica de destino, implementación remota y ejecución bajo memfddepuración iterativa y, finalmente, la sobrescritura de credenciales que convirtió el shell del navegador en root.

Mientras conducíamos al Codex hasta su destino final, definitivamente estuvo a punto de desviarnos si no lo desviábamos inmediatamente. Estas son algunas de esas interacciones reales:

Sinceramente, esto lo hace aún más realista de lo que pensábamos. En ocasiones, fue un éxito puntual y, en otras, realmente es necesario crear esa interacción real con Codex. ¡Esto no podría haberse completado si lo hubiéramos tratado como una máquina desalmada que busca errores y explota el desarrollo!

Lo que hizo que valiera la pena documentar la sesión fue la forma del bucle en sí. Configuramos una ruta de control en un televisor comprometido, le dimos el árbol fuente correspondiente y una manera de construir y preparar el código, y desde allí el trabajo se convirtió en un ciclo repetido de inspección, prueba, ajuste y repetición hasta que el navegador se convirtió en raíz en el dispositivo.

Este experimento es parte de un ejercicio más amplio. Codex no obtuvo mágicamente el shell del navegador. Ya habíamos explotado el dispositivo para conseguir ese punto de apoyo inicial. El objetivo aquí era más limitado: dada una posición realista post-explotación, ¿podría la IA llegar hasta el final?

El siguiente paso es obvio (y un poco preocupante): dejar que la IA haga todo de principio a fin. Con suerte, permanecerá atrapado dentro de la televisión para siempre, aumentando silenciosamente sus privilegios y viendo nuestras comedias.

redacción y PoC: https://github.com/califio/publications/blob/main/MADBugs/samsung-tv/.

—dp