Database CVE

Nel firmware Anjvision YSSD‑RTMP‑H5 versione 3.3.2.4, sono incorporate credenziali hardcoded dell'API cloud condivise tra i dispositivi distribuiti. Chiunque ottenga il pacchetto firmware pubblico può riutilizzare questi valori per interagire con il servizio cloud in modi non previsti dal normale funzionamento.

Nel firmware Anjvision YSSD‑RTMP‑H5 versione 3.3.2.4, sia il meccanismo di aggiornamento locale sia quello cloud applicano il nuovo firmware senza alcuna verifica crittografica, affidandosi solo a un hashing di base. Questa progettazione consente a un attaccante che può raggiungere la routine di aggiornamento di introdurre immagini firmware non attendibili che il dispositivo accetterà come valide.

Nel firmware Anjvision YSSD‑RTMP‑H5 versione 3.3.2.4, è possibile abilitare un’interfaccia di debug nascosta tramite una richiesta autenticata, consentendo di inviare comandi aggiuntivi a un servizio backend. Una volta attivo, questo percorso può esporre involontariamente funzionalità a livello di sistema che potrebbero essere utilizzate in modo improprio se input appositamente creati raggiungono il gestore dei comandi sottostante.

Nel firmware Anjvision YSSD‑RTMP‑H5 versione 3.3.2.4, diversi endpoint del servizio ONVIF elaborano richieste di gestione senza applicare i requisiti di autenticazione previsti. Ciò potrebbe consentire a un aggressore non autorizzato di accedere a operazioni sensibili del dispositivo.

TeamViewer Full Client and Host for Linux nelle versioni precedenti alla 15.82 contiene una vulnerabilità di convalida impropria del percorso nella funzionalità Cloud Session Recording (CSR). Sfruttando una condizione di competizione durante la convalida del percorso e il successivo accesso ai file, un utente malintenzionato locale autenticato può causare operazioni privilegiate sui file in posizioni non previste nel sistema interessato.

Una vulnerabilità di controllo degli accessi improprio in TeamViewer Full Client, Host e nei relativi moduli interessati su Windows, Linux e macOS consente a un aggressore remoto autenticato di aggirare le impostazioni delle autorizzazioni configurate dall’utente durante l’instaurazione della sessione. Modificando i parametri di controllo degli accessi per le funzionalità con restrizioni, un aggressore può eseguire azioni che erano state esplicitamente negate dalla configurazione della vittima. Ciò può comportare azioni non autorizzate e potenzialmente portare all’esecuzione di codice da remoto sul sistema di destinazione.

TeamViewer Full Client e Host precedenti alla versione 15.82 su Windows contengono una condizione di competizione TOCTOU nel meccanismo di rollback del programma di installazione. Un utente malintenzionato locale con privilegi limitati può sostituire i file di backup del rollback memorizzati in una directory temporanea scrivibile dall'utente prima che vengano ripristinati da un programma di installazione con privilegi elevati, ottenendo così un'escalation dei privilegi a NT AUHORITY/SYSTEM. Lo sfruttamento richiede che la condizione di competizione venga temporizzata con successo e che si verifichi un rollback durante l'installazione o l'aggiornamento.

TeamViewer Full Client e Host per Linux e macOS, nelle versioni precedenti alla 15.82, contengono una vulnerabilità di buffer overflow basata su heap nell'elaborazione dei file di registrazione delle sessioni .tvs. Una discrepanza nelle dimensioni durante la decompressione dei dati della sessione registrata può causare scritture heap fuori dai limiti. Convincendo un utente ad aprire una registrazione di sessione appositamente creata tramite la funzionalità "Riproduci o converti la sessione registrata…", un utente malintenzionato può ottenere l'esecuzione di codice arbitrario con i privilegi dell'utente corrente.

