Podatności OpenEXR

W OpenEXR 2.2.0, specjalnie przygotowany obraz powoduje nadmierne odczytywanie bufora w funkcji hufDecode w pliku IlmImf/ImfHuf.cpp podczas wykonywania exrmaketiled. Może to prowadzić do odmowy usługi lub innych nieokreślonych skutków.

W OpenEXR 2.2.0 występuje nieprawidłowe zapisanie danych o rozmiarze 2 w funkcji operatora = w pliku half.h, co może prowadzić do awarii aplikacji lub wykonania dowolnego kodu.

W OpenEXR 2.2.0 występuje nieprawidłowe zapisanie danych o rozmiarze 1 w funkcji bufferedReadPixels w pliku ImfInputFile.cpp, co może prowadzić do awarii aplikacji lub wykonania dowolnego kodu.

W OpenEXR 2.2.0 występuje nieprawidłowe zapisanie danych o rozmiarze 8 w funkcji storeSSE w pliku ImfOptimizedPixelReading.h, co może prowadzić do awarii aplikacji lub wykonania dowolnego kodu.

OpenEXR w wersjach od 3.0.0 do przed 3.2.9, 3.3.0 do przed 3.3.11 oraz 3.4.0 do przed 3.4.11 ma problem z funkcją readVariableLengthInteger(), która dekoduje zmienną długość liczby całkowitej z niezaufanego wejścia EXR bez ograniczenia liczby przesunięć. Po wystarczającej liczbie bajtów kontynuacji, kod wykonuje przesunięcie w lewo o 70 na 64-bitowej wartości, co prowadzi do nieokreślonego zachowania.

W bibliotece OpenEXR w wersjach od 3.0.0 do 3.2.9, od 3.3.0 do 3.3.11 oraz od 3.4.0 do 3.4.11 wykryto podatność w funkcji IDManifest::init(). Podczas rekonstrukcji ciągów znaków z reprezentacji skompresowanej prefiksowo, kod odczytuje bajty bez sprawdzenia, czy bieżący ciąg ma co najmniej dwa bajty, co może prowadzić do odczytu poza zakresem.

OpenEXR 3.4.14 zawiera podatność na dereferencję pustego wskaźnika w ścieżce parsowania atrybutów C++. Specjalnie spreparowany plik EXR zawierający atrybut nieznanego typu z dataSize ustawionym na zero powoduje utworzenie nieprzezroczystego atrybutu z pustym wskaźnikiem packed_data. Konstruktor OpaqueAttribute przekazuje ten pusty wskaźnik do memcpy() bez walidacji warunku zerowego rozmiaru, co prowadzi do niezdefiniowanego zachowania i zakończenia procesu.

OpenEXR przed wersjami 3.2.11, 3.3.13 i 3.4.14 zawiera podatność w narzędziu exrmultiview, które może zapisywać poza stertą podczas łączenia dwóch dostarczonych przez atakującego, indywidualnie poprawnych plików EXR, gdy unia dataWindow nie jest wyrównana do próbkowania kanałów jednego widoku. Prowadzi to do zapisu poza granicami sterty.

PyOpenEXR w wersjach 3.3.0-3.3.12 i 3.4.0-3.4.13 ma podatność na zapis poza stertą podczas odczytu spreparowanego pliku EXR z głębokimi scanline'ami. Specjalnie skonstruowany plik z kanałem 'left' i warstwowymi kanałami RGB może spowodować przepełnienie bufora i awarię.

OpenEXR w wersjach 3.3.0 do 3.3.12 i 3.4.0 do 3.4.13 zawiera przepełnienie bufora sterty w PyOpenEXR, wywoływane przez kolizję nazw kanałów między dosłownymi a prefiksowanymi kanałami RGB. Specjalnie spreparowany plik EXR może spowodować zapis poza granicami tablicy NumPy podczas dekodowania pikseli.

OpenEXR w wersjach do 3.2.10, 3.3.0 do 3.3.12 i 3.4.0 do 3.4.13 zawiera podatność w bibliotece OpenEXRUtil, która zwraca wskaźnik poza zakresem z API SampleCountChannel::row() dla obrazów głębokich z niezerowym początkiem dataWindow. Może to prowadzić do odczytu poza zakresem, co może spowodować awarię procesu lub ujawnienie danych z pamięci.

