Onze octets et un fil d'exécution en attente
Quelqu'un de l'équipe rouge d'Okta a envoyé 11 octets à un serveur et l'a regardé mettre de côté 131 kilooctets. L'astuce tient à la façon dont s'ouvre une conversation TLS. Les quatre premiers octets d'un message de négociation déclarent la longueur à venir du message, et les anciennes versions d'OpenSSL croyaient cette déclaration, réservant le tampon avant l'arrivée du reste ou l'exécution de la moindre validation. Le reste du message n'est jamais arrivé. La mémoire est restée réservée et un fil d'exécution est resté à attendre des données qui ne viendraient plus.
Répété, le procédé n'a plus rien de subtil. Sur un serveur d'un gigaoctet, l'équipe a laissé 547 mégaoctets gelés en fragments inutilisables. Sur une machine de seize gigaoctets, elle a bloqué un quart de la mémoire totale. Sur les systèmes utilisant l'allocateur glibc, la mémoire ne revient pas proprement même après la déconnexion de l'attaquant, car les fragments libérés ne peuvent être réemployés. Aucun identifiant n'était requis, aucune session n'a été établie, et rien dans l'échange ne ressemblait à une attaque.
La partie qui devrait inquiéter un dirigeant plus qu'un ingénieur
OpenSSL l'a corrigé. Les versions 4.0.1, 3.6.3, 3.5.7, 3.4.6 et 3.0.21 sont toutes sorties le 9 juin 2026 avec le comportement corrigé, n'allouant la mémoire qu'à mesure que les données arrivent réellement. Trois demandes de fusion, numérotées 30792, 30793 et 30794, portaient la modification. Ensuite, plus rien pendant plus de cinq semaines. La divulgation publique a atteint la liste oss-security le 18 juillet, 39 jours après que le correctif circulait déjà.
L'équipe de sécurité a fait un choix délibéré. OpenSSL applique une échelle de gravité à quatre niveaux, de Critique à Faible, et a estimé que ce cas n'entrait dans aucun d'eux. La demande de fusion indique clairement que l'équipe a préféré traiter le signalement comme un correctif de "bogue ou de durcissement". Il n'existe donc ni identifiant CVE, ni bulletin de sécurité, ni entrée aux journaux des modifications des versions concernées. Chacune de ces absences est une décision, et chacune a supprimé un signal que le processus de quelqu'un avait été bâti pour détecter.
Le processus discipliné a perdu contre l'indiscipliné
Prenez deux entreprises. La première met à jour OpenSSL à cadence mensuelle fixe, sans regarder le contenu de la version. C'est l'approche dont une fonction sécurité mature finit souvent par se détacher, parce qu'elle consomme des fenêtres de changement pour des versions sans intérêt. Cette entreprise est protégée depuis juin et ignore avoir jamais été en risque.
La seconde hiérarchise par gravité. Elle lit les bulletins, note les CVE, avance le Critique et l'Élevé et reporte le reste avec une justification documentée. C'est l'approche qui passe un audit, satisfait un assureur et résiste à une question du conseil. Cette entreprise a regardé la version d'OpenSSL de juin, n'y a trouvé aucun contenu de sécurité et a décidé, tout à fait correctement, de ne pas y consacrer de fenêtre de changement. Elle reste exposée, et son processus a fonctionné exactement comme prévu.
La conclusion inconfortable est que corriger selon la gravité revient à externaliser ses décisions de risque vers celui qui attribue cette gravité. Ce n'est pas un reproche adressé à OpenSSL, projet largement porté par des bénévoles qui prend des décisions défendables sur une échelle à quatre niveaux qu'il ne doit à personne. C'est un constat sur le lieu réel du jugement. Si votre processus n'escalade que ce qui arrive déjà étiqueté comme dangereux, alors votre modèle de menace est en réalité la politique d'étiquetage de vos fournisseurs.
Deux choses restent vraies aujourd'hui
Le chemin DTLS a été laissé en l'état. Le corriger proprement a été jugé trop invasif pour l'instant, si bien que ce code dimensionne toujours son tampon d'après la longueur déclarée par le pair. Si vous terminez du DTLS quelque part, et c'est le cas de nombreux concentrateurs VPN, serveurs de médias WebRTC et passerelles IoT industrielles, cette exposition n'est réglée par rien de ce qui est décrit ici. Ce n'est pas non plus un secret dissimulé. C'est énoncé ouvertement dans la divulgation, ce qui constitue en soi un avertissement.
La seconde chose tient au calendrier. D'ordinaire, divulgation et correctif arrivent ensemble et défenseurs comme attaquants partent de la même ligne. Ici, le code corrigé est resté dans des commits publics pendant 39 jours avant que quiconque explique ce qu'il corrigeait. Lire une comparaison de commits n'est pas une compétence exotique. Pendant plus d'un mois, ceux qui lisent le code ont eu l'avantage sur ceux qui lisent les bulletins, et le second groupe ignorait qu'une course avait commencé.
La question à ajouter à votre prochaine revue
Ne refondez pas votre programme de vulnérabilités pour un défaut d'épuisement mémoire. Ajoutez en revanche une question récurrente à la revue que vous tenez déjà : qu'avons-nous renoncé à corriger ce trimestre parce que cela arrivait sans niveau de gravité ? Non pas ce que nous avons reporté en Faible. Ce qui n'est jamais entré dans la file parce que rien ne l'avait étiqueté. Cette liste existe dans toute organisation et presque personne ne la regarde.
Comparez ensuite vos versions d'OpenSSL à celles du 9 juin, ce qui prend quelques minutes, et notez si vous êtes couvert par politique ou par chance. La différence entre ces deux réponses est tout l'enjeu. Un contrôle qui vous protège par accident n'est pas un contrôle, et la prochaine fois que l'accident ne se produira pas, vous l'apprendrez par la voie coûteuse.
À lire ensuite: Le correctif était public 81 jours avant l'avertissement | Une requête pouvait détourner votre site WordPress
