Base de données CVE

Dans la version 3.3.2.4 du firmware Anjvision YSSD‑RTMP‑H5, les mécanismes de mise à jour locale et dans le cloud appliquent un nouveau firmware sans aucune vérification cryptographique, en s’appuyant uniquement sur un hachage élémentaire. Cette conception permet à un attaquant pouvant accéder à la routine de mise à jour d’introduire des images de firmware non fiables que l’appareil acceptera comme valides.

Dans le firmware Anjvision YSSD‑RTMP‑H5 version 3.3.2.4, une interface de débogage cachée peut être activée au moyen d’une requête authentifiée, permettant d’envoyer des commandes supplémentaires à un service backend. Une fois cette voie activée, elle peut exposer involontairement des fonctionnalités au niveau système qui pourraient être utilisées à mauvais escient si des entrées spécialement conçues parviennent au gestionnaire de commandes sous-jacent.

Dans le firmware Anjvision YSSD‑RTMP‑H5 version 3.3.2.4, plusieurs points de terminaison du service ONVIF traitent les requêtes de gestion sans imposer l’authentification requise. Cela pourrait permettre à un attaquant non autorisé d’accéder à des opérations sensibles de l’appareil.

TeamViewer Full Client and Host for Linux dans les versions antérieures à 15.82 présente une vulnérabilité liée à une validation incorrecte du chemin dans la fonctionnalité Cloud Session Recording (CSR). En exploitant une condition de concurrence lors de la validation du chemin et de l’accès ultérieur au fichier, un attaquant local authentifié peut provoquer des opérations privilégiées sur des fichiers dans des emplacements non prévus du système affecté.

Une vulnérabilité de contrôle d’accès inadéquat dans TeamViewer Full Client, Host et les modules concernés associés sur Windows, Linux et macOS permet à un attaquant distant authentifié de contourner les paramètres d’autorisation configurés par l’utilisateur lors de l’établissement d’une session. En modifiant les paramètres de contrôle d’accès des fonctionnalités restreintes, un attaquant peut effectuer des actions explicitement interdites par la configuration de la victime. Cela peut entraîner des actions non autorisées et potentiellement conduire à l’exécution de code à distance sur le système cible.

TeamViewer Full Client and Host antérieurs à la version 15.82 sous Windows contiennent une condition de concurrence TOCTOU dans le mécanisme de retour arrière du programme d’installation. Un attaquant local disposant de faibles privilèges peut remplacer les fichiers de sauvegarde du retour arrière stockés dans un répertoire temporaire accessible en écriture par l’utilisateur avant leur restauration par un programme d’installation exécuté avec des privilèges élevés, ce qui entraîne une élévation de privilèges vers NT AUHORITY/SYSTEM. L’exploitation nécessite de synchroniser avec succès la condition de concurrence et qu’un retour arrière se produise pendant l’installation ou la mise à jour.

TeamViewer Full Client and Host pour Linux et macOS, dans les versions antérieures à 15.82, contiennent une vulnérabilité de heap-based buffer overflow dans le traitement des fichiers d’enregistrement de session .tvs. Une différence de taille lors de la décompression des données de session enregistrées peut entraîner des écritures hors limites dans le tas. En convainquant un utilisateur d’ouvrir un enregistrement de session spécialement conçu à l’aide de la fonctionnalité « Play or convert recorded session… », un attaquant peut parvenir à exécuter du code arbitraire avec les privilèges de l’utilisateur actuel.