OpenEXR w wersjach 3.4.0-3.4.12 ma podatność na odczyt poza zakresem w dekoderze HTJ2K, ponieważ nie sprawdza, czy wartość pola długości nagłówka (PLEN) mieści się w dostępnym buforze. Spreparowany plik EXR może spowodować odczyt poza pamięcią.

PyOpenEXR w wersjach 3.3.0-3.3.12 i 3.4.0-3.4.13 zwraca nieinicjalizowane dane sterty podczas odczytu spreparowanego pliku EXR z warstwowymi kanałami RGB. Kanały z prefiksem są dekodowane do niewłaściwych pozycji, a pozostałe pozostają niezainicjalizowane, co może ujawnić zawartość pamięci.

OpenEXR w wersjach przed 3.2.11, 3.3.0-3.3.12 i 3.4.0-3.4.13 ma podatność na awarię podczas przetwarzania spreparowanego pliku EXR z pustym atrybutem multiView. Funkcja viewFromChannelName() indeksuje pusty wektor, co prowadzi do crasha.

OpenEXR w wersjach 3.2.0-3.2.10, 3.3.0-3.3.12 i 3.4.0-3.4.13 ma podatność na odczyt poza stertą na buildach ILP32. Spreparowany plik EXR z kompresją RLE może spowodować obcięcie rozmiaru przed alokacją, prowadząc do odczytu poza buforem i odmowy usługi.

OpenEXR w wersjach 3.1.0-3.2.10, 3.3.0-3.3.12 i 3.4.0-3.4.13 jest podatny na zapis poza zakresem (out-of-bounds write) na buildach ILP32. Specjalnie spreparowany plik EXR z kompresją B44 może spowodować obcięcie rozmiaru bufora przed alokacją, a funkcja uncompress_b44_impl() zapisuje dane z użyciem szerokości kanału kontrolowanej przez atakującego, co prowadzi do odmowy usługi i uszkodzenia pamięci. Problem został naprawiony w wersjach 3.2.11, 3.3.13 i 3.4.14.

OpenEXR przed wersją 3.2.11, wersje 3.3.0-3.3.12 i 3.4.0-3.4.13 są podatne na odczyt poza zakresem (out-of-bounds read) na buildach ILP32. Podatność jest osiągana, gdy specjalnie spreparowany nieskompresowany plik EXR z głębokimi kafelkami powoduje zawinięcie obliczeń rozmiaru tabeli liczby próbek w OpenEXRCore decoding.c przed iteracją przez pełne wymiary kafelka kontrolowane przez atakującego, co prowadzi do odmowy usługi. Problem został naprawiony w wersjach 3.2.11, 3.3.13 i 3.4.14.

OpenEXR przed wersjami 3.2.11, 3.3.0 do 3.3.12 oraz 3.4.0 do 3.4.13 może zwracać wskaźnik poza zakresem z funkcji TypedDeepImageChannel::row() w przypadku spreparowanego głębokiego pliku EXR z niezerowym początkiem okna danych. Podatność wynika z połączenia dostępu do wierszy opartego na zerze z wskaźnikiem bazowym skorygowanym o współrzędne bezwzględne, co może prowadzić do awarii lub ograniczonego ujawnienia informacji. Problem naprawiono w wersjach 3.2.11, 3.3.13 i 3.4.14.

W bibliotece OpenEXRUtil (część OpenEXR) w wersjach 3.3.0 do 3.3.12 oraz 3.4.0 do 3.4.12, udokumentowane API TypedDeepImageChannel<T>::row() może zwracać wskaźnik poza zakresem, gdy obraz głęboki ma niezerowe pochodzenie okna danych (dataWindow origin). Prowadzi to do odczytu poza stertą i awarii, z potencjalnym ujawnieniem informacji przy kontrolowanym układzie sterty. Problem naprawiono w wersjach 3.3.13 i 3.4.13.

OpenEXR w wersjach 3.3.0 do 3.3.12 oraz 3.4.0 do 3.4.13 jest podatny na zapis poza granicami sterty podczas odczytu spreparowanego pliku EXR z głębokimi skanliniami przez narzędzie exrmetrics. Problem występuje przy opcjach konwersji pikseli, takich jak --pixelmode float lub --bench, gdy DeepSlice żąda danych w formacie FLOAT, a bufory próbek są przydzielane z uwzględnieniem rozmiaru elementu HALF. Luka została naprawiona w wersjach 3.3.13 i 3.4.14.

