Un desbordamiento en el decodificador EXR de Apple abre la puerta a un exploit de cero clics
El fallo está en libAppleEXR, detrás de ImageIO: se reserva espacio para tres canales por píxel y se escriben cuatro. El autor dice dispararlo desde un iMessage, sin tocar nada.
El decodificador de OpenEXR que Apple incluye en libAppleEXR.dylib, colgado de ImageIO, escribe cuatro canales por píxel en un búfer dimensionado para tres. Son cuatro bytes de más por cada píxel de la imagen, acumulados fila tras fila, y quien firma el análisis asegura que eso basta para ejecutar código dentro de un daemon privilegiado en cuanto llega un iMessage, antes de que la notificación termine de aparecer. Sin tocar la pantalla.
La mecánica es tan simple que da un poco de vergüenza ajena. El asignador recibe channels * sizeof(float) con tres canales: 12 bytes por píxel, rojo, verde y azul en coma flotante de 32 bits. Después entra una rutina de intercalado que emite R, G, B y un alfa constante de 1.0, 16 bytes por píxel. Doce reservados, dieciséis escritos, siempre, para toda la imagen. A 448 por 448 píxeles son unos 800 kilobytes volcados justo después de una reserva de tamaño parecido, encima de lo que el asignador hubiera colocado ahí.
Lo que convierte el fallo en algo aprovechable es de dónde salen esos bytes. Doce de cada dieciséis son los valores de color que vienen dentro del propio fichero, es decir, datos que elige quien lo envía. Solo el canal alfa es fijo: un float 1.0, 0x3f800000 en memoria. El desbordamiento no es ruido, es contenido dirigido.
De dónde salió el bug
El autor no llegó a esto auditando EXR a mano. Su montaje se apoya en fuzzing guiado por modelos: en lugar de lanzar bytes aleatorios contra el parser, hace que un LLM lea el desensamblado de la función objetivo, identifique qué campos se está creyendo y proponga mutaciones que mantienen el fichero estructuralmente válido mientras fuerzan los contadores y los tamaños por los que ramifica el código. Con un formato como EXR el fuzzing a ciegas no sirve de nada, porque el decodificador rechaza el fichero en los primeros cien bytes y nunca se llega a la parte interesante. El primer hallazgo, según cuenta, ni siquiera fue un crash: fue la incoherencia entre el tamaño reservado y el escrito, visible solo leyendo el código.
El peso del asunto está en dónde vive ese decodificador. Apple distribuye el suyo para OpenEXR y lo conecta a ImageIO, el embudo por el que pasa casi cualquier imagen que el sistema abre. Si EXR se decodifica ahí, se decodifica en cualquier sitio donde se pida abrir una imagen, y muchos de esos sitios corren en procesos con más privilegios que la app que recibió el fichero. El autor sostiene que BlastDoor, el sandbox con el que Apple procesa los adjuntos de Mensajes, no lo detiene.
Lo que no dice
No hay CVE en el texto, ni confirmación de Apple, ni parche anunciado, ni demo pública. El autor afirma haberlo reproducido en un iPad real y haber pasado de «esto peta» a controlar los bytes escritos, pero el texto se corta antes de la cronología de divulgación, así que no se sabe en qué estado quedó la cosa con Cupertino.
Para quien administra flotas de dispositivos Apple, la lección es la de siempre y por eso conviene repetirla: la superficie real de estos equipos no son las apps que se abren, sino los decodificadores que trabajan solos. Un formato de imagen con todas las de perder por su complejidad, metido en el camino crítico de cualquier fichero entrante, es un objetivo de primer nivel. Habrá que seguir los parches de ImageIO con atención.
