Un défaut de retransmission DTLS dans OpenSSL peut divulguer des données du tas ou provoquer l’arrêt d’applications

Faille CVE-2026-84782 DTLS OpenSSL : retransmission défectueuse exposant mémoire du tas ou crash applicatif. Correctifs disponibles.

Un défaut de retransmission DTLS dans OpenSSL peut divulguer des données du tas ou provoquer l’arrêt d’applications
Vulnérabilités

Image d’illustration générée par IA

Des retransmissions défectueuses entraînent deux risques distincts

OpenSSL a révélé une faille de gravité élevée dans son implémentation de Datagram Transport Layer Security (DTLS), qui peut exposer la mémoire du tas à un pair distant ou faire planter le processus concerné.

Répertoriée sous le numéro CVE-2026-84782, la vulnérabilité touche les retransmissions de messages de négociation DTLS. OpenSSL a publié des correctifs le 29 septembre et a classé le problème comme étant de gravité élevée, un niveau en dessous de « critique » sur son échelle de gravité.

Laurent Gaffie, de Secorizon, a signalé la vulnérabilité le 17 août. Ryan Hooper a développé le correctif.

Le 29 septembre, la CISA a attribué à CVE-2026-84782 un score CVSS de 8,2 sur 10, selon le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H. Cette évaluation décrit une faille exploitable à distance, qui ne nécessite ni privilèges ni interaction de l’utilisateur et présente un faible impact sur la confidentialité, mais un fort impact sur la disponibilité.

OpenSSL n’utilise pas les scores CVSS pour établir ses propres niveaux de gravité et précise que les évaluations externes peuvent différer sensiblement des siennes.

Au moment de la publication de la fiche de la CISA, aucune exploitation n’était signalée. OpenSSL n’avait fait état d’aucune attaque et aucune échéance de correction n’avait été fixée dans le catalogue des vulnérabilités exploitées connues de la CISA.

Comment une négociation DTLS interrompue expose des données mémoire inappropriées

DTLS adapte les protections de TLS aux protocoles de transport par datagrammes, comme UDP. Il peut servir à sécuriser les canaux de données WebRTC et à établir des clés de chiffrement pour les appels sur Internet.

Les messages de négociation DTLS volumineux doivent être répartis en fragments suffisamment petits pour tenir dans des datagrammes UDP individuels. Si une connexion cesse temporairement d’accepter de nouvelles données, OpenSSL peut suspendre l’envoi alors qu’il n’a transmis qu’une partie d’un message.

Le délai de retransmission peut expirer pendant cette pause. OpenSSL doit alors renvoyer un message de négociation précédent. Or, le code vulnérable peut reprendre à la position actuelle du tampon du message volumineux dont l’envoi est suspendu, au lieu de repartir du début du message à retransmettre.

Ce décalage d’état produit des données de négociation mal formées. Le message retransmis reçoit une étiquette incorrecte et peut contenir des octets résiduels appartenant au message plus volumineux stocké dans le tampon.

Le traitement de ces données mal formées peut alors entraîner une lecture au-delà des limites prévues du tampon. Selon OpenSSL, le contenu du tas peut être envoyé au pair sous la forme de données de négociation non chiffrées. Si la lecture hors limites atteint une zone mémoire non mappée, l’application peut s’arrêter.

Deux conséquences sont donc possibles : une divulgation limitée de la mémoire du processus et un déni de service. L’avis USN-8847-1 d’Ubuntu décrit un comportement incorrect de la négociation et un déni de service, mais ne mentionne pas l’exposition de la mémoire du tas signalée par OpenSSL.

Le risque ne concerne pas exclusivement les clients ou les serveurs DTLS. OpenSSL a testé son correctif dans les deux rôles. L’entreprise n’a toutefois pas précisé si un attaquant pouvait provoquer de manière fiable une retransmission au moment précis où l’envoi d’un autre message de négociation est suspendu.

Les versions corrigées laissent peu de solutions aux branches non prises en charge

Toutes les versions antérieures à la version corrigée indiquée ci-dessous sont vulnérables dans chaque branche répertoriée :

Branche OpenSSL Version corrigée Disponibilité et état de la prise en charge
4.0 4.0.3 Disponible publiquement ; prise en charge jusqu’au 14 mai 2027
3.6 3.6.5 Disponible publiquement ; prise en charge jusqu’au 1er novembre 2026
3.5 3.5.9 Version LTS disponible publiquement ; prise en charge jusqu’au 8 avril 2030
3.4 3.4.8 Disponible publiquement ; prise en charge jusqu’au 22 octobre 2026
3.0 3.0.23 Réservée aux clients bénéficiant de l’assistance premium ; fin de la prise en charge publique le 7 septembre 2026
1.1.1 1.1.1zj Réservée aux clients bénéficiant de l’assistance premium ; aucune prise en charge publique
1.0.2 1.0.2zs Réservée aux clients bénéficiant de l’assistance premium ; aucune prise en charge publique

OpenSSL n’a pas établi si les branches 3.1, 3.2 et 3.3 étaient vulnérables. Elles ne bénéficient plus d’une prise en charge publique.

La situation d’OpenSSL 3.0 est particulièrement importante pour les organisations qui compilent elles-mêmes la bibliothèque ou l’intègrent à d’autres produits. Sa dernière version publique était la 3.0.22, publiée le 25 août. La version 3.0.23 est la première mise à jour de sécurité de cette branche qu’OpenSSL réserve à une diffusion non publique.

