CVE-2025-14942

W wolfSSH do wersji 1.5.0 zbudowanej z opcją --enable-fwd, funkcja DoChannelOpen() w src/internal.c ogranicza tylko otwieranie kanałów direct-tcpip za pomocą wywołania zwrotnego polityki przekazywania. Otwarcia forwarded-tcpip są dopuszczane bez sprawdzenia autoryzacji i nie są ograniczane liczbowo, co pozwala złośliwemu peerowi SSH na przydzielenie nieograniczonych buforów per-kanał dla kanałów przekazywania, których aplikacja nigdy nie autoryzowała. Klient również nie sprawdza otwarcia forwarded-tcpip względem przekazywań zarejestrowanych za pomocą żądania tcpip-forward, jak wymaga RFC 4254 sekcja 7.2, więc złośliwy serwer może otwierać kanały przekazywania dla adresów i portów, których klient nigdy nie prosił o przekazywanie.

W wolfSSH w wersjach 1.4.20 i starszych klientach występuje nieprawidłowa weryfikacja uwierzytelniania hosta, co pozwala na obejście uwierzytelniania i wyciek danych uwierzytelniających klienta.

Podatność w wolfSSH do wersji 1.5.0 pozwala nieuwierzytelnionemu klientowi wysłać komunikaty wymiany grup Diffie-Hellmana (SSH_MSG_KEX_DH_GEX_GROUP i SSH_MSG_KEX_DH_GEX_REPLY) do serwera, który nie sprawdza kierunku tych komunikatów. Serwer uruchamia wówczas procedurę przeznaczoną dla klienta, co prowadzi do kosztownych testów pierwszości Millera-Rabina na danych sterowanych przez atakującego, a następnie do wygenerowania pary kluczy w grupie wybranej przez atakującego.

Niedopełnienie liczby całkowitej bez znaku w funkcji wstrncat() w src/port.c w wolfSSH od wersji 1.4.11 do 1.5.0 na platformach innych niż Windows umożliwia uwierzytelnionemu zdalnemu atakującemu zapisanie jednego bajtu zerowego poza końcem bufora stosu poprzez wysłanie spreparowanej ścieżki SFTP. Funkcja wolfSSH_RealPath() w src/ssh.c dołącza każdy komponent ścieżki z ograniczeniem pozostałego rozmiaru (outSz - curSz) zamiast pełnego rozmiaru docelowego, więc gdy skumulowana ścieżka osiągnie połowę bufora wyjściowego, obliczenie size_t n - strlen(s1) - 1 zawija się do wartości bliskiej SIZE_MAX. Wywołanie strncat() jest wtedy praktycznie nieograniczone i kopiuje cały komponent; gdy ten komponent dokładnie wypełnia resztę bufora, jego kończący bajt zerowy jest zapisywany jeden bajt poza końcem. Własna kontrola długości przez wywołującego utrzymuje skopiowane dane wewnątrz bufora, więc przepełnienie jest ograniczone do tego pojedynczego bajtu zerowego, który może uszkodzić sąsiednią wartość na stosie i spowodować awarię procesu. Aplikacje wywołujące publiczną funkcję wolfSSH_RealPath() z buforem wyjściowym mniejszym niż ścieżka wejściowa są dodatkowo narażone na nieograniczoną kopię, ponieważ wyrażenie word32 outSz - segSz w tej kontroli długości również zawija się.

wolfSSH nie weryfikuje, czy identyfikator krzywej ECDSA w bloku klucza hosta KEXDH_REPLY odpowiada algorytmowi uzgodnionemu podczas wymiany kluczy. Aktywny atakujący typu man-in-the-middle może podstawić blok klucza hosta z inną krzywą ECDSA, co powoduje zaimportowanie klucza na niewłaściwej krzywej, a ponieważ atakujący kontroluje klucz prywatny dla podstawionej krzywej, weryfikacja podpisu przechodzi.

W bibliotece wolfSSH wykryto podatność polegającą na odczycie poza zakresem pamięci sterty w funkcji wolfSSH_CleanPath(). Zdalny, uwierzytelniony atakujący może wywołać ten problem, wysyłając spreparowaną ścieżkę SCP zawierającą sekwencje '/./', co prowadzi do odczytu o 1 bajt poza przydzielonym buforem.