Riepilogo del problema: un peer remoto malintenzionato può inondare lo stack QUIC locale con frame NEW_CONNECTION_ID eludendo un controllo del limite sul numero di ID di connessione che lo stack QUIC remoto può usare. Riepilogo dell’impatto: lo stack QUIC locale invia un frame RETIRE_CONN_ID per ogni frame NEW_CONNECTION_ID che riceve. Il frame RETIRE_CONN_ID viene inoltrato tramite la Control Frame Queue (CFQ). Se il peer remoto omette anche gli ACK, può costringere lo stack locale ad allocare ~400MB (a seconda del ritardo degli ACK). CWE: CWE-770: Allocazione di risorse senza limiti o limitazioni Descrizione: le sezioni 5.1.1 e 5.1.2 dell’RFC 9000 [1] descrivono il meccanismo con cui un peer remoto può notificare allo stack QUIC locale di cambiare l’ID di connessione di destinazione (detto anche CID) che lo stack locale usa per identificare la connessione presso il peer remoto. Ogni CID è associato a un numero di sequenza. Il numero di sequenza viene trasmesso nei frame NEW_CONNECTION_ID e RETIRE_CONNECTION_ID per identificare il CID che viene associato a una connessione o ritirato. Il peer remoto invia un frame NEW_CONNECTION_ID per comunicare allo stack locale che un nuovo CID viene associato a una connessione esistente. Il frame NEW_CONNECTION_ID contiene il nuovo CID, il relativo numero di sequenza e il numero retire-prior-to. Il valore retire-prior-to identifica i CID esistenti da ritirare. Lo stack QUIC locale deve inviare un RETIRE_CONNECTION_ID per ogni CID di destinazione il cui numero di sequenza è inferiore a retire-prior-to. Il CID viene ritirato dopo che lo stack locale riceve un ACK per il relativo frame RETIRE_CONNECTION_ID. Sebbene lo stack QUIC di OpenSSL supporti al massimo un CID di destinazione per ogni connessione, può essere indotto a elaborare più di un frame RETIRE_CONNECTION_ID per connessione. Attualmente, lo stack QUIC di OpenSSL ritira il CID di destinazione non appena riceve il NEW_CONNECTION_ID, mentre in realtà il CID di destinazione deve essere ritirato dopo aver ricevuto un ACK per il frame RETIRE_CONNECTION_ID. La correzione della logica difettosa risolve anche la crescita dell’arretrato. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids Impatto FIPS: no Il modulo FIPS non è interessato, poiché l’implementazione QUIC è al di fuori del perimetro del modulo FIPS di OpenSSL.

Riepilogo del problema: Il primo uso concorrente dello stesso certificato X.509 da parte di diversi thread può causare la liberazione dei dati delle estensioni memorizzati nella cache mentre un altro thread li sta ancora usando. Riepilogo dell'impatto: Un peer remoto non autenticato potrebbe causare l'arresto anomalo di un client TLS multithread, o di un server TLS multithread che richiede certificati client, se le prime catene di certificati costruite fino allo stesso certificato CA attendibile vengono costruite da più connessioni contemporaneamente. Si tratta di una lettura use-after-free, che probabilmente causerà l'arresto anomalo del processo, con conseguente Denial of Service. CWE: CWE-416: Use After Free Descrizione: OpenSSL memorizza nella cache i valori decodificati delle estensioni X.509v3 di un certificato all'interno dell'oggetto X509 la prima volta che sono necessari. In OpenSSL 4.0 questa cache viene costruita in due fasi: i valori delle estensioni vengono calcolati mantenendo un lock di lettura sul certificato, e i risultati vengono quindi installati nel certificato con un lock di scrittura. Poiché un lock di lettura non esclude altri lettori, diversi thread possono calcolare contemporaneamente la cache per lo stesso certificato. Ogni thread che acquisisce successivamente il lock di scrittura installa i propri risultati e libera i valori installati dal thread precedente, anche se quel thread precedente ha già contrassegnato la cache come completa e potrebbe aver restituito al chiamante puntatori al suo interno. Un chiamante che sta ancora usando quei puntatori legge quindi memoria liberata. Qualsiasi certificato condiviso tra thread è esposto la prima volta che le sue estensioni vengono decodificate. In TLS, i certificati a rischio sono i certificati CA attendibili forniti per la verifica della catena, con qualsiasi mezzo, poiché sono condivisi da ogni connessione e le loro estensioni vengono decodificate e memorizzate nella cache la prima volta che viene costruita una catena che li include. I certificati inviati dal peer vengono decodificati separatamente per ogni connessione e non sono condivisi, quindi non sono interessati. In un client TLS che verifica i certificati del server, o in un server TLS che richiede e verifica i certificati client, l'use-after-free potrebbe verificarsi solo se le prime catene costruite fino alla stessa CA attendibile vengono costruite da più connessioni contemporaneamente. Impatto su FIPS: no Il modulo FIPS non è interessato, poiché la gestione dei certificati X.509 è esterna al perimetro del modulo FIPS di OpenSSL. OpenSSL 4.0 è vulnerabile a questo problema. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 e 1.0.2 non sono interessati da questo problema. Gli utenti di OpenSSL 4.0 dovrebbero aggiornare a OpenSSL 4.0.3. Questo problema è stato segnalato il 27 agosto 2026 da Tim Becker (Xint.io) e, indipendentemente, in una segnalazione pubblica il 31 agosto 2026 da aydinmercan. La correzione è stata sviluppata da Bob Beck. -- taglio (metadati non pubblicati per uso interno) -- Segnalato da: Tim Becker (Xint.io), aydinmercan Corretto da: Bob Beck