Résumé du problème : Un pair distant malveillant peut inonder la pile QUIC locale de trames NEW_CONNECTION_ID en contournant une vérification de limite portant sur le nombre d’identifiants de connexion que la pile QUIC distante peut utiliser. Résumé de l’impact : La pile QUIC locale envoie une trame RETIRE_CONN_ID pour chaque trame NEW_CONNECTION_ID qu’elle reçoit. La trame RETIRE_CONN_ID est distribuée via la Control Frame Queue (CFQ). Si le pair distant retient également les ACK, il peut alors forcer la pile locale à allouer ~400MB (en fonction du délai des ACK). CWE : CWE-770 : Allocation de ressources sans limites ni limitation de débit Description : Les sections 5.1.1 et 5.1.2 de la RFC 9000 [1] décrivent le mécanisme par lequel un pair distant peut notifier à la pile QUIC locale de modifier l’identifiant de connexion de destination (également appelé CID) que la pile locale utilise pour identifier la connexion chez le pair distant. Chaque CID est associé à un numéro de séquence. Le numéro de séquence est transmis dans les trames NEW_CONNECTION_ID et RETIRE_CONNECTION_ID pour identifier le CID qui est associé à une connexion ou retiré. Le pair distant envoie une trame NEW_CONNECTION_ID pour informer la pile locale qu’un nouveau CID est associé à une connexion existante. La trame NEW_CONNECTION_ID contient le nouveau CID, son numéro de séquence et le numéro retire-prior-to. Le numéro retire-prior-to identifie les CID existants qui doivent être retirés. La pile QUIC locale doit envoyer un RETIRE_CONNECTION_ID pour chaque CID de destination dont le numéro de séquence est inférieur à retire-prior-to. Le CID est retiré lorsque la pile locale reçoit un ACK pour sa trame RETIRE_CONNECTION_ID. Bien que la pile QUIC OpenSSL ne prenne en charge qu’un seul CID de destination par connexion au maximum, elle peut être amenée à traiter plusieurs trames RETIRE_CONNECTION_ID par connexion. La pile QUIC OpenSSL retire actuellement le CID de destination dès qu’elle reçoit le NEW_CONNECTION_ID, alors qu’en réalité, le CID de destination ne doit être retiré qu’après réception d’un ACK pour la trame RETIRE_CONNECTION_ID. Corriger cette logique erronée corrige également la croissance de la file d’attente. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids Impact sur FIPS : non Le module FIPS n’est pas affecté, car l’implémentation QUIC se trouve en dehors du périmètre du module FIPS OpenSSL.

Résumé du problème : La première utilisation concurrente du même certificat X.509 par plusieurs threads peut entraîner la libération de ses données d’extension mises en cache alors qu’un autre thread les utilise encore. Résumé de l’impact : Un pair distant non authentifié pourrait faire planter un client TLS multithread, ou un serveur TLS multithread qui demande des certificats clients, si les premières chaînes de certificats construites jusqu’au même certificat d’AC de confiance sont construites par plusieurs connexions en même temps. Il s’agit d’une lecture après libération (use-after-free), qui est susceptible de faire planter le processus et d’entraîner un déni de service. CWE : CWE-416 : Use After Free Description : OpenSSL met en cache les valeurs décodées des extensions X.509v3 d’un certificat dans l’objet X509 la première fois qu’elles sont nécessaires. Dans OpenSSL 4.0, ce cache est construit en deux phases : les valeurs des extensions sont calculées en détenant un verrou en lecture sur le certificat, puis les résultats sont installés dans le certificat sous un verrou en écriture. Comme un verrou en lecture n’exclut pas les autres lecteurs, plusieurs threads peuvent calculer le cache du même certificat en même temps. Chaque thread qui acquiert ensuite le verrou en écriture installe ses propres résultats et libère les valeurs installées par le thread précédent, alors même que ce dernier a déjà marqué le cache comme complet et a pu renvoyer à son appelant des pointeurs vers celui-ci. Un appelant qui utilise encore ces pointeurs lit alors de la mémoire libérée. Tout certificat partagé entre plusieurs threads est exposé la première fois que ses extensions sont décodées. Dans TLS, les certificats à risque sont les certificats d’AC de confiance fournis pour la vérification de la chaîne, par quelque moyen que ce soit, puisqu’ils sont partagés par toutes les connexions et que leurs extensions sont décodées et mises en cache la première fois qu’une chaîne est construite jusqu’à eux. Les certificats envoyés par le pair sont décodés séparément pour chaque connexion et ne sont pas partagés ; ils ne sont donc pas concernés. Dans un client TLS qui vérifie les certificats du serveur, ou dans un serveur TLS qui demande et vérifie les certificats clients, la lecture après libération ne pourrait se produire que si les premières chaînes construites jusqu’à la même AC de confiance sont construites par plusieurs connexions en même temps. Impact sur FIPS : non Le module FIPS n’est pas concerné, car la gestion des certificats X.509 se situe hors des limites du module FIPS d’OpenSSL. OpenSSL 4.0 est vulnérable à ce problème. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 et 1.0.2 ne sont pas concernés par ce problème. Les utilisateurs d’OpenSSL 4.0 doivent mettre à niveau vers OpenSSL 4.0.3. Ce problème a été signalé le 27 août 2026 par Tim Becker (Xint.io), puis indépendamment dans un signalement public le 31 août 2026 par aydinmercan. Le correctif a été développé par Bob Beck. -- coupure (métadonnées non publiées à usage interne) -- Signalé par : Tim Becker (Xint.io), aydinmercan Corrigé par : Bob Beck

