OpenEXR corrige 15 vulnerabilidades en la lectura de archivos EXR

Los desarrolladores de la biblioteca OpenEXR publicaron el 31 de octubre la versión de parches 3.5.3. Corrige 15 vulnerabilidades, de las cuales 10 están pendientes de recibir números CVE. Casi todas se activan al leer un archivo EXR dañado o preparado a propósito: son desbordamientos de búfer y escrituras fuera de la memoria asignada. Según los autores del lanzamiento, varios de esos errores permitían ejecutar código de forma remota.

Para los estudios es un riesgo concreto. Las secuencias EXR llegan de proveedores externos, de clientes, de archivos ajenos y de servicios de intercambio de ficheros, y por norma general se abren sin ninguna comprobación aparte. Para que el ataque funcione no hay que ejecutar el archivo: basta con que un programa basado en una versión vulnerable de OpenEXR intente leerlo. El mismo día, poco antes de la 3.5.3, salió la versión 3.4.17 para la rama anterior. Corrige nueve de esas vulnerabilidades, las que afectan a la rama 3.4, por lo que los usuarios de 3.4 pueden actualizar sin pasar a la 3.5.

Dónde estaban los errores

La lista de correcciones abarca casi todas las vías por las que un EXR llega a la memoria:

• compresión DWAA/DWAB: cinco puntos, incluida una escritura fuera de los límites de memoria en el decodificador, una fuga de datos no inicializados cuando el flujo comprimido es corto y un acceso a puntero nulo con canales submuestreados;
• compresión B44: un desbordamiento al calcular el tamaño del bloque descomprimido, que los autores marcan expresamente como posibilidad de ejecución remota de código, y un error en el codificador con submuestreo;
• imágenes deep: dos errores al descomprimir datos deep comprimidos con ZSTD y un desbordamiento al volver a guardar archivos deep en mosaico. Lo último, según la valoración de los desarrolladores, puede ser consecuencia de una corrección incompleta de un error antiguo;
• HTJ2K: un acceso incorrecto a memoria durante la decodificación;
• archivos multiparte (multipart): un encabezado sin límites de tamaño podía hacer que el programa lo analizara con un coste cuadrático de tiempo y recursos;
• módulo Python de OpenEXR: un desbordamiento de búfer cuando coinciden los nombres de dos grupos de canales RGB y una escritura en un desplazamiento elegido por el atacante en la interfaz obsoleta de lectura de canales;
• atributos del encabezado: un acceso a memoria ya liberada si el nombre de un canal supera los 31 bytes y un desbordamiento por una lista adicional de canales sin comprobar.

El error que los desarrolladores vinculan expresamente con la ejecución remota de código lo describen así en las notas del lanzamiento:

«Escritura fuera de los límites del heap por un desbordamiento de entero al calcular el tamaño descomprimido de un bloque B44: ejecución remota de código en OpenEXRCore».

En la 3.5.3 no hay funciones nuevas ni otros cambios de comportamiento, salvo la corrección de una regresión con las imágenes deep (se detalla más abajo). El usuario puede notar algo más: la biblioteca comprueba ahora con mayor rigor los datos de entrada y rechaza los archivos incorrectos. Todo el conjunto de pruebas pasa ya sin errores bajo comprobaciones de depuración que detectan fallos de manejo de memoria, comportamiento indefinido y condiciones de carrera entre hilos. La relación completa de cambios está en el archivo CHANGES.md.

Qué más incluye el lanzamiento

• Lectura de imágenes deep en sistemas big-endian. Desde la versión 3.4.14, en esas máquinas la biblioteca obtenía una tabla de recuento de muestras incorrecta por un error de orden de bytes. Los sistemas little-endian no estaban afectados. Esta corrección también está en la 3.4.17.
• Compatibilidad con Python 3.15 para quienes escriben scripts de pipeline en un intérprete reciente.
• Las utilidades exrmetrics, exrmultipart y exrcheck recibieron correcciones de diagnóstico y de corrección, igual que las vías principales de descompresión. El autor de estos arreglos es Alex Khal.
• Plataformas. Se han corregido errores antiguos de compilación y de pruebas en Linux de 32 bits (i686) y s390x, problemas de compilación en macOS anterior a 10.15 y powerpc, así como el arranque en Windows 7.

Quién debe actualizar y con cuánta urgencia

A juzgar por la composición de las vulnerabilidades, la mayor parte de los problemas está en código que existe desde hace mucho. De los 15 puntos, solo dos están relacionados con la compresión ZSTD, que apareció en la línea 3.5 junto con el lanzamiento de 3.5.0 en septiembre; su mayor ventaja entonces se daba en los datos deep, donde los archivos resultaban entre un 20 y un 30 % más pequeños que con ZIPS. Los demás errores afectan a DWA, B44, archivos deep en mosaico, el análisis de encabezados y el módulo de Python. Por eso renunciar a los nuevos formatos de compresión probablemente aporta poco: también era vulnerable la parte de la biblioteca por la que pasan desde hace tiempo los renders y el composición.

La regresión con las imágenes deep afecta a un círculo reducido de máquinas. Las estaciones de trabajo habituales con x86 y ARM funcionan en little-endian y no la notaban. Esta corrección es más importante para quienes compilan OpenEXR para hardware de servidor y más inusual.

La mayoría de los artistas no instalan OpenEXR directamente: la biblioteca la integran en sus propias compilaciones los desarrolladores de paquetes DCC, programas de composición, motores de render y visores. La corrección llegará a los puestos de trabajo cuando esos proveedores publiquen actualizaciones; en los materiales del lanzamiento no se indican plazos. Pueden actuar por su cuenta los TD de pipeline y los estudios que tienen herramientas propias basadas en el módulo Python de OpenEXR o compilaciones propias de la biblioteca. A ellos les conviene pasar a 3.5.3 o 3.4.17 en primer lugar, sobre todo si esas herramientas procesan archivos de fuentes externas.

¿De dónde le llegan con más frecuencia los archivos EXR ajenos?

• De proveedores externos
• De clientes