Ostatnio pojawiła się wiadomość o luce w bibliotece zlib już skatalogowany pod CVE-2018-25032, powodując przepełnienie bufora podczas próby kompresji specjalnie przygotowanej sekwencji znaków w przychodzących danych.
W swojej obecnej formie badacze wykazali możliwość wywołania nieprawidłowej terminacji procesu, więc nie zbadano jeszcze, czy problem może mieć poważniejsze konsekwencje.
Wspomina się, że luka zamanifestowało się to od wersji zlib 1.2.2.2 i wpływa na obecną wersję zlib 1.2.11. Warto zauważyć, że łata naprawiająca lukę została zaproponowana w 2018 roku, ale deweloperzy nie zwrócili na nią uwagi i nie wydali wersji korygującej (ostatnia aktualizacja biblioteki zlib miała miejsce w 2017 roku).
Ten błąd został zgłoszony przez Danilo Ramosa z Eideticom, Inc polował przez 13 lat, zanim go znaleziono! Błąd został wprowadzony w zlib 1.2.2.2, z dodatkiem opcji Z_FIXED. Opcja wymusza stosowanie stałych kodów Huffmana. W przypadku rzadkich wpisów z
dużo odległych meczów, oczekujący bufor, w którym skompresowane dane są zapisywane, można je zastąpić. Powoduje to uszkodzenie danych wyjściowych z powodu nieprawidłowe odległości i może skutkować dostępem poza granice, awaria aplikacji.
Słaby punkt manifestuje się, gdy strumień wejściowy zawiera dużą liczbę dopasowań do spakowania, do którego opakowania aplikowane są w oparciu o kody Huffmana naprawiony. W pewnych okolicznościach zawartość bufora pośredniego, w którym umieszczany jest skompresowany wynik, może nakładać się na pamięć, w której przechowywana jest tablica częstotliwości symboli. W rezultacie obserwuje się tworzenie niepoprawnie skompresowanych danych i awarię z powodu zapisu poza granicami bufora.
Słaby punkt może być wykorzystany tylko przez strategię kompresji opartą na stałych kodach Huffmana. Podobna strategia jest wybierana, gdy opcja Z_FIXED jest jawnie zawarta w kodzie (przykład sekwencji, która powoduje awarię podczas korzystania z opcji Z_FIXED). Sądząc po kodzie strategia Z_FIXED może być również wybrana automatycznie, jeśli optymalne i statyczne drzewa obliczone dla danych mają ten sam rozmiar.
Rozwiązanie tutaj łączy bufor odległości i literał/długość bufory w pojedynczy bufor symboli. Teraz trzy bajty dprzestrzeń bufora jest otwierana dla każdego literału lub długości/odległości zużyta para, zamiast poprzednich dwóch bajtów zapewnia to
że oczekujący bufor nie może nadpisać tablicy symboli, ponieważ maksymalna długość/odległość skompresowanego kodu o stałej długości wynosi 31 bitów, oraz ponieważ na każde trzy bajty przypada cztery bajty wolnego miejsca przestrzeni symboli.
Nie jest jeszcze jasne, czy warunki wykorzystania luki są zgodne ze strategią kompresji Z_DEFAULT_STRATEGY, która jest stosowana domyślnie.
W przeciwnym razie usterka będzie ograniczona do określonych systemów, w których opcja Z_FIXED jest wyraźnie zastosowana. Jeśli tak, szkoda wynikająca z luki może być bardzo znacząca, ponieważ biblioteka zlib jest de facto standardem i jest wykorzystywana w wielu popularnych projektach, w tym w jądrze Linux, OpenSSH, OpenSSL, apache httpd, libpng, FFmpeg, rsync, dpkg. , rpm, Git, PostgreSQL, MySQL itp.
Wspomina się również o tym wybrane parametry, pod którymi ujawnia się podatność przy wyborze domyślnej strategii kompresji Z_DEFAULT_STRATEGY. W rzeczywistych warunkach atak jest nadal uważany za mało prawdopodobny, ponieważ eksploatacja przy użyciu ujawnionej sekwencji wymaga ustawienia parametru memLevel na 1, podczas gdy poziom 8 jest wybierany domyślnie.
Przykład sekwencji blokady, gdy wywoływana jest „deflateInit2(&strm, 7, Z_DEFLATED, 15, 1, Z_DEFAULT_STRATEGY)” (poziom=7, windowBits=15, memLevel=1).
W końcu należy wspomnieć, że rozwiązanie również nie jest wliczone nadal w pakietach oferowanych przez dystrybucje, więc możesz śledzić wydania poprawek według dystrybucji na tych stronach: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD FreeBSD, NetBSD, a problem nie dotyczy biblioteki zlib-ng.
Jeśli chcesz dowiedzieć się więcej na ten temat, możesz zapoznać się ze szczegółami W poniższym linku.