Résumé du problème : La logique de retransmission DTLS ne gère pas correctement l’écriture d’un message de handshake suspendue en cours de route. Le message retransmis peut être lu au-delà du tampon de message et la retransmission écrase l’état interne dont l’écriture suspendue a besoin pour reprendre correctement. Résumé de l’impact : Le message retransmis peut divulguer au pair de la mémoire du tas sous forme de données de handshake en clair ou provoquer un crash et un déni de service lorsque la lecture atteint une région mémoire non mappée. CWE : CWE-125: Out-of-bounds Read Description : Les messages de handshake DTLS peuvent être écrits en plusieurs fragments, et une écriture peut être suspendue en cours de message (en renvoyant WANT_WRITE) si le transport sous-jacent ne peut temporairement pas accepter davantage de données. Tant qu’une telle écriture est suspendue, le minuteur de retransmission DTLS peut se déclencher indépendamment et demander à la logique de retransmission de renvoyer un message antérieur, déjà confirmé comme envoyé, provenant de sa file d’attente de retransmission. La logique de retransmission réutilisait le même tampon interne et le même suivi de position que le message toujours en cours d’écriture, sans réinitialiser la position au début du message en cours de retransmission. Par conséquent, la retransmission commençait à être lue à partir de l’endroit où l’écriture suspendue s’était arrêtée, produisant un message mal étiqueté dont le corps était constitué d’octets résiduels provenant de l’autre message, plus volumineux, toujours en cours de transmission — contenu qui n’était pas censé être envoyé à ce moment-là et qui pouvait dépasser la fin du tampon alloué. Par ailleurs, même lorsque la retransmission est correctement positionnée, la laisser aller jusqu’à son terme alors qu’une autre écriture est suspendue écrase les mêmes informations de suivi partagées dont dépend l’écriture suspendue pour reprendre. Lorsque l’application reprend ensuite l’écriture suspendue (via un appel ultérieur à SSL_read(), SSL_write(), SSL_accept() ou SSL_connect()), elle constate que ces informations de suivi sont dans un état incohérent avec le message et interrompt le processus dans une version de débogage. Le correctif réinitialise la position de lecture de la retransmission au début du message avant de le renvoyer, et ignore entièrement la retransmission chaque fois qu’une écriture de handshake est toujours suspendue, en la reportant au prochain appel qui la reprend. Impact FIPS : non Le code concerné se trouve hors de la limite du module FIPS.

Résumé du problème : la génération de signatures SM2 utilise une arithmétique à temps non constant sur des valeurs secrètes, créant un canal auxiliaire temporel. Résumé de l’impact : un attaquant capable de mesurer les temps de signature SM2 peut apprendre des informations sur le nonce secret propre à chaque signature, ce qui, après de nombreuses signatures, peut conduire, via une attaque par réseau / le problème du nombre caché, à la récupération de la clé privée. CWE : CWE-208 : Écart temporel observable Description : la génération de signatures SM2 calcule la valeur de signature à l’aide d’opérations BIGNUM à temps variable sur le nonce secret et la clé privée, de sorte que le temps nécessaire pour produire une signature SM2 dépend de ces valeurs secrètes, créant un canal auxiliaire temporel. Les applications effectuant la génération de signatures SM2 sont affectées sur toutes les plateformes. Impact FIPS : aucun SM2 n’est pas un algorithme FIPS.