Riepilogo del problema: la logica di ritrasmissione DTLS non gestisce correttamente una scrittura di un messaggio handshake sospesa a metà. Il messaggio ritrasmesso può essere letto oltre il buffer del messaggio e la ritrasmissione sovrascrive lo stato interno necessario alla scrittura sospesa per riprendere correttamente. Riepilogo dell'impatto: il messaggio ritrasmesso può divulgare memoria heap al peer sotto forma di dati handshake in chiaro oppure causare un crash e un Denial of Service quando la lettura raggiunge una regione di memoria non mappata. CWE: CWE-125: Lettura fuori dai limiti Descrizione: i messaggi handshake DTLS possono essere scritti in più frammenti e una scrittura può sospendersi a metà messaggio (restituendo WANT_WRITE) se il trasporto sottostante non può temporaneamente accettare altri dati. Mentre una scrittura è sospesa, il timer di ritrasmissione DTLS può attivarsi indipendentemente e chiedere alla logica di ritrasmissione di reinviare un messaggio precedente, già riconosciuto come inviato, dalla sua coda di ritrasmissione. La logica di ritrasmissione riutilizzava lo stesso buffer interno e lo stesso tracciamento della posizione del messaggio ancora in fase di scrittura, senza reimpostare la posizione all'inizio del messaggio da ritrasmettere. Di conseguenza, la ritrasmissione veniva letta a partire dal punto in cui la scrittura sospesa si era interrotta, producendo un messaggio etichettato erroneamente, il cui corpo era costituito da byte residui dell'altro messaggio, più grande, ancora in transito: contenuti che non avrebbero dovuto essere inviati in quel momento e che potevano oltrepassare la fine del buffer allocato. Inoltre, anche quando la ritrasmissione è posizionata correttamente, lasciarla completare mentre un'altra scrittura è sospesa sovrascrive gli stessi dati di gestione dello stato condivisi da cui dipende la scrittura sospesa per riprendere. Quando in seguito l'applicazione riprende la scrittura sospesa (tramite una successiva chiamata a SSL_read(), SSL_write(), SSL_accept() o SSL_connect()), rileva che tali dati di gestione si trovano in uno stato incoerente con il messaggio e interrompe il processo in una build di debug. La correzione reimposta la posizione di lettura della ritrasmissione all'inizio del messaggio prima del reinvio e salta del tutto la ritrasmissione ogni volta che una scrittura handshake è ancora sospesa, rimandandola alla chiamata successiva che la riprende. Impatto FIPS: no Il codice interessato è al di fuori del perimetro del modulo FIPS.

Riepilogo del problema: la generazione delle firme SM2 utilizza operazioni aritmetiche non a tempo costante su valori segreti, creando un canale laterale temporale. Riepilogo dell'impatto: un attaccante in grado di misurare i tempi di firma SM2 può apprendere informazioni sul nonce segreto di ciascuna firma, che, nel caso di molte firme, possono portare al recupero della chiave privata tramite un attacco reticolare / Hidden Number Problem. CWE: CWE-208: discrepanza temporale osservabile Descrizione: la generazione delle firme SM2 calcola il valore della firma utilizzando operazioni BIGNUM a tempo variabile sul nonce segreto e sulla chiave privata, quindi il tempo necessario a produrre una firma SM2 dipende da questi valori segreti, creando un canale laterale temporale. Le applicazioni che eseguono la generazione di firme SM2 sono interessate su tutte le piattaforme. Impatto FIPS: no SM2 non è un algoritmo FIPS.

