Podatność use-after-free (UAF) w modułach `lzma.LZMADecompressor`, `bz2.BZ2Decompressor` oraz `gzip.GzipFile` języka Python pozwala na odczyt i zapis w zwolnionym obszarze pamięci. Jest ona groźna szczególnie w aplikacjach działających pod presją pamięciową, które ponownie wykorzystują instancje dekompresorów po wystąpieniu błędu `MemoryError`.
▸ Pokaż oryginał (EN)
Use-after-free (UAF) was possible in the `lzma.LZMADecompressor`, `bz2.BZ2Decompressor`, and `gzip.GzipFile` when a memory allocation fails with a `MemoryError` and the decompression instance is re-used. This scenario can be triggered if the process is under memory pressure. The fix cleans up the dangling pointer in this specific error condition. The vulnerability is only present if the program re-uses decompressor instances across multiple decompression calls even after a `MemoryError` is raised during decompression. Using the helper functions to one-shot decompress data such as `lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, and `zlib.decompress()` are not affected as a new decompressor instance is used per call. If the decompressor instance is not re-used after an error condition, this usage is similarly not vulnerable.
Błąd pojawia się, gdy podczas dekompresji dochodzi do niepowodzenia alokacji pamięci skutkującego wyjątkiem `MemoryError`, a następnie ta sama instancja dekompresor jest ponownie użyta do kolejnej operacji dekompresji. W takim przypadku wskaźnik do zwolnionego obszaru pamięci (dangling pointer) nie jest czyszczony, co prowadzi do stanu use-after-free. Podatność nie dotyczy jednorazowych funkcji pomocniczych (`lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, `zlib.decompress()`), ponieważ każde ich wywołanie tworzy nową instancję dekompresor. Poprawka usuwa wiszący wskaźnik w momencie wystąpienia opisanego błędu.
Atakujący mogący wpłynąć na przetwarzane dane i sprowokować odpowiednie warunki pamięciowe może doprowadzić do nieautoryzowanego odczytu lub zapisu pamięci procesu, co potencjalnie skutkuje ujawnieniem wrażliwych danych lub wykonaniem arbitralnego kodu (RCE).
Należy zastosować patche dostępne w repozytorium CPython zgodnie z referencjami (commity: 47128e6, 6a5f79c, 8fc66ae, c3cf71c, e20c6c9). Zaleca się aktualizację środowiska Python do wersji zawierającej poprawkę. Doraźnie należy upewnić się, że kod aplikacji nie ponownie używa instancji dekompresor po wystąpieniu wyjątku `MemoryError`, lub korzystać wyłącznie z jednorazowych funkcji pomocniczych (`lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, `zlib.decompress()`).
Aplikacje napisane w języku Python, które ponownie wykorzystują instancje klas `lzma.LZMADecompressor`, `bz2.BZ2Decompressor` lub `gzip.GzipFile` po wystąpieniu wyjątku `MemoryError` podczas dekompresji; konkretne podatne wersje CPython wskazane są w referencjach producenta (commity na GitHub python/cpython)
Podatność jest aktywna wyłącznie przy jednoczesnym spełnieniu dwóch warunków: ponownym użyciu instancji dekompresor po błędzie `MemoryError` oraz działaniu procesu pod presją pamięciową. Aplikacje używające jednorazowych funkcji pomocniczych dekompresji są odporne na tę podatność.
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X