W implementacji kryptograficznej funkcji skrótu SHA-3 (Keccak) oferowanej w pakiecie XKCP (eXtended Keccak Code Package) została zidentyfikowana luka (CVE-2022-37454), która może prowadzić do przepełnienia bufora podczas przetwarzania niektórych danych. Problem wynika z błędu w kodzie konkretnej implementacji SHA-3, a nie z luki w samym algorytmie. Pakiet XKCP jest reklamowany jako oficjalna implementacja SHA-3, opracowana przy udziale zespołu programistów Keccak i używana jako podstawa dla funkcji SHA-3 w różnych językach programowania (np. kod XKCP jest używany w hashlib Pythona moduł, funkcje pakietu Sha3 Ruby Digest i PHP hash_*).
Według badacza, który zidentyfikował problem, udało mu się wykorzystać lukę do naruszenia właściwości kryptograficznych funkcji skrótu i znalezienia pierwszego i drugiego obrazu wstępnego, a także wykryć kolizje. Ponadto ogłoszono, że powstanie prototypowy exploit, który umożliwi wykonanie kodu podczas obliczania skrótu specjalnie zaprojektowanego pliku. Lukę tę można również potencjalnie wykorzystać do ataku na algorytmy weryfikacji podpisu cyfrowego korzystające z SHA-3 (na przykład Ed448). Opublikowanie szczegółów metod ataku planowane jest później, gdy luka zostanie już wszędzie wyeliminowana.
Nie jest jeszcze jasne, na ile luka wpływa w praktyce na istniejące aplikacje, gdyż aby problem uwidocznił się w kodzie, należy zastosować cykliczne obliczenia skrótu w blokach, a jeden z przetwarzanych bloków musi mieć rozmiar około 4 GB (co najmniej 2^32 - 200 bajtów). Podczas przetwarzania danych wejściowych od razu (bez sekwencyjnego obliczania skrótu w częściach) problem nie pojawia się. Jako najprostszą metodę ochrony proponuje się ograniczenie maksymalnego rozmiaru danych biorących udział w jednej iteracji obliczenia skrótu.
Podatność wynika z błędu w blokowym przetwarzaniu danych wejściowych. W wyniku nieprawidłowego porównania wartości z typem „int” ustalany jest nieprawidłowy rozmiar danych oczekujących, co powoduje zapisanie ogona poza przydzielonym buforem. W szczególności w porównaniu wykorzystano wyrażenie „partialBlock + instancja->byteIOIndex”, co doprowadziło do przepełnienia liczb całkowitych w przypadku dużych wartości części składowych. Dodatkowo w kodzie wystąpiło nieprawidłowe rzutowanie typu „(unsigned int)(dataByteLen - i)”, co spowodowało przepełnienie w systemach z 64-bitowym typem size_t.
Przykładowy kod powodujący przepełnienie: 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