Riepilogo del problema: un’associazione DTLS 1.2 stabilita che utilizza una suite di cifratura AEAD può essere terminata da un singolo datagramma non autenticato il cui frammento cifrato è più corto dell’overhead obbligatorio dell’IV esplicito e del tag di autenticazione. Riepilogo dell’impatto: un attaccante in grado di inviare un datagramma che viene instradato verso un’associazione DTLS 1.2 esistente può interrompere tale associazione senza conoscere alcun materiale delle chiavi. Si tratta di un attacco denial of service limitato all’associazione presa di mira. Non vi sono impatti sulla sicurezza della memoria né sulla riservatezza. CWE: CWE-1284: Convalida impropria della quantità specificata nell’input Descrizione: In TLS 1.2 e DTLS 1.2 ogni record protetto da una suite di cifratura AEAD contiene un IV esplicito seguito dal testo cifrato e da un tag di autenticazione. Durante la decifratura di un record di questo tipo, il livello dei record passava la lunghezza del record all’implementazione del cifrario prima di verificare che il record fosse abbastanza lungo da contenere l’IV esplicito e il tag. Per un record più corto di tale overhead, l’implementazione del cifrario rifiutava la lunghezza impossibile e il livello dei record considerava ciò un errore interno e generava un alert fatale internal_error invece di trattare il record come non autenticato. In TLS 1.2 lo stesso record provoca un alert fatale internal_error invece dell’alert previsto bad_record_mac. Poiché qualsiasi record non decifrabile termina già una connessione TLS, in TLS si tratta di un problema di conformità al protocollo anziché di sicurezza. La correzione convalida la lunghezza del record rispetto alla lunghezza dell’IV esplicito e del tag prima di qualsiasi elaborazione AEAD, in modo che TLS segnali bad_record_mac e DTLS scarti silenziosamente il record. Impatto FIPS: no Il codice interessato è al di fuori dei confini del modulo FIPS.

Riepilogo del problema: Un client CMP che richiede la revoca di un certificato sulla base di una CSR PKCS#10 può dereferenziare un puntatore NULL e terminare in modo anomalo durante l'elaborazione di una risposta di revoca appositamente predisposta. Riepilogo dell'impatto: La dereferenziazione del puntatore NULL avviene durante una lettura, causando un crash e una negazione del servizio per l'applicazione client interessata. CWE: CWE-476: dereferenziazione di un puntatore NULL Descrizione: Un client CMP che revoca un certificato deve indicare al server quale certificato revocare e può farlo fornendo una CSR PKCS#10 invece del certificato stesso o del nome del suo emittente e del numero di serie. Si tratta di 'openssl cmp -cmd rr -csr <file>' dalla riga di comando, oppure di OSSL_CMP_exec_RR_ses() con il certificato fornito tramite OSSL_CMP_CTX_set1_p10CSR() attraverso l'API. Una CSR non contiene il nome dell'emittente e il numero di serie del certificato, quindi il client non li invia. Un server può indicare facoltativamente nella propria risposta il certificato revocato; il client confronta quindi tale nome con quello che ha inviato. Non avendo inviato né un nome dell'emittente né un numero di serie, non ha nulla con cui confrontarlo; se il server restituisce un nome appositamente predisposto, il client legge da un puntatore NULL e va in crash. La risposta di revoca viene verificata per accertare la validità della protezione del messaggio prima che venga raggiunto il codice interessato, quindi l'autore dell'attacco deve essere un server CMP malevolo o compromesso, oppure un man-in-the-middle in possesso del segreto usato per la protezione del messaggio. I client che identificano il certificato da revocare tramite il certificato stesso o tramite l'emittente e il numero di serie, anziché tramite una CSR PKCS#10, non sono interessati. Impatto su FIPS: no Nessun modulo FIPS è interessato da questo problema, poiché l'implementazione del protocollo CMP si trova al di fuori del perimetro del modulo FIPS di OpenSSL.

