Pillow-Mehrbild-Loader können nach Moduswechseln veralteten nativen Bildspeicher wiederverwenden

Zusammenfassung

Mehrbild-Bild-Loader in Pillow können den nativen Speicher ImagingCore, der für ein Frame reserviert wurde, beibehalten, während das Python-seitige Bild-mode und die Decoder-Kacheln für ein nachfolgendes Frame geändert werden.

Wenn Frame 0 Speicher für einen schmaleren Modus wie L reserviert und ein nachfolgendes Frame mit denselben Abmessungen zu einem breiteren Modus wie RGB oder CMYK wechselt, dekodiert Pillow möglicherweise breitere Pixel in den veralteten schmaleren nativen Puffer. Dies verursacht native Out-of-bounds-Schreibvorgänge und Prozessabstürze. Im MPO/JPEG-Pfad wurde zudem eine Befehlsausführung in passenden Python/Pillow-Laufzeitprofilen über den dokumentierten Pfad ImageSequence.Iterator + frame.load() nachgewiesen.

Details

Die Ursache liegt offenbar darin, dass ImageFile.load_prepare() den nativen Speicher nur neu zuweist, wenn _im is None. Es wird nicht überprüft, ob der beibehaltene native Speicher ImagingCore weiterhin mit self.mode und self.size übereinstimmt.

Mehrere Mehrbild-Pfade von seek() / _open() können self._mode und die Decoder-Kacheln für ein späteres Frame aktualisieren, ohne _im zu invalidieren. Der Decoder schreibt oder liest dann entsprechend dem neuen Frame-Modus, während der native Speicher noch dem vorherigen Frame-Modus zugeordnet ist.

Verifizierte betroffene Angriffsflächen:

1. PSD PsdImageFile.seek() kann von Graustufen/nativem L-Speicher zur RGB-Ebenendekodierung wechseln, während _im beibehalten wird. Dies führt zu angreifergesteuerten nativen Out-of-bounds-Schreibvorgängen und zuverlässigen Abstürzen.

2. MPO/JPEG Eine manipulierte Zwei-Frame-MPO-Datei kann dazu führen, dass Frame 0 Speicher für L reserviert und anschließend Frame 1 Daten vom Typ CMYK / RGB in den beibehaltenen L-Speicher dekodiert. Der dokumentierte Pfad ImageSequence.Iterator erreicht dies über frame.load(). Verifiziert wurden native Speicherbeschädigung, Abstürze, Over-Read-Verhalten sowie eine abgegrenzte Marker-Befehlsausführung unter Pillow 12.3.0.

3. DCX DcxImageFile.seek() ruft PcxImageFile._open() auf, was den Modus-/Kachelstatus ohne Prüfung des nativen Speichermodus ändert. Ein manipuliertes DCX mit L- und anschließend RGB-PCX-Frames führt zu einer Nichtübereinstimmung des beibehaltenen Speichers und zum Absturz.

4. MIC MIC kann TiffImageFile._open() direkt aufrufen und das normale abgesicherte seek()-Verhalten von TIFF umgehen. Bei einem erreichbaren Frame-Übergang auf Basis von NextIFD führt dies zu einer Nichtübereinstimmung des Speichers und zum Absturz.

TIFF stellt eine nützliche Positivkontrolle dar, da der Pfad seek() sowohl Größe als auch Modus vor der Wiederverwendung des Speichers überprüft.

Auswirkungen

• Prozessabsturz / Denial of Service
• Nativer Out-of-bounds-Schreibvorgang
• Nativer Over-Read im MPO-Pfad
• Befehlsausführung in kompatiblen Python/Pillow-Laufzeitumgebungen über den MPO/JPEG-Pfad

Auswirkungen im Serverbetrieb:

• In einem lokalen anfälligen Web-Upload-Dienst, der nicht authentifizierte MPO-Uploads annimmt und automatisch mit Pillow verarbeitet, genügt eine einzelne HTTP-Anfrage ohne weitere Benutzerinteraktion.
• Der feste Marker zur Befehlsausgabe war in 10 von 10 Fällen erfolgreich.
• Der Kontrolllauf _im=None blieb in 10 von 10 Fällen unauffällig.

Reproduktionsbelege

Getestete Version:

Pillow 12.3.0

MPO-Terminal-Prüfumgebungen:

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

Server-Web-Upload-Nachweis:

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

Der Terminalnachweis verwendet ausschließlich einen festen, harmlosen Marker-Befehl und keine Reverse-Shell, Persistenz, Datenexfiltration oder frei wählbare Befehle.

Folgende Artefakte können Maintainern bereitgestellt werden:

• Minimale Crash-Fixtures für PSD, MPO, DCX und MIC
• Nicht waffenfähiger MPO-Marker-PoC
• Lokale anfällige Web-Upload-Demo
• gdb/GEF-Geometriebelege
• Kontrolllauf-Protokolle
• Vorgeschlagene Regressionstest-Struktur

Minimale Reproduktionsstruktur

Für den MPO-Pfad lautet die verwundbare Struktur:

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()

Die manipulierte Bildstruktur:

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

Frame 0 reserviert nativen Speicher für L. Frame 1 ändert den logischen Modus und den Decoder-Status, kann jedoch den alten nativen Speicher wiederverwenden. Der Decoder für Frame 1 schreibt dann mit dem breiteren Modus in den schmaleren Speicher.

Lösungsvorschlag

Vor der Wiederverwendung des nativen Speichers ImagingCore sollte Pillow überprüfen, ob der beibehaltene Speicher mit dem aktuellen logischen Bildmodus und der Bildgröße kompatibel ist.

Eine zentrale Prüfung in ImageFile.load_prepare() könnte Modus und Größe des nativen Speichers mit self.mode / self.size vergleichen und neuen Speicher zuweisen, wenn Abweichungen vorliegen. Alternativ sollte jeder modusändernde Pfad von seek() / _open() den Speicher _im vor der Dekodierung explizit invalidieren.

Hinweis: TIFF verfügt über ein spezialisiertes Verhalten bezüglich Kachelgrößen und besitzt bereits eine Modus-/Größenprüfung; ein zentraler Fix sollte dieses Verhalten nicht beeinträchtigen.

Danksagung

Rotem Kama

Hinweis zur Methodik

Für die Entdeckung und Verifizierung wurde KI-gestützte Analyse eingesetzt. Die Angaben in diesem Bericht beschränken sich auf die oben genannten Artefakte, Kontrollen und Befehlsausgaben.