OpenEXR schließt 15 Sicherheitslücken beim Lesen von EXR-Dateien

Soft

Die Entwickler der Bibliothek OpenEXR haben am 31. Oktober das Patch-Release 3.5.3 veröffentlicht. Es schließt 15 Sicherheitslücken, von denen 10 noch auf die Zuweisung von CVE-Nummern warten. Fast alle werden beim Lesen einer beschädigten oder speziell vorbereiteten EXR-Datei ausgelöst: Es handelt sich um Pufferüberläufe und Schreibvorgänge außerhalb des zugewiesenen Speichers. Nach Angaben der Autoren des Releases erlaubten mehrere dieser Fehler die Ausführung von Code aus der Ferne.

Für Studios ist das ein konkretes Risiko. EXR-Sequenzen kommen von Outsourcern, von Kunden, aus fremden Archiven und von Filehostern, und sie werden in der Regel ohne eigene Prüfung geöffnet. Damit ein Angriff funktioniert, muss die Datei nicht gestartet werden: Es genügt, dass ein Programm auf Basis einer anfälligen OpenEXR-Version versucht, sie zu lesen. Am selben Tag, kurz vor 3.5.3, erschien die Version 3.4.17 für den vorherigen Zweig. Sie schließt neun dieser Sicherheitslücken, die den Zweig 3.4 betreffen, sodass Nutzer von 3.4 aktualisieren können, ohne auf 3.5 umzusteigen.

Wo die Fehler lagen

Die Liste der Korrekturen umfasst nahezu alle Wege, über die eine EXR-Datei in den Speicher gelangt:

Kompression DWAA/DWAB: fünf Punkte, darunter ein Schreibvorgang außerhalb des Speichers im Decoder, ein Leck nicht initialisierter Daten bei einem zu kurzen komprimierten Datenstrom und ein Zugriff auf einen Nullzeiger bei subgesampelten Kanälen;
Kompression B44: ein Überlauf bei der Berechnung der Größe des entpackten Blocks, den die Autoren ausdrücklich als Möglichkeit zur Codeausführung aus der Ferne markieren, sowie ein Fehler im Encoder beim Subsampling;
Deep-Bilder: zwei Fehler beim Entpacken von mit ZSTD komprimierten Deep-Daten und ein Überlauf beim erneuten Speichern von Tiled-Deep-Dateien. Letzteres kann nach Einschätzung der Entwickler die Folge einer unvollständigen Korrektur eines alten Fehlers sein;
HTJ2K: ein fehlerhafter Speicherzugriff beim Decodieren;
Multipart-Dateien: Ein Header ohne Größenbeschränkungen konnte ein Programm dazu bringen, ihn mit quadratisch steigendem Zeit- und Ressourcenaufwand zu zerlegen;
Python-Modul OpenEXR: ein Pufferüberlauf bei Namensgleichheit zweier RGB-Kanalgruppen und ein Schreibvorgang an einem vom Angreifer gewählten Offset in der veralteten Schnittstelle zum Lesen von Kanälen;
Header-Attribute: ein Zugriff auf bereits freigegebenen Speicher, wenn ein Kanalname länger als 31 Byte ist, und ein Überlauf durch eine ungeprüfte zusätzliche Kanalliste.

Den Fehler, den die Entwickler ausdrücklich mit Codeausführung aus der Ferne verbinden, beschreiben sie in den Release Notes so:

«Schreibvorgang außerhalb des Heaps aufgrund eines Integer-Überlaufs bei der Berechnung der entpackten Größe eines B44-Blocks — Codeausführung aus der Ferne in OpenEXRCore».

Neue Funktionen oder andere Verhaltensänderungen gibt es in 3.5.3 nicht, abgesehen von der Korrektur einer Regression bei Deep-Bildern (dazu unten mehr). Eine weitere Änderung kann Nutzern auffallen: Die Bibliothek prüft Eingabedaten nun strenger und weist fehlerhafte Dateien zurück. Die gesamte Testsuite läuft jetzt fehlerfrei unter Debug-Prüfungen durch, die Speicherfehler, undefiniertes Verhalten und Thread-Races aufspüren. Die vollständige Liste der Änderungen liegt in der Datei CHANGES.md.

Was außerdem im Release enthalten ist

Lesen von Deep-Bildern auf Big-Endian-Systemen. Seit Version 3.4.14 erhielt die Bibliothek auf solchen Maschinen aufgrund eines Fehlers in der Byte-Reihenfolge eine falsche Tabelle der Sample-Anzahlen. Little-Endian-Systeme waren von dem Fehler nicht betroffen. Diese Korrektur ist auch in 3.4.17 enthalten.
Unterstützung für Python 3.15 für alle, die Pipeline-Skripte mit einem aktuellen Interpreter schreiben.
Die Werkzeuge exrmetrics, exrmultipart und exrcheck haben Korrekturen bei Diagnose und Korrektheit erhalten, ebenso die zentralen Entpackpfade. Autor dieser Korrekturen ist Alex Khal.
Plattformen. Behoben wurden langjährige Build- und Testfehler unter 32-Bit-Linux (i686) und s390x, Build-Probleme unter macOS vor 10.15 und auf powerpc sowie der Start unter Windows 7.

Wer wie dringend aktualisieren sollte

Der Zusammensetzung der Sicherheitslücken nach steckt der Großteil der Probleme in lange bestehendem Code. Von 15 Punkten hängen nur zwei mit der ZSTD-Kompression zusammen, die in der Linie 3.5 mit dem Release 3.5.0 im September eingeführt wurde; den größten Gewinn brachte sie damals bei Deep-Daten, wo die Dateien 20–30 % kleiner ausfielen als mit ZIPS. Die übrigen Fehler betreffen DWA, B44, Tiled-Deep-Dateien, das Parsen von Headern und das Python-Modul. Ein Verzicht auf die neuen Kompressionsformate bringt daher wahrscheinlich wenig: Anfällig war auch jener Teil der Bibliothek, durch den seit langem Renderings und Compositings laufen.

Die Regression bei Deep-Bildern betrifft einen engen Kreis von Maschinen. Typische Workstations auf x86 und ARM arbeiten in Little-Endian und haben sie nicht bemerkt. Diese Korrektur ist wichtiger für alle, die OpenEXR für Server- und seltenere Hardware bauen.

Die meisten Artists installieren OpenEXR nicht direkt: Die Bibliothek wird von den Entwicklern von DCC-Paketen, Compositing-Programmen, Renderern und Viewern in deren eigene Builds eingebettet. An den Arbeitsplätzen kommt die Korrektur an, wenn diese Anbieter Updates veröffentlichen; Termine werden in den Release-Materialien nicht genannt. Selbst handeln können Pipeline-TDs und Studios, die eigene Werkzeuge auf Basis des Python-Moduls von OpenEXR oder eigene Builds der Bibliothek haben. Für sie ist ein Wechsel auf 3.5.3 oder 3.4.17 vorrangig sinnvoll, besonders wenn die Werkzeuge Dateien aus externen Quellen verarbeiten.

Woher kommen fremde EXR-Dateien bei Ihnen am häufigsten?