Riepilogo del problema: lo stack QUIC di OpenSSL non applica il controllo del flusso a livello di connessione per gli stream. I peer remoti possono inviare più byte, purché rientrino nei limiti del controllo del flusso degli stream. Riepilogo dell'impatto: un peer remoto malevolo può sfruttare l'assenza del controllo del flusso a livello di connessione per gli stream per far ricevere allo stack QUIC circa 100MB di memoria invece di 768 KiB (dimensione predefinita della finestra di controllo del flusso). CWE: CWE-770: Allocazione di risorse senza limiti o limitazione della velocità Descrizione: lo stack QUIC locale pubblicizza al peer remoto due limiti di controllo del flusso: il limite di controllo del flusso degli stream e il limite di controllo del flusso della connessione. Il peer remoto deve rispettare entrambi i limiti durante la trasmissione dei dati degli stream. Ogni volta che lo stack QUIC locale riceve un frame di stream, verifica che le dimensioni del frame di stream ricevuto rientrino nei limiti di controllo del flusso. Se uno dei due limiti viene superato (a livello di stream o a livello di connessione), lo stack QUIC deve chiudere la connessione con un errore di controllo del flusso. Lo stack QUIC vulnerabile di OpenSSL applica il limite a livello di stream, ma non quello a livello di connessione. Per sfruttare il problema, devono essere soddisfatte tre condizioni: - il peer remoto apre diversi stream - ogni stream deve rispettare il limite di controllo del flusso a livello di stream - nessuno stream deve trasmettere byte con offset zero (per impedire allo stack QUIC vulnerabile di consumare dati). Soddisfacendo le condizioni precedenti, il peer remoto può far allocare allo stack locale 2 x MAX_STREAMS x (limite di controllo del flusso degli stream) byte di memoria. MAX_STREAMS è impostato a 100 per impostazione predefinita e il limite si applica sia agli stream bidirezionali sia a quelli unidirezionali, per un totale di 200. La finestra predefinita di controllo del flusso per uno stream è di 512kB. Il peer remoto può costringere lo stack QUIC vulnerabile ad allocare 100MB di heap per connessione. Impatto FIPS: no Il modulo FIPS non è interessato, poiché l'implementazione QUIC è al di fuori del perimetro del modulo FIPS di OpenSSL.

Riepilogo del problema: un server TLS che chiama SSL_set_SSL_CTX() per passare una connessione a un SSL_CTX diverso nel corso di un handshake può accedere a memoria oltre la fine di un array interno se il contesto sostitutivo conosce più algoritmi di firma del provider rispetto al contesto da cui è stata creata la connessione. Le applicazioni che non chiamano mai SSL_set_SSL_CTX() non sono interessate. Riepilogo dell’impatto: un peer remoto potrebbe causare una piccola lettura fuori dai limiti e, in alcune circostanze, una scrittura fuori dai limiti di valore fisso nell’heap del server. Ciò può provocare una negazione del servizio. CWE: CWE-787: Scrittura fuori dai limiti Descrizione: una connessione TLS registra il numero di slot per certificati di cui dispone al momento della creazione, in base all’SSL_CTX che l’ha creata: i tipi di certificato incorporati più uno slot per ogni voce TLS-SIGALG del provider nota al contesto. Questo numero determina la dimensione di un array interno di flag di validità dei certificati, uno per slot. Un’applicazione può sostituire l’SSL_CTX di una connessione nel corso dell’handshake chiamando SSL_set_SSL_CTX(), più comunemente da un callback servername per servire un host virtuale diverso. Questa operazione non aggiornava il numero registrato. L’indice dello slot di un algoritmo di firma del provider corrisponde alla sua posizione nell’elenco del contesto che lo risolve; pertanto, se il contesto sostitutivo ne conosce più di quello originale, un algoritmo offerto dal peer può essere risolto in un indice oltre la fine dell’array. L’elaborazione degli algoritmi di firma del peer legge quindi una parola di quattro byte oltre la fine per ciascuno di questi algoritmi e, quando la parola letta è zero, la sovrascrive con un valore fisso. Un peer che ne offre molti può corrompere i metadati dell’heap e causare l’interruzione del processo. Questo effetto si verifica solo con gli algoritmi di firma del provider che occupano uno degli slot in eccesso e che sono anche configurati sul server. I codepoint che il contesto sostitutivo non riconosce vengono scartati senza essere risolti in uno slot; inoltre, gli algoritmi di firma del provider sono utilizzabili solo da TLS 1.3. I due contesti devono quindi conoscere numeri diversi di algoritmi di firma del provider, il che richiede contesti di libreria separati, un provider caricato tra la creazione dei due contesti oppure provider che differiscono per ciò che pubblicizzano: in 4.0, ad esempio, il provider predefinito pubblicizza SM2, mentre il provider FIPS no. Una distribuzione che soddisfi questa condizione non è inoltre in grado di negoziare gli algoritmi interessati con client legittimi, poiché lo stesso numero obsoleto nasconde i certificati corrispondenti; è quindi probabile che la configurazione errata venga notata. Per questo motivo, e poiché la configurazione non è quella predefinita, il problema è stato valutato come di gravità bassa. Impatto FIPS: no Nessun modulo FIPS è interessato da questo problema, poiché il codice interessato è esterno ai confini del modulo FIPS di OpenSSL.

