Podatności wolfSSL

Wersje wolfSSL przed 3.12.2 zawierają słabą orakl Bleichenbachera, gdy negocjowana jest jakakolwiek suite szyfrowania TLS z użyciem wymiany kluczy RSA. Atakujący może odzyskać klucz prywatny z podatnej aplikacji wolfSSL.

Wersje wolfSSL przed 3.11.0 nie zapobiegają akceptacji źle sformatowanego klucza DH przez funkcję wc_DhAgree.

Wersje wolfSSL przed 3.10.2 mają problem z dostępem do pamięci poza przydzielonym zakresem podczas ładowania spreparowanych parametrów DH, co prowadzi do przepełnienia bufora wywołanego przez źle sformatowany tymczasowy plik DH.

Wersje wolfSSL (wcześniej CyaSSL) przed 3.6.8 są podatne na atak typu denial of service, który może być spowodowany przez złośliwie skonstruowane ciasteczko DTLS w wiadomości ClientHello.

Certyfikat bez dNSName SAN, ale z innym typem SAN (np. registeredID lub iPAddress) omija sprawdzanie ograniczeń nazw dla CN jako DNS. Poprawka z CVE-2026-6731 była niekompletna, co wprowadzono w wolfSSL 5.9.2.

Podatność CVE-2023-3724 dotyczy klientów TLS 1.3, które nie otrzymują rozszerzenia PSK ani KSE podczas łączenia się z złośliwym serwerem. W takim przypadku używany jest domyślny, przewidywalny bufor dla wartości IKM, co może prowadzić do kompromitacji klucza sesji.

Specjalnie przygotowany certyfikat x509 może spowodować nadpisanie bajtu poza zakresem w wolfSSL w wersji do 3.10.2, co prowadzi do potencjalnych luk w walidacji certyfikatów, odmowy usługi oraz możliwego zdalnego wykonania kodu.

Podatność w funkcji ConfirmNameConstraints() w pliku wolfcrypt/src/asn.c biblioteki wolfSSL w wersjach 5.9.1 i 5.9.2 pozwala atakującemu wywołać odmowę usługi (DoS) poprzez dostarczenie spreparowanych certyfikatów urzędu certyfikacji. W efekcie klienci TLS oparte na wolfSSL błędnie odrzucają prawidłowe certyfikaty bez rozszerzenia SAN.

Podatność w wolfSSL powoduje pominięcie sprawdzania listy CRL dla certyfikatów bez adresu OCSP, gdy włączone jest jednocześnie sprawdzanie OCSP i CRL. W rezultacie certyfikat odwołany przez CRL może zostać zaakceptowany, a brak odpowiedzi OCSP jest traktowany jako odpowiedź pozytywna. Problem dotyczy wersji do 5.9.2 włącznie i jest osiągalny w TLS 1.0-1.3 oraz DTLS.

Klient (D)TLS 1.2 może zaakceptować wiadomość ChangeCipherSpec przed wysłaniem ClientKeyExchange, co pozwala atakującemu dokończyć handshake zamiast serwera i wysyłać dane akceptowane jako autentyczne. Klienci DTLS 1.2 są narażeni, gdy datagram dostarczy nieuporządkowane rekordy, a klienci TLS 1.2, gdy aplikacja używa wolfSSL_inject() lub włącza read ahead.

Funkcja MatchTrustedPeer ignoruje użyty klucz publiczny, co pozwala na sfałszowanie klonów CA i ominięcie weryfikacji. Dotyczy to buildów z makrem WOLFSSL_TRUST_PEER_CERT i ładowaniem certyfikatów CA przez wolfSSL_CTX_trust_peer_cert() lub wolfSSL_trust_peer_cert(). Atakujący musi znać ładowane certyfikaty, aby wykorzystać podatność.

W przypadku użycia RPK (Raw Public Key), klient TLS 1.2, 1.3 i DTLS 1.2 może zaakceptować niechciany typ certyfikatu serwera RawPublicKey, co pozwala złośliwemu lub błędnie działającemu serwerowi ominąć uwierzytelnianie. RPK jest domyślnie wyłączone i dostępne tylko w buildach z --enable-rpk, --enable-all lub --enable-distro.

Nieudane wywołanie X509_verify_cert trwale umieszcza niezweryfikowany certyfikat atakującego CA we współdzielonym CertManager, omijając walidację certyfikatów we wszystkich konsumentach (TLS, OCSP, CRL, bezpośrednia weryfikacja). Dotyczy to wersji 5.8.4-5.9.2 wolfSSL z makrami (OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY) lub buildem --enable-opensslextra, gdy aplikacja wywołuje X509_verify_cert.

W wolfSSL w wersjach 5.9.2 i wcześniejszych występuje błąd w walidacji certyfikatów X.509, który nie egzekwuje poprawnie rozszerzeń NameConstraints, gdy między ograniczonym pośrednim CA a certyfikatem liścia znajduje się nieograniczony poziom CA. wolfSSL błędnie akceptuje certyfikaty dla nazw hostów, których nie powinien obejmować, z powodu błędu w maszynie stanów podczas przechodzenia łańcucha.

