Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-125 : lecture hors limites, la fuite qui ne casse rien

CWE-125 : lecture hors limites, la fuite qui ne casse rien

Section intitulée « CWE-125 : lecture hors limites, la fuite qui ne casse rien »

Huitième du CWE Top 25 2025, et sœur jumelle de l’écriture hors limites à un verbe près. Le libellé officiel est Out-of-bounds Read, « lecture hors limites » ; le catalogue admet l’abréviation OOB read. La définition est la plus courte du Top 25 : le produit lit des données au-delà de la fin, ou avant le début, du tampon prévu.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Section intitulée « Ce que la classe recouvre exactement »

Même géométrie que l’écriture hors limites, conséquence opposée. Là où l’écriture corrompt la mémoire du voisin, la lecture la divulgue : le programme continue de fonctionner normalement, et ce qui sort de lui contient des données qui ne lui appartenaient pas.

Le catalogue couvre les deux directions. La sur-lecture, au-delà de la fin, est le cas courant : une longueur annoncée plus grande que la zone réellement remplie, et le programme recopie le surplus depuis ce qui traînait derrière. La sous-lecture, avant le début, provient d’un indice négatif ou d’un décalage mal calculé.

Trois conséquences sont à distinguer, parce qu’elles n’ont pas la même gravité :

  • le plantage, lorsque la lecture sort de la mémoire attribuée au processus : c’est le cas le plus visible, donc le plus vite corrigé ;
  • la divulgation d’information, lorsque la lecture reste dans la mémoire du processus : clés, jetons de session, fragments de requêtes d’autres utilisateurs, et surtout adresses mémoire ;
  • le contournement des protections, lorsque les adresses divulguées servent à défaire la disposition aléatoire de la mémoire. C’est le rôle le plus précieux de cette classe dans une chaîne d’attaque : elle ne donne pas le contrôle, elle donne la carte.

C’est ce dernier point qui explique que cette faiblesse, apparemment bénigne, accompagne si souvent une écriture hors limites dans un même rapport : l’une renseigne, l’autre agit.

Sa place dans l’arbre

Section intitulée « Sa place dans l’arbre »

CWE-125 est une base, fille de la classe CWE-119 (« restriction incorrecte des opérations dans les limites d’un tampon mémoire »), qui est aussi le parent de l’écriture hors limites. Les deux branches de la famille mémoire partent donc du même nœud, et c’est à ce nœud qu’il faut remonter pour comprendre qu’il s’agit d’un seul type d’erreur : opérer sur un tampon sans respecter ses bornes.

Deux variantes la précisent : CWE-126, la sur-lecture, et CWE-127, la sous-lecture. L’exemple historique le plus connu appartient à la première : la vulnérabilité d’OpenSSL publiée en 2014 sous l’identifiant CVE-2014-0160, qui laissait un client demander jusqu’à soixante-quatre kilo-octets de mémoire du serveur en annonçant une longueur supérieure à celle des données réellement envoyées. Le serveur ne plantait pas, ne journalisait rien, et répondait poliment avec le contenu de sa propre mémoire : clés privées comprises. Une classe à faible gravité apparente, un incident mondial.

Pourquoi elle est si haut

Section intitulée « Pourquoi elle est si haut »

Parce qu’elle est le produit direct du test automatisé. La génération d’entrées aléatoires appliquée à un parseur fait planter le programme sur une lecture hors limites bien avant de produire une écriture exploitable. Les campagnes de test massives menées sur les bibliothèques de décodage (images, polices, vidéos, formats d’archive) en publient par séries entières.

Parce que les bibliothèques concernées sont partout. Un décodeur d’images est embarqué dans un navigateur, un système d’exploitation, un téléphone, une liseuse et un serveur de messagerie. Une seule faiblesse se décline alors en autant d’avis de sécurité, chacun avec son identifiant, ce que le classement compte sans les regrouper.

Parce que la gravité est très variable, donc moyenne. Elle ne monte pas plus haut dans le classement parce qu’une bonne partie de ces vulnérabilités ne produit qu’un déni de service. Son rang 8 est le résultat d’une fréquence énorme multipliée par une gravité modérée : l’inverse du profil de l’écriture hors limites.

Le mécanisme, et où le site le traite

Section intitulée « Le mécanisme, et où le site le traite »