Riepilogo del problema: sulle piattaforme ARM64 e RISC-V, per le operazioni con chiave privata SM2 viene utilizzata un’implementazione ottimizzata non a tempo costante della moltiplicazione scalare di punti. Riepilogo dell’impatto: un aggressore in grado di misurare il tempo impiegato oppure di osservare il pattern di accesso alle linee di cache durante la firma o la decifratura SM2 su una piattaforma interessata può ricavare informazioni sullo scalare segreto. CWE: CWE-208: Discrepanza temporale osservabile Descrizione: sui processori ARM64 e RISC-V, la curva SM2 utilizza un’implementazione ottimizzata della moltiplicazione scalare, le cui diramazioni condizionali e ricerche nelle tabelle vengono scelte in base ai bit dello scalare segreto. Il tempo di esecuzione e il pattern di accesso alla cache dipendono quindi dalla chiave privata a lungo termine (durante la decifratura SM2) o dal nonce usato per ogni firma (durante la generazione di una firma SM2), generando un canale laterale temporale e basato sulla cache. Impatto su FIPS: no SM2 non è un algoritmo FIPS e l’implementazione SM2 ottimizzata non fa parte del modulo FIPS. OpenSSL 4.0, 3.6, 3.5 e 3.4 sono vulnerabili a questo problema su AArch64 e RISC-V. OpenSSL 3.0, 1.1.1 e 1.0.2 non sono interessati da questo problema. Gli utenti di OpenSSL 4.0 dovrebbero aggiornare a OpenSSL 4.0.3. Gli utenti di OpenSSL 3.6 dovrebbero aggiornare a OpenSSL 3.6.5. Gli utenti di OpenSSL 3.5 dovrebbero aggiornare a OpenSSL 3.5.9. Gli utenti di OpenSSL 3.4 dovrebbero aggiornare a OpenSSL 3.4.8. Questo problema è stato segnalato il 2 maggio 2026 da Abhinav Agarwal. È stato segnalato in modo indipendente il 6 giugno 2026 da Feng Xue. La correzione è stata sviluppata da Igor Ustinov. -- cut (metadati non destinati alla pubblicazione, per uso interno) -- Segnalato da: Abhinav Agarwal, Feng Xue Corretto da: Igor Ustinov