Résumé du problème : Une association DTLS 1.2 établie utilisant une suite de chiffrement AEAD peut être terminée par un seul datagramme non authentifié dont le fragment chiffré est plus court que la surcharge obligatoire de l’IV explicite et du tag d’authentification. Résumé de l’impact : Un attaquant capable d’envoyer un datagramme acheminé vers une association DTLS 1.2 existante peut mettre fin à cette association sans connaître aucun élément de clé. Il s’agit d’un déni de service limité à l’association ciblée. Il n’y a aucun impact sur la sécurité mémoire ou la confidentialité. CWE : CWE-1284 : Validation incorrecte de la quantité spécifiée en entrée Description : En TLS 1.2 et DTLS 1.2, chaque enregistrement protégé par une suite de chiffrement AEAD contient un IV explicite suivi du texte chiffré et d’un tag d’authentification. Lors du déchiffrement d’un tel enregistrement, la couche d’enregistrement transmettait la longueur de l’enregistrement à l’implémentation du chiffrement avant de vérifier que l’enregistrement était suffisamment long pour contenir l’IV explicite et le tag. Pour un enregistrement plus court que cette surcharge, l’implémentation du chiffrement rejetait la longueur impossible, et la couche d’enregistrement traitait cela comme une défaillance interne et déclenchait une alerte fatale internal_error au lieu de traiter l’enregistrement comme ayant échoué à l’authentification. En TLS 1.2, le même enregistrement provoque une alerte fatale internal_error au lieu de l’alerte bad_record_mac attendue. Comme tout enregistrement impossible à déchiffrer met déjà fin à une connexion TLS, il s’agit d’un problème de conformité au protocole plutôt que d’un problème de sécurité en TLS. Le correctif valide la longueur de l’enregistrement par rapport à la longueur de l’IV explicite et du tag avant tout traitement AEAD, afin que TLS signale bad_record_mac et que DTLS écarte silencieusement l’enregistrement. Impact sur FIPS : non Le code concerné se trouve hors des limites du module FIPS.

Résumé du problème : Un client CMP qui demande la révocation d’un certificat sur la base d’une CSR PKCS#10 peut déréférencer un pointeur NULL et se terminer de manière anormale lors du traitement d’une réponse de révocation spécialement conçue. Résumé de l’impact : Le déréférencement du pointeur NULL se produit lors d’une lecture, ce qui provoque un crash et un déni de service pour l’application cliente concernée. CWE : CWE-476 : déréférencement de pointeur NULL Description : Un client CMP qui révoque un certificat doit indiquer au serveur quel certificat révoquer, et peut le faire en fournissant une CSR PKCS#10 au lieu du certificat lui-même ou de son nom d’émetteur et de son numéro de série. Il s’agit de « openssl cmp -cmd rr -csr <file> » sur la ligne de commande, ou de OSSL_CMP_exec_RR_ses() avec le certificat fourni via OSSL_CMP_CTX_set1_p10CSR() par l’intermédiaire de l’API. Une CSR ne contient ni le nom de l’émetteur ni le numéro de série du certificat ; le client ne les envoie donc pas. Un serveur peut éventuellement indiquer dans sa réponse le certificat qu’il a révoqué, et le client compare alors ce nom à celui qu’il a envoyé. N’ayant envoyé ni nom d’émetteur ni numéro de série, il n’a rien à comparer, et un serveur qui renvoie un nom spécialement conçu amène le client à lire à partir d’un pointeur NULL et à planter. La protection valide du message de la réponse de révocation est vérifiée avant que le code concerné ne soit atteint ; un attaquant doit donc être un serveur CMP malveillant ou compromis, ou un attaquant de type homme du milieu disposant du secret utilisé pour la protection des messages. Les clients qui identifient le certificat à révoquer au moyen d’un certificat ou du nom de l’émetteur et du numéro de série, plutôt qu’au moyen d’une CSR PKCS#10, ne sont pas concernés. Impact FIPS : non Aucun module FIPS n’est concerné par ce problème, car l’implémentation du protocole CMP se situe en dehors du périmètre du module FIPS d’OpenSSL.

