CVE-2026-94418 in wolfSSL
Riassunto
di VulDB • 27/09/2026
Con la definizione di precompilatore `WOLFSSL_SMALL_CERT_VERIFY`, la funzione `ProcessPeerCertParse()` esegue il controllo della firma del certificato separatamente dalla fase di parsing per mantenere basso l'utilizzo massimo di memoria, quindi unisce i due risultati; tuttavia, essa incorpora nuovamente il risultato della verifica della firma solo quando il parsing restituisce 0 (esito positivo), pertanto qualsiasi errore durante la fase di parsing lo nasconde. `ParseCertRelative()` raggiunge i controlli sulla data di validità, sui vincoli del nome e sulle estensioni critiche solo dopo che `ConfirmSignature()` ha avuto esito positivo; ciò inverte la precedenza che rende "sovrascrivere gli errori della data" una politica valida (sound policy), e l'errore `ASN_SIG_CONFIRM_E` non viene mai segnalato. L'attaccante non necessita di materiale chiave proveniente dalla PKI reale né del compromesso di un CA: è sufficiente un certificato auto-firmato che contenga il nome del soggetto atteso, come emittente (issuer) il soggetto del CA attendibile, byte arbitrari nella posizione della firma, una finestra di validità nel passato e la propria coppia di chiavi dell'attaccante. Le build colpite definiscono `WOLFSSL_SMALL_CERT_VERIFY`, che è disattivato per impostazione predefinita, non viene impostato implicitamente da alcuna piattaforma o header preset e non è raggiungibile tramite nessuna opzione CMake; i percorsi autotools sono `--enable-lowresource`, `--enable-leantls`, `--enable-tinytls13=cert` e `--enable-tinytls13=mutualauth`; il file `examples/configs/user_settings_embedded.h` lo raggiunge tramite `WC_CFG_SMALL_CERT_VERIFY`, che viene distribuito con valore 0, mentre né `--enable-all` né `--enable-distro` lo abilitano affatto. L'applicazione deve inoltre installare una callback di verifica attraverso `wolfSSL_CTX_set_verify()` o `wolfSSL_set_verify()` impostando `WOLFSSL_VERIFY_PEER`, che restituisce 1 per gli errori `ASN_BEFORE_DATE_E` o `ASN_AFTER_DATE_E`; wolfSSL distribuisce esattamente questa configurazione come `myVerify()` in `wolfssl/test.h` sotto la definizione `VERIFY_OVERRIDE_DATE_ERR`, selezionata da `examples/client -D`. Un'applicazione senza callback, o il cui callback restituisce un esito di pre-verifica (preverify) per errori della data, fallisce comunque l'handshake, e le funzioni `wolfSSL_CertManagerVerifyBuffer()` e `wc_CheckCertSignature()` segnalano correttamente `ASN_SIG_CONFIRM_E` nello stesso binario. Sono interessati sia TLS 1.2 che TLS 1.3 in entrambe le direzioni, e DTLS raggiunge la stessa funzione; dove il certificato falsificato è un certificato della catena (chain certificate), l'approvazione da parte della callback ne causa la memorizzazione nella cache del gestore dei certificati `WOLFSSL_CTX`, pertanto una distribuzione esposta deve riavviare il contesto o il processo anziché limitarsi a riconnettersi.
If you want to get best quality of vulnerability data, you may have to visit VulDB.