W implementacji funkcji haszującej SHA-3 (Keccak), proponowanej w pakiecie XKCP (eXtended Keccak Code Package), wykryto podatność (CVE-2022-37454), która może prowadzić do przepełnienia bufora podczas przetwarzania określonych danych. Problem wynika z błędu w kodzie konkretnej implementacji SHA-3, a nie z podatności samego algorytmu. Pakiet XKCP jest uznawany za oficjalną implementację SHA-3, rozwijaną przy udziale zespołu programistów Keccak i używaną jako podstawa w funkcjach do pracy z SHA-3 w różnych językach programowania (na przykład kod XKCP jest używany w module hashlib w Pythonie, pakiecie digest-sha3 w Ruby oraz funkcjach hash_* w PHP).
Jak podaje badacz, który wykrył problem, udało mu się wykorzystać podatność do naruszenia właściwości kryptograficznych funkcji haszującej i znalezienia pierwszego i drugiego preobrazów, a także określenia kolizji. Ponadto stworzono prototyp exploita, który umożliwia wykonanie kodu podczas obliczania hasza specjalnie przygotowanego pliku. Potencjalnie podatność ta może być także wykorzystana do ataków na algorytmy weryfikacji podpisów cyfrowych, które wykorzystują SHA-3 (np. Ed448). Szczegóły metod ataków planuje się opublikować później, po powszechnym usunięciu podatności.
Nie jest na razie jasne, jak podatność wpływa na istniejące aplikacje w praktyce, ponieważ aby problem się ujawnił, w kodzie musi być zastosowane cykliczne obliczanie hasza blokami, a jeden z przetwarzanych bloków musi mieć rozmiar około 4 GB (co najmniej 2^32 — 200 bajtów). Przy przetwarzaniu danych wejściowych jednocześnie (bez sekwencyjnego obliczania hasza w kawałkach) problem się nie ujawnia. Najprostszą metodą ochrony jest ograniczenie maksymalnego rozmiaru danych, biorących udział w jednej iteracji obliczania hasza.
Wrażliwość wynika z błędu w blokowym przetwarzaniu danych wejściowych. Z powodu nieprawidłowego porównania wartości typu 'int' określa się błędny rozmiar oczekujących danych do przetworzenia, co prowadzi do zapisu poza przydzielonym buforem. W szczególności, w porównaniu użyto wyrażenia 'partialBlock + instance->byteIOIndex', które przy dużych wartościach składników prowadziło do przepełnienia całkowitego. Ponadto w kodzie występowało nieprawidłowe rzutowanie typów '(unsigned int)(dataByteLen - i)', co prowadziło do przepełnienia w systemach z 64-bitowym typem size_t.
Przykład kodu prowadzącego do przepełnienia: import hashlib h = hashlib.sha3_224() m1 = b"\x00" * 1; m2 = b"\x00" * 4294967295; h.update(m1) h.update(m2) print(h.hexdigest())
Źródło: opennet.ru