Résumé du problème : La pile QUIC d’OpenSSL n’applique pas le contrôle de flux au niveau de la connexion pour les flux. Les pairs distants peuvent envoyer davantage d’octets tant qu’ils respectent les limites du contrôle de flux des flux. Résumé de l’impact : Un pair distant malveillant peut exploiter l’absence de contrôle de flux au niveau de la connexion pour les flux afin de faire recevoir à la pile QUIC ~100MB de mémoire au lieu de 768 KiB (taille de fenêtre de contrôle de flux par défaut). CWE : CWE-770: Allocation de ressources sans limites ni régulation Description : La pile QUIC locale annonce deux limites de contrôle de flux à son pair distant : la limite de contrôle de flux du flux et la limite de contrôle de flux de la connexion. Le pair distant doit respecter les deux limites lors de la transmission des données des flux. Chaque fois que la pile QUIC locale reçoit une trame de flux, elle vérifie que la taille de la trame de flux reçue reste dans les limites du contrôle de flux. Si l’une des limites est dépassée (au niveau du flux ou de la connexion), la pile QUIC doit fermer la connexion avec une erreur de contrôle de flux. La pile QUIC vulnérable d’OpenSSL applique la limite au niveau du flux, mais pas celle au niveau de la connexion. Pour exploiter le problème, trois conditions doivent être réunies : - le pair distant ouvre plusieurs flux - chaque flux doit respecter la limite de contrôle de flux au niveau du flux - aucun octet avec un décalage nul ne doit être envoyé sur aucun des flux (pour empêcher la pile QUIC vulnérable de consommer des données). En réunissant les conditions ci-dessus, le pair distant peut faire allouer à la pile locale 2 x MAX_STREAMS x (limite de contrôle de flux du flux) octets de mémoire. MAX_STREAMS a une valeur par défaut de 100, et la limite s’applique aux flux bidirectionnels et unidirectionnels, ce qui en fait 200 au total. La fenêtre de contrôle de flux par défaut d’un flux est de 512kB. Le pair distant peut contraindre la pile QUIC vulnérable à allouer 100MB de tas par connexion. Impact sur FIPS : non Le module FIPS n’est pas affecté, car l’implémentation QUIC se trouve en dehors du périmètre du module FIPS d’OpenSSL.

Résumé du problème : Un serveur TLS qui appelle SSL_set_SSL_CTX() pour basculer une connexion vers un autre SSL_CTX en cours de négociation peut accéder à de la mémoire au-delà de la fin d’un tableau interne si le contexte de remplacement connaît davantage d’algorithmes de signature de fournisseur que le contexte à partir duquel la connexion a été créée. Les applications qui n’appellent jamais SSL_set_SSL_CTX() ne sont pas concernées. Résumé de l’impact : Un pair distant peut être en mesure de provoquer une petite lecture hors limites et, dans certaines circonstances, une écriture hors limites d’une valeur fixe sur le tas du serveur. Cela peut entraîner un déni de service. CWE : CWE-787 : Écriture hors limites Description : Une connexion TLS enregistre le nombre d’emplacements de certificat dont elle dispose lors de sa création, nombre tiré du SSL_CTX qui l’a créée : les types de certificat intégrés, plus un emplacement pour chaque entrée TLS-SIGALG de fournisseur dont ce contexte avait connaissance. Ce nombre détermine la taille d’un tableau interne d’indicateurs de validité de certificat par emplacement. Une application peut remplacer le SSL_CTX d’une connexion en cours de négociation en appelant SSL_set_SSL_CTX(), le plus souvent depuis un callback servername afin de servir un autre hôte virtuel. Cette opération ne mettait pas à jour le nombre enregistré. L’indice d’emplacement d’un algorithme de signature de fournisseur correspond à sa position dans la liste du contexte qui le résout ; ainsi, si le contexte de remplacement en connaît davantage que le contexte d’origine, un algorithme proposé par le pair peut être résolu en un indice au-delà de la fin du tableau. Le traitement des algorithmes de signature du pair lit alors un mot de quatre octets au-delà de la fin pour chaque algorithme de ce type et, lorsque le mot lu vaut zéro, écrit une valeur fixe à cet emplacement. Un pair qui en propose un grand nombre peut corrompre les métadonnées du tas et provoquer l’arrêt du processus. Seuls les algorithmes de signature de fournisseur qui occupent l’un des emplacements excédentaires et que le serveur a également configurés ont cet effet. Les points de code que le contexte de remplacement ne reconnaît pas sont écartés sans être résolus en emplacement, et les algorithmes de signature de fournisseur ne sont utilisables qu’à partir de TLS 1.3. Les deux contextes doivent donc connaître des nombres différents d’algorithmes de signature de fournisseur, ce qui nécessite des contextes de bibliothèque distincts, le chargement d’un fournisseur entre la création des deux contextes, ou des fournisseurs qui diffèrent par ce qu’ils annoncent — dans la version 4.0, par exemple, le fournisseur par défaut annonce SM2, contrairement au fournisseur FIPS. Un déploiement répondant à cette condition ne peut pas non plus négocier les algorithmes concernés avec des clients légitimes, car le même nombre obsolète masque les certificats correspondants ; cette mauvaise configuration est donc susceptible d’être détectée. Pour cette raison, et parce que cette configuration n’est pas celle par défaut, ce problème a été évalué comme étant de gravité faible. Impact FIPS : non Aucun module FIPS n’est concerné par ce problème, car le code concerné se trouve en dehors de la frontière du module FIPS OpenSSL.