Cette mise à jour, réservée aux clients bénéficiant de l’assistance premium, corrige six des 14 vulnérabilités résolues le 29 septembre, dont CVE-2026-84782. Les organisations qui utilisent encore la branche OpenSSL 3.0 ne peuvent donc pas obtenir le correctif officiel en accès public.

OpenSSL recommande de migrer vers une branche prise en charge, notamment la 4.0 ou la branche 3.5 bénéficiant d’une assistance à long terme, ou de souscrire à une offre d’assistance. Aucun contournement n’a été publié pour les environnements dans lesquels la mise à jour est impossible.

Ubuntu et Debian distribuent des correctifs rétroportés

Les versions des paquets des distributions Linux ne correspondent pas nécessairement aux numéros des versions corrigées en amont, car les responsables de la maintenance rétroportent souvent les correctifs de sécurité.

Ubuntu Security a publié l’avis USN-8847-1 le 29 septembre 2026. Il concerne Ubuntu 26.04 LTS, 24.04 LTS et 22.04 LTS. Les paquets corrigés sont les suivants :

Version d’Ubuntu Paquet Version corrigée du paquet
26.04 LTS (resolute) libssl3t64 3.5.5-1ubuntu3.6
24.04 LTS (noble) libssl3t64 3.0.13-0ubuntu3.16
22.04 LTS (jammy) libssl3 3.0.2-0ubuntu1.30

Les utilisateurs d’Ubuntu doivent effectuer une mise à jour standard du système, puis le redémarrer afin que tous les services et processus en cours d’exécution chargent les bibliothèques corrigées. La simple installation du paquet peut laisser des applications actives depuis longtemps continuer à utiliser le code vulnérable déjà chargé en mémoire.

Ubuntu Pro offre dix ans de couverture de sécurité pour plus de 25 000 paquets des dépôts Main et Universe. Le service est gratuit pour un maximum de cinq machines.

Debian a corrigé CVE-2026-84782 dans Debian 13 avec la version 3.5.7-1~deb13u3 du paquet openssl, publiée dans le cadre de DSA-6531-1. Le 30 septembre à 07:36 UTC, le suivi de sécurité de Debian indiquait toujours que Debian 12 était vulnérable.

Les administrateurs doivent recenser les usages de DTLS, et pas seulement les installations d’OpenSSL

La faille ne concerne que les logiciels qui utilisent l’implémentation DTLS d’OpenSSL. La présence d’un paquet OpenSSL installé ne suffit pas à établir qu’une application emprunte le chemin de code vulnérable.

Les équipes de défense doivent recenser les services accessibles depuis Internet ou depuis le réseau interne qui utilisent DTLS, notamment les logiciels de communication et les composants liés à WebRTC. Elles doivent également examiner les appliances, les conteneurs, les programmes liés statiquement et les produits de fournisseurs susceptibles d’intégrer leur propre copie d’OpenSSL au lieu d’utiliser le paquet du système d’exploitation.

Il convient de donner la priorité aux applications accessibles à distance dont un plantage interromprait des communications en temps réel ou un autre service sensible à la disponibilité. Une divulgation de données du tas est également possible, même si ni le type ni la quantité de mémoire récupérable en pratique n’ont été établis.

Aucun indicateur de compromission spécifique n’a été publié. Des plantages inexpliqués pendant des négociations DTLS, des messages de négociation retransmis mal formés ou des échecs de connexion répétés peuvent justifier une enquête, mais ne constituent pas des preuves confirmées d’exploitation.

La même version corrige 13 autres vulnérabilités

Les mises à jour du 29 septembre ont également corrigé 13 autres failles d’OpenSSL. La plus grave d’entre elles, avec CVE-2026-84782, est CVE-2026-84783, une vulnérabilité de gravité modérée qui ne concerne qu’OpenSSL 4.0.

Un pair distant non authentifié peut exploiter cette faille pour faire planter certains clients ou serveurs TLS multithread qui demandent des certificats client. Pour que le problème se produise, plusieurs connexions doivent construire simultanément leur première chaîne de certificats jusqu’au même certificat d’autorité de certification de confiance. Le score CVSS est de 7,5, avec le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

CVE-2026-75806, classée de gravité faible par OpenSSL et notée 5,3, permet à un attaquant de mettre fin à une connexion DTLS 1.2 établie utilisant une suite de chiffrement AEAD. Un seul datagramme trop court peut déclencher l’échec, sans que l’attaquant ait besoin de connaître les clés de la connexion.

Les autres failles de gravité faible comprennent cinq problèmes liés à l’implémentation QUIC d’OpenSSL et trois canaux auxiliaires temporels affectant les opérations ECDSA ou SM2. Ubuntu a également documenté, parmi les correctifs intégrés, des défauts entraînant des dénis de service, des lectures hors limites, une consommation excessive de mémoire et des problèmes de traitement des certificats.

Les organisations qui appliquent le correctif de CVE-2026-84782 doivent donc déployer l’intégralité de la mise à jour fournie par leur fournisseur plutôt que d’essayer d’isoler un seul correctif. Cette version corrige en même temps un ensemble plus vaste de failles susceptibles d’être exploitées à distance.

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

CVE traitées dans cet article

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →