Une faille dans la gestion de la négociation DTLS d’OpenSSL pouvait envoyer des fragments de la mémoire d’une application à l’autre extrémité de la connexion.
OpenSSL a divulgué et corrigé la vulnérabilité de gravité élevée, suivie sous l’identifiant CVE-2026-84782, le 29 septembre. Son avis de sécurité indique que le bug peut exposer de la mémoire du tas sous forme de données de négociation en clair ou faire planter un processus affecté, provoquant un déni de service.
Pour les équipes de sécurité, la première question est de savoir quelles applications utilisent la sécurité de la couche transport des datagrammes (DTLS) d’OpenSSL, un protocole qui sécurise le trafic par datagrammes, généralement au-dessus d’UDP. La faille se produit lorsqu’OpenSSL retransmet un message de négociation alors qu’une autre écriture de négociation est suspendue. Les équipes doivent donc vérifier comment leurs applications utilisent DTLS.
Comment la faille DTLS expose la mémoire
Le problème se produit lorsqu’un message de négociation n’est écrit que partiellement parce que le transport sous-jacent ne peut temporairement plus accepter de données. Si un minuteur de retransmission expire alors que cette écriture est suspendue, OpenSSL peut renvoyer un message précédent en utilisant une position incorrecte dans un tampon partagé.
Cette position obsolète peut faire en sorte que la retransmission inclue des octets inattendus et lise au-delà du tampon alloué. Ces octets peuvent parvenir au pair sans chiffrement ; la lecture d’une zone de mémoire non mappée peut au contraire faire planter le processus.
L’avis décrit également une défaillance distincte dans laquelle la retransmission écrase les informations de suivi nécessaires pour reprendre l’écriture suspendue. Sa reprise peut interrompre le processus dans une version de débogage. Le correctif rétablit la position de retransmission et reporte celle-ci tant qu’une écriture de négociation reste suspendue.
OpenSSL avait déjà corrigé des vulnérabilités susceptibles de permettre l’exécution de code à distance en janvier. Les impacts documentés de cette faille DTLS sont la divulgation de mémoire et le déni de service ; l’avis n’identifie pas l’exécution de code à distance comme une conséquence.
Quelles versions d’OpenSSL doivent être mises à jour ?
L’avis d’OpenSSL répertorie les cibles de mise à niveau suivantes pour les branches concernées :
Branche OpenSSL | Version corrigée |
|---|---|
4.0 | 4.0.3 |
3.6 | 3.6.5 |
3.5 | 3.5.9 |
3.4 | 3.4.8 |
3.0 | 3.0.23 |
1.1.1 | 1.1.1zj |
1.0.2 | 1.0.2zs |
L’avis classe les correctifs pour les versions 3.0, 1.1.1 et 1.0.2 dans le support premium.
Les organisations qui utilisent des paquets fournis par une distribution doivent consulter l’avis de sécurité de leur distributeur plutôt que d’évaluer l’état du correctif uniquement à partir du numéro de version en amont. Ubuntu, par exemple, répertorie des correctifs dans des paquets tels que 3.0.13-0ubuntu3.16 pour Ubuntu 24.04 LTS et 3.0.2-0ubuntu1.30 pour Ubuntu 22.04 LTS.
Ce que les équipes de sécurité doivent faire maintenant
Une réponse concrète commence par l’identification des applications qui utilisent des versions concernées d’OpenSSL et par la détermination de leur utilisation ou non de DTLS. Lorsqu’elles interrogent leurs fournisseurs au sujet de l’exposition et des mises à jour disponibles, les équipes doivent inclure les produits gérés par les fournisseurs ainsi que les applications intégrant des copies de bibliothèques.
Les équipes peuvent utiliser des outils de gestion des vulnérabilités pour faciliter la découverte et le suivi de la remédiation, puis confirmer l’exposition propre à chaque application avec les développeurs ou les fournisseurs. La détection d’une bibliothèque constitue un point de départ pour l’analyse.
Appliquez la mise à jour appropriée, fournie par le projet en amont, la distribution ou le fournisseur, testez les services concernés et vérifiez que le déploiement a réussi. Ces vérifications doivent s’inscrire dans un processus de gestion des correctifs couvrant l’inventaire, la priorisation, les tests et la validation après mise à jour.
Pour les défenseurs, la conclusion est concrète : déterminer où le code DTLS concerné est utilisé, désigner un responsable pour chaque mise à jour et confirmer que l’application utilise bien la bibliothèque corrigée.
Pour en savoir plus : Découvrez comment une faille critique de GitLab dans GraphQL pourrait exposer des dépôts publics à la suppression et à la falsification.