OpenEXR przed wersją 3.2.11, w wersjach 3.3.0 do 3.3.12 oraz 3.4.0 do 3.4.13 jest podatny na zapis poza granicami sterty na systemach 32-bitowych/ILP32 podczas odczytu spreparowanego kafelkowego pliku EXR przez publiczne API TiledRgbaInputFile RGBA. Plik używa małego okna danych 40x40, ale rozmiar kafelka 65537x65537. Na ILP32 obliczenie rozmiaru bufora konwersji kafelków Array2D<Rgba> powoduje przepełnienie, przydziela znacznie mniejszy bufor sterty, a dekodowanie kafelków zapisuje poza tę alokację. Problem naprawiono w wersjach 3.2.11, 3.3.13 i 3.4.14.

OpenEXR przed wersją 3.2.11, w wersjach 3.3.0 do 3.3.12 oraz 3.4.0 do 3.4.13 pozwala spreparowanemu plikowi EXR z niezerowym dataWindow.min na spowodowanie, że TypedFlatImageChannel::row() zwróci nieprawidłowy wskaźnik sterty, co prowadzi do zapisów poza granicami lub użycia po zwolnieniu. Dzieje się tak, gdy aplikacja zapisuje wiersze przez FlatHalfChannel::row(). Dotknięte są narzędzia, konwertery, komponenty potoku renderowania lub usługi przetwarzania obrazów, które akceptują niezaufane pliki EXR i używają FlatHalfChannel::row() na załadowanych obrazach. Problem naprawiono w wersjach 3.2.11, 3.3.13 i 3.4.14.

OpenEXR w wersjach 3.1.0-3.2.10, 3.3.0-3.3.12 i 3.4.0-3.4.13 ma podatność na przepełnienie liczby całkowitej w funkcji unpack_sample_table(), co może prowadzić do odczytu z nieprawidłowego adresu pamięci i awarii podczas dekodowania złośliwego pliku EXR z głębokimi kafelkami.

OpenEXR przed wersjami 3.2.10, 3.3.12 i 3.4.13 ma podatność na nieskończoną pętlę w funkcji roundListSizeUp() w SampleCountChannel. Podanie wartości UINT_MAX powoduje zapętlenie, co prowadzi do zawieszenia aplikacji (denial of service).

OpenEXR w wersjach 3.4.0-3.4.12 ma podatność na dereferencję pustego wskaźnika w funkcji exr_attr_set_bytes(). Podanie dodatniej wartości hint_length z pustym wskaźnikiem type_hint powoduje deterministyczną awarię, co prowadzi do odmowy usługi.

OpenEXR przed wersjami 3.2.10, 3.3.12 i 3.4.13 ma podatność na zapis poza dozwolony obszar pamięci (heap out-of-bounds write) w funkcji SampleCountChannel::set(). Błąd w obliczaniu współrzędnej Y może prowadzić do zapisu przed buforem, co może skutkować uszkodzeniem pamięci i awarią.

OpenEXR w wersjach 3.4.0-3.4.12 ma podatność na błąd asercji w ścieżce dekodowania HTJ2K, co pozwala na wywołanie awarii procesu (abort) przez złośliwy plik EXR skompresowany HTJ2K. Problem wynika z przekazania nieprawidłowych danych do biblioteki OpenJPH, która używa asercji zamiast obsługi błędów.

OpenEXR jest referencyjną implementacją i specyfikacją formatu obrazu EXR, szeroko używanego w przemyśle filmowym. W wersjach od 3.4.0 do 3.4.12, spreparowany plik EXR skompresowany HTJ2K powoduje bezwarunkowe przerwanie procesu w każdej aplikacji, która wywołuje exr_start_read() na niezaufanym wejściu, co prowadzi do odmowy usługi. Awaria jest wywoływana przez marker QCD, którego dolne pięć bitów jest zerowe, co OpenEXR przekazuje do dołączonej biblioteki OpenJPH podczas konstruowania strumienia kodowego i oceny parametrów delta kwantyzacji. OpenJPH używa asercji zamiast odzyskiwalnego błędu do walidacji tych bitów, więc każda nieprawidłowa wartość wywołuje bezpośrednio abort() i nie może być przechwycona przez otaczającą obsługę błędów, co jest pogłębione przez to, że OpenEXR otacza tylko wewnętrzny parser nagłówka HT obsługą błędów, pozostawiając późniejsze odczyty strumienia kodowego i wywołania konstrukcji niechronione. Problem został rozwiązany w wersji 3.4.13.