Résumé du problème : Une implémentation optimisée à temps non constant de la multiplication scalaire de points est utilisée pour les opérations avec clé privée SM2 sur les plateformes ARM64 et RISC-V. Résumé de l’impact : Un attaquant capable de mesurer le temps nécessaire à la signature ou au déchiffrement SM2, ou d’observer le schéma d’accès aux lignes de cache sur une plateforme affectée, peut obtenir des informations sur le scalaire secret. CWE : CWE-208 : Écart de temps observable Description : Sur les processeurs ARM64 et RISC-V, la courbe SM2 utilise une implémentation optimisée de la multiplication scalaire dont les branchements conditionnels et les accès aux tables sont choisis en fonction des bits du scalaire secret. Le temps d’exécution et le schéma d’accès au cache dépendent donc de la clé privée à long terme (lors du déchiffrement SM2) ou du nonce par signature (lors de la génération d’une signature SM2), ce qui constitue un canal auxiliaire temporel et lié au cache. Impact FIPS : non SM2 n’est pas un algorithme FIPS et l’implémentation SM2 optimisée ne fait pas partie du module FIPS. OpenSSL 4.0, 3.6, 3.5 et 3.4 sont vulnérables à ce problème sur AArch64 et RISC-V. OpenSSL 3.0, 1.1.1 et 1.0.2 ne sont pas affectés par ce problème. Les utilisateurs d’OpenSSL 4.0 doivent effectuer une mise à niveau vers OpenSSL 4.0.3. Les utilisateurs d’OpenSSL 3.6 doivent effectuer une mise à niveau vers OpenSSL 3.6.5. Les utilisateurs d’OpenSSL 3.5 doivent effectuer une mise à niveau vers OpenSSL 3.5.9. Les utilisateurs d’OpenSSL 3.4 doivent effectuer une mise à niveau vers OpenSSL 3.4.8. Ce problème a été signalé le 2 mai 2026 par Abhinav Agarwal. Il a été signalé indépendamment le 6 juin 2026 par Feng Xue. Le correctif a été développé par Igor Ustinov. -- coupure (métadonnées non destinées à la publication, pour usage interne) -- Signalé par : Abhinav Agarwal, Feng Xue Corrigé par : Igor Ustinov

Résumé du problème : La multiplication scalaire générique sur courbe elliptique utilisée pour les opérations de signature ECDSA et SM2 avec des courbes ne disposant pas d’une implémentation dédiée divulgue des informations sur le nonce secret par le biais du temps d’exécution. Résumé de l’impact : Un attaquant capable de mesurer les temps de signature peut apprendre des informations sur le nonce secret propre à chaque signature, ce qui, sur un grand nombre de signatures, peut conduire à la récupération de la clé privée au moyen d’une attaque par réseau / problème du nombre caché. CWE : CWE-208: Écart de temps observable Description : La multiplication scalaire générique sur courbe elliptique utilisée pour les courbes ne disposant pas d’une implémentation dédiée à temps constant complète le scalaire secret à l’aide d’opérations BIGNUM à temps non constant, de sorte que le temps d’exécution dépend de la valeur du scalaire secret dérivée du nonce ECDSA et SM2. La fuite est très faible ; son observation nécessite un grand nombre de mesures. L’effet est le plus important pour les courbes dont l’ordre du groupe se situe à la limite d’un mot machine, telles que brainpoolP384r1. Les applications qui utilisent la signature ECDSA sur les courbes Brainpool et d’autres courbes génériques à nombres premiers, ainsi que la signature SM2 sur les plateformes utilisant l’implémentation générique, sont vulnérables à ce problème. Les courbes NIST P-256, P-384 et P-521 utilisent des implémentations dédiées à temps constant et ne sont pas concernées. Impact FIPS : non Les modules FIPS ne sont pas concernés : les courbes NIST approuvées utilisées dans le fournisseur FIPS disposent d’implémentations dédiées à temps constant et n’utilisent pas le chemin de code concerné.