Les fondations sont traitées par le site : comment un débordement écrase la pile décrit l’organisation d’un tampon et de son voisinage, qui est exactement ce que la lecture hors limites divulgue.

Pour les protections, ASLR, DEP, NX, canaris et CFI explique la disposition aléatoire de la mémoire : et donc ce que l’attaquant gagne à la connaître. C’est le lien à garder en tête : une divulgation d’adresses n’est pas une fuite d’information anodine, c’est la neutralisation d’une protection.

Enfin, Rust et la sécurité mémoire par construction décrit la vérification des bornes à l’exécution, qui transforme cette classe en erreur contrôlée plutôt qu’en lecture silencieuse.

Pour la version grandeur nature, Cloudbleed raconte une lecture hors limites logée dans un proxy partagé par des millions de sites : rien n’a planté, et la mémoire des uns partait poliment chez les visiteurs des autres.

Ce qu’une équipe en fait

Section intitulée « Ce qu’une équipe en fait »

Ne jamais croire une longueur annoncée. C’est la leçon de 2014, et elle se généralise : toute taille reçue de l’extérieur doit être comparée à la taille réellement disponible avant de servir à quoi que ce soit. Les protocoles qui transportent leur propre longueur sont les premiers concernés.

Effacer les tampons réutilisés. Une zone de mémoire remise dans un pool conserve ce qu’elle contenait ; la remettre à zéro avant réemploi réduit considérablement la valeur de la fuite. Pour les secrets, l’effacement après usage est la règle, même sans défaut connu.

Tester les parseurs par génération d’entrées, avec un analyseur mémoire activé. C’est la seule méthode qui trouve ces défauts à l’échelle, et elle a l’avantage d’être automatisable sans compétence en sécurité.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Une équipe qui classe les lectures hors limites parmi les bogues de stabilité les traite par ordre de nuisance : celles qui plantent sont corrigées, celles qui ne plantent pas restent. C’est l’inverse de l’ordre utile. Une lecture qui plante se voit ; une lecture qui réussit ne laisse aucune trace, ni dans les journaux applicatifs, ni dans la supervision, et rend des données d’autres utilisateurs à qui sait quoi demander. Le coût réel se paie en deux temps : d’abord la fuite, impossible à quantifier après coup puisque rien n’a été enregistré, on ne peut donc ni rassurer, ni notifier avec précision ; ensuite la perte des protections mémoire, car les adresses divulguées suppriment le bénéfice de leur disposition aléatoire et rendent exploitable un second défaut qu’on croyait seulement gênant.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Un programme réserve en mémoire des espaces de taille déterminée pour y ranger ses données, et ces espaces sont contigus : juste après l’un commence celui d’autre chose. Lorsque le programme lit son espace, il doit savoir où s’arrêter.

Si quelqu’un lui annonce une taille plus grande que la réalité, et que le programme la croit, il lit au-delà de son espace et récupère ce qui se trouvait derrière : des fragments appartenant à d’autres parties du logiciel. Il les renvoie alors comme s’ils étaient le résultat normal de la demande. Rien n’est cassé, aucun message d’erreur n’apparaît, et le logiciel continue de fonctionner parfaitement.

C’est le défaut que le catalogue CWE appelle CWE-125, « lecture hors limites ». Son cousin, l’écriture hors limites, abîme la mémoire du voisin ; celui-ci se contente de la raconter, ce qui est parfois plus grave. L’exemple le plus connu date de 2014 : un défaut de ce type dans un logiciel de chiffrement très répandu permettait de demander à n’importe quel serveur sur Internet de renvoyer soixante-quatre mille caractères du contenu de sa mémoire, y compris ses clés secrètes, sans laisser la moindre trace.

Deux leçons en découlent. D’abord, un programme ne doit jamais croire une taille annoncée par quelqu’un d’autre : il doit vérifier de combien de données il dispose réellement. Ensuite, une fuite de mémoire sans dégât visible n’est pas un incident mineur : outre les secrets qu’elle peut livrer, elle révèle à l’attaquant la carte de la mémoire, ce qui lui permet d’exploiter un autre défaut qu’il n’aurait pas su utiliser à l’aveugle.

À lire aussi

Pages voisines

La citent

CWE-125 : lecture hors limites, la fuite qui ne casse rien

Elle cite

: les deux pages se citent l’une l’autre.