OpenEXR w wersjach od 3.4.0 do 3.4.13 ma podatność na awarię podczas dekodowania specjalnie spreparowanych plików EXR skompresowanych HTJ2K. Problem dotyczy geometrii kafelków i bloków kodu w dekoderze AVX2 OpenJPH, co może prowadzić do zapisu poza stosem i odmowy usługi. Poprawka została wydana w wersji 3.4.14.

W bibliotece OpenEXR w wersjach 3.4.0 do 3.4.11 odkryto podatność w dekoderze HTJ2K (High-Throughput JPEG 2000). Funkcja ht_undo_impl() odczytuje dane poza przydzielonym buforem sterty, ponieważ nie weryfikuje zgodności rozmiaru linii z deklarowaną szerokością kanału EXR. Atakujący może wykorzystać spreparowany plik EXR do wywołania deterministycznej awarii (DoS) lub potencjalnego wycieku danych z sąsiedniej sterty.

W bibliotece OpenEXR w wersjach od 3.0.0 do 3.2.9, od 3.3.0 do 3.3.11 oraz od 3.4.0 do 3.4.11 wykryto przepełnienie liczby całkowitej w funkcji ImageChannel::resize. Błąd prowadzi do zapisu poza dozwolony obszar sterty (heap OOB write) poprzez publiczne API OpenEXRUtil.

W bibliotece OpenEXR w wersjach 3.2.0 do 3.2.7, 3.3.0 do 3.3.9 oraz 3.4.0 do 3.4.9 występuje przepełnienie liczby całkowitej w operacji mnożenia szerokości i wysokości obrazu w pliku `internal_dwa_compressor.h:1722`. Brak rzutowania na typ `size_t` powoduje, że wynik mnożenia może przekroczyć zakres 32-bitowej liczby całkowitej, co prowadzi do nieprawidłowego obliczenia rozmiaru bufora.

W bibliotece OpenEXR w wersjach od 3.2.0 do 3.2.7, 3.3.9 i 3.4.9 wykryto podatność w dekompresji DWA. Przy odpowiednio dużej szerokości obrazu, arytmetyka 32-bitowa powoduje przepełnienie, co prowadzi do zapisu poza przydzielonym buforem.

W bibliotece OpenEXR w wersjach od 3.1.0 do 3.2.6, 3.3.8 i 3.4.8 wykryto podatność w funkcji internal_exr_undo_piz(). Arytmetyka na 32-bitowych liczbach całkowitych ze znakiem może spowodować przepełnienie i zawinięcie wskaźnika, co prowadzi do odczytu i zapisu poza dozwolonym obszarem pamięci podczas dekodowania plików EXR.

W bibliotece OpenEXR w wersjach od 3.2.0 do 3.2.7, 3.3.9 i 3.4.9 występuje podatność polegająca na niezgodnym z wymaganiami zapisie pamięci w funkcji LossyDctDecoder_execute(). Podczas dekodowania skompresowanego pliku EXR z kanałem typu FLOAT, wskaźnik do wiersza bufora może być niewyrównany do 4 bajtów, co prowadzi do niezdefiniowanego zachowania i awarii na architekturach wymagających wyrównania (ARM, RISC-V).

Podatność w bibliotece OpenEXR (wersje 3.4.0 do 3.4.6) umożliwia atakującemu przepełnienie sterty poprzez dostarczenie spreparowanego pliku EXR z kompresją HTJ2K i szerokością kanału 32768. Atakujący może zapisać kontrolowane dane poza buforem sterty, co może prowadzić do zdalnego wykonania kodu.

W bibliotece OpenEXR wykryto podatność polegającą na przepełnieniu licznika całkowitego bez znaku (unsigned int) podczas akumulacji rozmiarów próbek w funkcji CompositeDeepScanLine::readPixels. Atakujący może kontrolować duże liczby próbek, powodując zawinięcie licznika modulo 2^32, co prowadzi do alokacji zbyt małego bufora i późniejszego przepełnienia bufora podczas zapisu danych.