W wolfSSL w wersjach 5.7.2-5.9.2 występuje błąd implementacji po stronie klienta w RFC 6961 (wielokrotne stapling OCSP), który może prowadzić do fałszowania certyfikatów. Gdy klient włącza OCSP stapling z funkcją HAVE_CERTIFICATE_STATUS_REQUEST_V2 i używa wolfSSL_UseOCSPStaplingV2, akceptuje dowolny certyfikat w łańcuchu jako CA bez weryfikacji uprawnień.

We wszystkich wersjach korzystających z (D)TLS, w tym w wersjach domyślnych, istnieje sekwencja stanów warunkowych podczas zamykania TLS, która może prowadzić do użycia po zwolnieniu pamięci (heap-use-after-free). Jeśli aplikacja otrzyma częściowy wynik wolfSSL_read(), co czasami jest spowodowane małym buforem użytkownika, a następnie wywoła wolfSSL_shutdown w celu dwukierunkowego zamknięcia i spróbuje ponownie wywołać wolfSSL_read(), podczas gdy peer kontynuuje wysyłanie danych w trakcie zamykania, może dojść do użycia po zwolnieniu.

W bibliotece wolfSSL w wersjach od v5.3.0 do v5.9.2, w konfiguracjach bez zdefiniowanego NO_SESSION_CACHE_REF, funkcja wolfSSL_get_session() zwraca uchwyt do wpisu w globalnym cache sesji zamiast obiektu sesji. Ponieważ identyfikator sesji TLS 1.2 jest wybierany przez serwer i przesyłany jawnie, złośliwy serwer może nadpisać wpis klienta dla innego serwera, a następnie zostać zaakceptowany jako serwer oryginalny podczas wznowienia sesji bez weryfikacji certyfikatu i nazwy domeny.

Podatność w wolfSSL przy włączonym WOLFSSL_SMALL_CERT_VERIFY pozwala atakującemu na obejście weryfikacji podpisu certyfikatu. Z powodu błędnego scalania wyników, błędy parsowania ukrywają nieprawidłowy podpis, a sprawdzenie daty ważności i ograniczeń jest wykonywane przed weryfikacją podpisu. Atakujący może użyć samodzielnie wygenerowanego certyfikatu z dowolnymi bajtami w miejscu podpisu, aby przejść weryfikację, jeśli aplikacja używa callbacku zezwalającego na błędy daty.

W bibliotece wolfSSL w funkcjach wc_Blake2bHmacFinal i wc_Blake2sHmacFinal występuje błąd polegający na odrzuceniu wiadomości, gdy długość klucza przekracza rozmiar bloku BLAKE2. Powoduje to wygenerowanie kodu MAC niezależnego od wejściowej wiadomości, co narusza bezpieczeństwo uwierzytelniania.

Podatność w bibliotece wolfSSL umożliwia pominięcie ograniczeń nazw adresów IP, gdy makro WOLFSSL_IP_ALT_NAME nie jest zdefiniowane. W takiej konfiguracji certyfikat może naruszyć ograniczenia adresów IP nałożone przez urząd certyfikacji.

Podatność typu integer underflow w funkcji wc_PKCS7_DecryptOri biblioteki wolfSSL podczas przetwarzania spreparowanych informacji o innych odbiorcach (Other Recipient Info). Prowadzi to do nieprawidłowego obsłużenia długości podczas deszyfrowania.

Podatność w bibliotece wolfSSL powoduje, że ograniczenia nazw URI (nameConstraints) z certyfikatów pośrednich są parsowane, ale nie są egzekwowane podczas weryfikacji łańcucha certyfikatów. Oznacza to, że zaufany, ale skompromitowany podrzędny urząd certyfikacji (sub-CA) może wystawić certyfikat końcowy z wpisem URI w SAN, który narusza ograniczenia nałożone przez nadrzędny CA, a wolfSSL uzna go za prawidłowy.

W wolfSSL przed wersją 5.8.4 liczne implementacje stałoczasowe mogą zostać przekształcone przez optymalizacje LLVM w kod niestałoczasowy. Może to prowadzić do obserwowalnych różnic czasowych i ujawnienia informacji poprzez ataki kanałami bocznymi opartymi na czasie.

W wolfSSL w wersji 5.8.2 na wielu platformach występuje nieprawidłowa walidacja danych wejściowych podczas parsowania KeyShareEntry w TLS 1.3. Zdalny nieuwierzytelniony atakujący może wywołać odmowę usługi, wysyłając spreparowaną wiadomość ClientHello zawierającą zduplikowane wartości KeyShareEntry dla tej samej grupy, co prowadzi do nadmiernego zużycia CPU i pamięci.

W wolfSSL w wersji 5.8.2 i wcześniejszych występuje niewłaściwa walidacja danych wejściowych w negocjacji algorytmu podpisu CertificateVerify w TLS 1.3. Umożliwia to obniżenie (downgrade) algorytmu podpisu, np. serwer może zaakceptować ECDSA P256, gdy klient zadeklarował ECDSA P521.

Nieprawidłowa walidacja danych wejściowych podczas parsowania rozszerzenia CKS w TLS 1.3 w wolfSSL 5.8.2 i wcześniejszych na wielu platformach pozwala zdalnemu nieuwierzytelnionemu atakującemu potencjalnie wywołać odmowę usługi poprzez spreparowaną wiadomość ClientHello z zduplikowanymi rozszerzeniami CKS.