Riepilogo del problema: la moltiplicazione scalare generica su curve ellittiche usata per le operazioni di firma ECDSA e SM2 con curve che non dispongono di un’implementazione dedicata divulga informazioni sul nonce segreto attraverso i tempi di esecuzione. Riepilogo dell’impatto: un attaccante in grado di misurare i tempi di firma può apprendere informazioni sul nonce segreto usato per ciascuna firma; con un numero elevato di firme, ciò può portare al recupero della chiave privata tramite un attacco basato su reticolo / Hidden Number Problem. CWE: CWE-208: discrepanza temporale osservabile Descrizione: la moltiplicazione scalare generica su curve ellittiche usata per le curve che non dispongono di un’implementazione dedicata a tempo costante aggiunge padding allo scalare segreto mediante operazioni BIGNUM non a tempo costante, perciò il tempo impiegato dipende dal valore dello scalare segreto derivato dal nonce ECDSA e SM2. La perdita è molto ridotta; osservarla richiede un gran numero di misurazioni. L’effetto è maggiore per le curve il cui ordine del gruppo cade su un confine di parola macchina, come brainpoolP384r1. Le applicazioni che usano la firma ECDSA sulle curve Brainpool e su altre curve prime generiche, nonché la firma SM2 sulle piattaforme che usano l’implementazione generica, sono vulnerabili a questo problema. Le curve NIST P-256, P-384 e P-521 usano implementazioni dedicate a tempo costante e non sono interessate. Impatto FIPS: no I moduli FIPS non sono interessati: le curve NIST approvate usate nel provider FIPS dispongono di implementazioni dedicate a tempo costante e non usano il percorso del codice interessato.

Riepilogo del problema: il server QUIC di OpenSSL, se configurato per non eseguire la convalida dell'indirizzo, può essere costretto a conteggiare più volte i pacchetti in ingresso nel calcolo del credito non convalidato, causando la violazione del limite di amplificazione della connessione non convalidata pari a 3 volte la quantità di dati ricevuti, stabilito da RFC 9000. Riepilogo dell'impatto: un attaccante remoto in grado di contraffare pacchetti diretti a un server che utilizza l'implementazione QUIC di OpenSSL potrebbe usare il server per amplificare un attacco DDoS. CWE: CWE-440: Violazione del comportamento previsto Descrizione: lo stack QUIC di OpenSSL, quando opera come server, applica la convalida dell'indirizzo del client (RFC 9000, Sezione 8) per confermare che l'indirizzo del peer non venga usato per un attacco di amplificazione del traffico. Se questa funzionalità è disabilitata sul server, lo stack QUIC limita la quantità di dati del server che possono essere inviati a 3 volte la quantità di dati ricevuti dall'indirizzo del peer, fino al completamento dell'handshake TLS. Il server QUIC di OpenSSL, quando opera in modalità senza convalida, aggiunge la lunghezza dell'intero datagramma ricevuto al limite del credito non convalidato durante l'elaborazione di ciascun pacchetto QUIC nel datagramma. Un peer remoto può, dopo aver stabilito una connessione con un frame client hello iniziale, inviare un datagramma successivo contenente più pacchetti QUIC, facendo sì che il server conteggi la lunghezza dell'intero datagramma per ciascun pacchetto in esso contenuto. Di conseguenza, il server ritiene che il peer abbia inviato più dati di quanti ne abbia effettivamente inviati, violando così il limite di amplificazione 3x imposto dalla RFC. Impatto FIPS: no Poiché lo stack QUIC si trova al di fuori del perimetro del modulo FIPS, nessun modulo FIPS è interessato da questa CVE.

Riepilogo del problema: Un certificato con numerosi punti di distribuzione CRL nameRelativeToCRLIssuer causa una crescita sproporzionata dell'heap quando OpenSSL memorizza nella cache le estensioni X.509. Riepilogo dell'impatto: La ricezione di un certificato appositamente predisposto da un peer malevolo può causare una notevole pressione sulla memoria e una possibile Denial of Service nei client o nei server che richiedono certificati client. CWE: CWE-770: Allocazione di risorse senza limiti o limitazione della frequenza Descrizione: Un certificato o un insieme di certificati che rientra nel limite dimensionale dei certificati accettati dal peer (~100 KiB) può causare l'allocazione di diverse centinaia di MiB di memoria residente sul lato ricevente durante un normale handshake TLS. Ciò può essere sufficiente a causare un crash del client o del server, se più connessioni simultanee provocano allocazioni di memoria altrettanto elevate. La correzione posticipa l'elaborazione delle estensioni dei punti di distribuzione CRL nei certificati fino al momento in cui il valore elaborato è necessario per l'elaborazione CRL. Ciò evita di mantenere a lungo grandi allocazioni di memoria quando vengono ricevuti certificati di questo tipo. Impatto FIPS: no Il codice interessato è esterno al perimetro del modulo FIPS.