Résumé du problème : Le serveur QUIC OpenSSL, lorsqu’il est configuré pour ne pas effectuer de validation d’adresse, peut être contraint de comptabiliser plusieurs fois les paquets entrants dans son calcul du crédit non validé, entraînant une violation de la limite d’amplification de connexion non validée de 3 fois la quantité de données reçues définie par la RFC 9000. Résumé de l’impact : Un attaquant distant capable d’usurper des paquets à destination d’un serveur utilisant l’implémentation QUIC OpenSSL pourrait utiliser ce serveur pour amplifier une attaque DDoS. CWE : CWE-440: Violation du comportement attendu Description : La pile QUIC d’OpenSSL, lorsqu’elle fonctionne en tant que serveur, impose la validation de l’adresse du client (RFC 9000, Section 8) afin de confirmer que l’adresse du pair n’est pas utilisée pour une attaque par amplification du trafic. Si cette fonctionnalité est désactivée sur le serveur, la pile QUIC limite la quantité de données du serveur pouvant être envoyées à 3 fois la quantité de données reçues depuis l’adresse du pair, jusqu’à la fin de la négociation TLS. Le serveur QUIC OpenSSL, lorsqu’il fonctionne en mode sans validation, ajoute la longueur du datagramme entier reçu à la limite du crédit non validé lors du traitement de chaque paquet QUIC contenu dans le datagramme. Un pair distant peut, après avoir établi une connexion avec une trame client hello initiale, envoyer un datagramme ultérieur contenant plusieurs paquets QUIC, conduisant le serveur à comptabiliser la longueur entière du datagramme pour chaque paquet qu’il contient, de sorte que le serveur croit que le pair a envoyé plus de données qu’en réalité, violant ainsi la limite d’amplification de 3x imposée par la RFC. Impact FIPS : non Comme la pile QUIC se trouve en dehors des limites du module FIPS, aucun module FIPS n’est affecté par ce CVE.

Résumé du problème : Un certificat comportant de nombreux points de distribution de CRL nameRelativeToCRLIssuer entraîne une croissance disproportionnée du tas lorsque OpenSSL met en cache les extensions X.509. Résumé de l’impact : La réception d’un certificat conçu de manière malveillante par un pair malveillant peut entraîner une forte pression sur la mémoire et un possible déni de service chez les clients ou les serveurs qui demandent des certificats client. CWE : CWE-770 : Allocation de ressources sans limites ni régulation Description : Un certificat ou un ensemble de certificats dont la taille reste inférieure à la limite des certificats acceptés du pair (~100 KiB) peut entraîner l’allocation de plusieurs centaines de MiB de mémoire résidente côté réception lors d’une négociation TLS normale. Cela peut suffire à faire planter le client ou le serveur si plusieurs connexions simultanées entraînent des allocations de mémoire aussi importantes. Le correctif reporte le traitement des extensions des points de distribution de CRL dans les certificats jusqu’au moment où la valeur traitée est nécessaire au traitement des CRL. Cela évite de conserver longtemps d’importantes allocations de mémoire lorsque de tels certificats sont reçus. Impact FIPS : non Le code concerné se trouve hors du périmètre du module FIPS.

Une validation incorrecte des chemins dans le service IPC local de TeamViewer Full Client et Host sur Windows, Linux et macOS antérieurs à la version 15.82 permet à un utilisateur local authentifié disposant de faibles privilèges d’effectuer des écritures arbitraires de fichiers avec des privilèges élevés (NT AUTHORITY/SYSTEM \ root). En envoyant des commandes IPC spécialement conçues au démon du service local, un attaquant pouvait manipuler les chemins de fichiers, entraînant une élévation locale des privilèges.