CVE-2026-84897

src/internal.c w wolfSSL wolfSSH do wersji 1.5.0 dopuszcza komunikaty wymiany grupowej Diffiego-Hellmana między serwerem a klientem SSH_MSG_KEX_DH_GEX_GROUP (31) i SSH_MSG_KEX_DH_GEX_REPLY (33), gdy serwer odbiera je od nieuwierzytelnionego klienta. Funkcja IsMessageAllowedServer() nie sprawdza kierunku zakresu komunikatów wymiany kluczy: gdy partner wprowadza klucz i nie oczekuje się żadnego konkretnego komunikatu, czyli stanu, w jakim znajduje się serwer przez całe okno po przetworzeniu KEXINIT klienta, ponieważ nic tam nie ustawia uzgadniania->expectMsgId, funkcja wypada ze swojej gałęzi oczekiwań bez werdyktu i osiąga granicę liczbową, która dopuszcza każdy identyfikator wiadomości od 30 do 34. Klient negocjujący diffie-hellman-group-exchange-sha256, a następnie wysyła komunikat 31, powoduje, że serwer uruchamia po stronie klienta procedurę obsługi DoKexDhGexGroup(), która sprawdza poprawność grupy dostarczonej przez atakującego za pomocą dwóch 8-rundowych testów pierwszości Millera-Rabina, jednego na p i jednego na (p-1)/2, na wartości do 8192 bitów. Następnie procedura obsługi zwraca sukces: serwer przechowuje klucz główny i generator atakującego, generuje parę kluczy Diffiego-Hellmana w grupie atakującego i wysyła komunikat roli klienta SSH_MSG_KEX_DH_GEX_INIT (32) z powrotem do atakującego. Opublikowane bezpieczne liczby pierwsze w RFC 3526 stanowią dane wejściowe w najgorszym przypadku i ich uzyskanie nie kosztuje atakującego nic. Weryfikacja pierwszości została dodana w wersji 1.5.0; wersje od 1.2.0 do 1.4.22 obsługują tę samą wiadomość i wprowadzają tę samą ścieżkę roli klienta bez kosztu pierwszości. Wiadomość 33 również jest akceptowana, ale na serwerze jest odrzucana przed jakąkolwiek kryptografią, ponieważ nie zarejestrowano żadnego wywołania zwrotnego sprawdzającego klucz publiczny, więc nie wiąże się to z porównywalnymi kosztami. Nie ma to wpływu na kompilacje definiujące WOLFSSH_NO_DH_GEX_SHA256, co sugeruje WOLFSSH_NO_DH lub NO_SHA256.