Los cargadores multifotograma de Pillow pueden reutilizar almacenamiento de imagen nativo obsoleto tras transiciones de modo

Resumen

Los cargadores de imágenes multifotograma de Pillow pueden conservar el almacenamiento nativo ImagingCore asignado para un fotograma mientras modifican el mode de imagen en el lado de Python y los mosaicos del decodificador para un fotograma posterior.

Si el fotograma 0 asigna almacenamiento para un modo estrecho como L, y un fotograma posterior con las mismas dimensiones cambia a un modo más amplio como RGB o CMYK, Pillow puede decodificar píxeles más anchos en el búfer nativo estrecho y obsoleto. Esto genera escrituras fuera de límites nativas y caídas del proceso. En la ruta MPO/JPEG, también se demostró ejecución de comandos en perfiles de tiempo de ejecución de Python/Pillow compatibles a través de la ruta documentada ImageSequence.Iterator + frame.load().

Detalles

La causa raíz radica en que ImageFile.load_prepare() solo vuelve a asignar almacenamiento nativo cuando _im is None. No verifica que el almacenamiento nativo retenido ImagingCore siga coincidiendo con self.mode y self.size.

Varias rutas multifotograma de seek() / _open() pueden actualizar self._mode y los mosaicos del decodificador para un fotograma posterior sin invalidar _im. Como resultado, el decodificador escribe o lee según el modo del nuevo fotograma mientras que el almacenamiento nativo todavía pertenece al modo del fotograma anterior.

Superficies afectadas verificadas:

1. PSD PsdImageFile.seek() puede cambiar del almacenamiento en escala de grises/nativo L a la decodificación de capas RGB conservando _im. Esto produce escrituras fuera de límites nativas controladas por el atacante y caídas reproducibles.

2. MPO/JPEG Un archivo MPO manipulado de dos fotogramas puede hacer que el fotograma 0 asigne almacenamiento L, y luego hacer que el fotograma 1 decodifique datos CMYK / RGB en el almacenamiento retenido L. La ruta documentada ImageSequence.Iterator alcanza esto con frame.load(). Se verificaron corrupción de memoria nativa, caídas, comportamiento de sobrelectura y ejecución de comandos de prueba inocuos en Pillow 12.3.0.

3. DCX DcxImageFile.seek() invoca a PcxImageFile._open(), lo que cambia el estado de modo/mosaico sin una protección de modo en el almacenamiento nativo. Un DCX manipulado con fotogramas PCX L y luego RGB produce una discrepancia en el almacenamiento retenido y una caída.

4. MIC MIC puede invocar directamente a TiffImageFile._open() y eludir el comportamiento protegido normal de TIFF seek(). Con una transición de fotograma alcanzable basada en NextIFD, esto provoca una discrepancia en el almacenamiento retenido y una caída.

TIFF sirve como un control positivo útil ya que su ruta seek() comprueba tanto el tamaño como el modo antes de reutilizar el almacenamiento.

Impacto

• Caída del proceso / denegación de servicio
• Escritura fuera de límites nativa
• Sobrelectura nativa en la ruta MPO
• Ejecución de comandos en perfiles de tiempo de ejecución coincidentes de Python/Pillow a través de la ruta MPO/JPEG

Impacto en despliegues del lado del servidor:

• En un servicio web local vulnerable que acepte cargas MPO no autenticadas y las procese automáticamente con Pillow, el ataque requiere una sola petición HTTP sin interacción del usuario posterior a la carga.
• La ejecución del marcador de salida de comando inocuo tuvo éxito 10/10 veces.
• El control _im=None fue limpio 10/10 veces.

Evidencia de Reproducción

Versión probada:

Pillow 12.3.0

Entornos de prueba en terminal MPO:

Python 3.12.3 + Pillow 12.3.0, clean PyPI environment:
marker 10/10, control 0/10

Python 3.13.14 + Pillow 12.3.0, prepared profile:
marker 10/10, control 0/10

Prueba de carga web en servidor:

control 1..10: MARKER_MISSING
control_summary ok 0 missing 10 /10

vulnerable 1..10: MARKER_OK marker_output <server-user>
vulnerable_summary ok 10 missing 0 /10

La prueba en terminal emplea únicamente un comando marcador inofensivo; no utiliza reverse shell, persistencia, exfiltración de datos ni comandos arbitrarios seleccionados por el atacante.

Se pueden proporcionar los siguientes artefactos a los mantenedores:

• Fixtures de prueba mínimos de fallo para PSD, MPO, DCX y MIC
• PoC de marcador MPO no armamentizado
• Demostración local de carga web vulnerable
• Registros de geometría gdb/GEF
• Registros de ejecuciones de control
• Propuesta de estructura para pruebas de regresión

Estructura Mínima de Reproducción

Para la ruta MPO, el patrón consumidor vulnerable es:

from io import BytesIO
from PIL import Image, ImageSequence

source = BytesIO(open(path, "rb").read())
image = Image.open(source)
iterator = ImageSequence.Iterator(image)
next(iterator).load()
next(iterator).load()

El formato de la imagen manipulada es:

frame 0: mode L, dimensions W x H
frame 1: same W x H, wider mode such as CMYK

El fotograma 0 asigna almacenamiento nativo L. El fotograma 1 cambia el modo lógico y el estado del decodificador, pero puede reutilizar el almacenamiento nativo anterior. El decodificador del fotograma 1 escribe utilizando el modo más ancho en el almacenamiento estrecho.

Dirección de Corrección Sugerida

Antes de reutilizar el almacenamiento nativo ImagingCore, Pillow debería verificar que dicho almacenamiento sea compatible con el modo lógico y el tamaño actuales de la imagen.

Una protección central en ImageFile.load_prepare() podría comparar el modo y tamaño del almacenamiento nativo frente a self.mode / self.size y asignar nuevo almacenamiento si difieren. Como alternativa, cada ruta de cambio de modo en seek() / _open() debería invalidar explícitamente _im antes de la decodificación.

Precaución: TIFF tiene un comportamiento especializado en el tamaño de mosaicos y ya cuenta con una protección de modo/tamaño, por lo que una corrección central debe evitar regresiones en el manejo del búfer de mosaicos de TIFF.

Créditos

Rotem Kama

Nota Metodológica

Se utilizó análisis asistido por IA para el descubrimiento y el soporte de verificación. Las afirmaciones de este informe se limitan a los artefactos locales, controles y salidas de comandos descritos anteriormente.