Applications, sites et API

Particuliers et entreprises

Lecture hors limites de la mémoire

Out-of-bounds read / Buffer over-read / Heartbleed

Un logiciel lit au-delà des données attendues et peut révéler des secrets.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 5 min
Je pense être concerné : que faire ?
Illustration pédagogique : lecture hors limites de la mémoire.

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Un service doit renvoyer une petite partie des données reçues. Il accepte une longueur erronée et lit aussi la mémoire voisine. Sa réponse peut alors révéler des informations provenant d’une autre opération.

Comment cela fonctionne

Une lecture hors limites accède à de la mémoire située en dehors de la zone autorisée pour l’opération. Elle peut faire planter un programme ou révéler des informations si les octets lus sont transmis. Heartbleed, annoncé en 2014 dans OpenSSL, est un exemple connu de fuite par lecture excessive. Le chiffrement de la connexion ne corrige pas un défaut dans le logiciel qui prépare la réponse.

Comment le piège fonctionne
  1. Une longueur est mal vérifiée

    Le programme reçoit une demande de données.

  2. La lecture dépasse la zone prévue

    Des octets voisins sont consultés.

  3. Une sortie peut les révéler

    La réponse expose alors des données supplémentaires.

Ce que vous pouvez faire

Vos premiers réflexes

Si une réponse contient les données d’une autre personne, arrêtez la consultation et signalez-la au service. Ne répétez pas la demande pour explorer ce qui serait accessible.

Si vous êtes responsable du service ou de l’organisation

Vérifiez les composants réellement chargés par les services. Après correction, évaluez les secrets qui pouvaient être présents en mémoire et décidez de leur renouvellement selon cette exposition.

Un point à vérifierUne idée reçue à corriger

L’absence de panne ne garantit pas l’absence de fuite : une réponse peut contenir de la mémoire supplémentaire tout en paraissant fonctionner.

À vous de décider

Le site utilise HTTPS et continue à fonctionner normalement. Cela exclut-il une fuite par lecture hors limites ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Non. HTTPS protège le transport des données. Un logiciel vulnérable peut préparer une réponse contenant de la mémoire supplémentaire, puis la transmettre par cette connexion chiffrée sans planter.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Une réponse de test contient des octets hors du message reçu

Le service fictif devrait renvoyer au maximum les 16 octets disponibles dans le message. Dans le laboratoire, il renvoie 64 octets et un marqueur factice placé dans la zone voisine apparaît dans la réponse. Ces deux observations relient la lecture hors limites à une sortie visible. Une alerte de lecture seule n’aurait pas suffi à établir cette transmission.

Le marqueur est une donnée de test. Son retour ne prouve aucun vol de secret réel dans l’environnement exploité. Pour évaluer ce dernier, il faut retrouver les versions chargées, la période d’exposition et les informations manipulées par le processus. Le contenu des réponses anciennes peut être inconnu.

Heartbleed est un cas historique documenté par OpenSSL et Metasploit : le défaut concernait l’extension TLS heartbeat. Un journal HTTP ordinaire ne couvre pas ce traitement TLS. Une mise à jour du fichier de bibliothèque doit donc être suivie d’une vérification des processus qui l’utilisent effectivement.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
Client de testDonnées factices
ServiceProtocole analysé
BibliothèqueMémoire du processus
Équipe techniqueAnalyse et correction
  1. Action

    Demande avec longueur incohérente

    Client de test vers Service

    Trace 64 déclarés, 16 disponibles

  2. Action

    Lecture demandée

    Service vers Bibliothèque

    Trace borne non contrôlée

  3. Action sur place

    Lecture de la zone voisine

    Bibliothèque

    Trace READ hors limites

  4. Réponse

    Données supplémentaires

    Bibliothèque vers Service

    Trace marqueur factice

  5. Réponse

    Réponse observée

    Service vers Client de test

    Trace 64 octets de contenu

  6. Action

    Constat de la fuite en laboratoire

    Client de test vers Équipe technique

    Trace vol réel non établi

  7. Refus / blocage

    Contrôle après correction

    Équipe technique vers Service

    Trace longueur rejetée

Comment repérer cette attaque

Indices à rechercher

  • Une réponse contient des fragments étrangers au contenu demandé.
  • Un analyseur mémoire signale une lecture au-delà de la zone disponible.
  • Un composant chargé correspond à une version vulnérable signalée par son fournisseur.

Chercher une incohérence entre les bornes disponibles et les données transmises, sur une copie instrumentée. Pour les faits passés, examiner les capteurs adaptés au protocole et l’inventaire des processus exposés ; une simple recherche dans les accès HTTP peut manquer la couche concernée.

Quelles informations comparer

Dans le laboratoire, rapprocher les bornes de l’objet, la lecture et la présence du marqueur factice dans la réponse. Pour l’exposition passée, reconstruire les versions effectivement chargées et la période où le service était joignable.

Ce que ces indices ne permettent pas de conclure

Le marqueur prouve une fuite de données factices dans ce test. Il ne permet pas d’identifier un secret réel volé auparavant. Une capture TLS chiffrée et un journal HTTP ordinaire ne donnent pas automatiquement le contenu recherché.

Comment réagir

Corriger le composant, vérifier le remplacement effectif de sa version chargée puis évaluer les secrets accessibles en mémoire. Organiser leur renouvellement selon cette exposition, ainsi que la révocation des sessions ou certificats concernés si nécessaire. Protéger les éléments d’enquête qui pourraient eux-mêmes contenir des secrets.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  1. Les longueurs dépassant les données disponibles sont rejetées avant la lecture.
  2. La reproduction corrigée ne renvoie aucun marqueur voisin, et les échanges valides fonctionnent.
  3. Les processus exposés utilisent la version corrigée ; la décision de renouvellement des secrets est documentée.

À vous de raisonner

Un marqueur factice voisin revient dans la réponse du laboratoire, mais les journaux HTTP historiques ne montrent rien. Qu’établit ce résultat ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Le test établit un chemin de lecture et de retour dans la version étudiée. Il ne prouve pas le vol passé d’un secret réel. Pour un défaut dans TLS, les accès HTTP peuvent ne pas couvrir l’échange concerné ; il faut retrouver les versions chargées, l’exposition et les autres preuves disponibles.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

available_bytes
Nombre d’octets du message dans ce protocole fictif ; ce champ pédagogique n’est pas un événement OpenSSL.
synthetic_neighbor_marker_returned
Résultat d’une observation de test : un marqueur factice de la zone voisine a atteint la réponse du client.

Mesures d’une reproduction avec des données factices

JSONL

Reconstitution pédagogique d’un protocole fictif, inspirée du principe d’une lecture excessive. Ces champs ne sont ni des journaux OpenSSL ni une capture Heartbleed ; les octets de mémoire sont volontairement absents.

{"case":"reply-7","environment":"isolated_test","declared_bytes":64,"available_bytes":16,"access":"READ","reply_payload_bytes":64}
{"case":"reply-7","environment":"isolated_test","synthetic_neighbor_marker_returned":true,"real_secret_theft":"not_established"}
{"case":"reply-7","environment":"isolated_test","build":"fixed","result":"length_rejected","reply_payload_bytes":0}
Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

  1. LLVM — rapport AddressSanitizer en environnement de test

    Où les trouver
    Dans la sortie d’erreur de la compilation instrumentée exécutée au laboratoire, ou son artefact conservé par la chaîne de tests. Lire le type d’accès, la pile d’appels et l’allocation décrite.
    Quoi relever
    Sur une compilation de test, rechercher l’accès READ hors de l’objet et la pile d’appels. L’outil localise la lecture invalide ; il ne garantit pas que les octets ont atteint le client.
    Accès et prérequis
    Reproduction autorisée sur des données factices, binaire instrumenté et symboles correspondant à sa version. Ces rapports ne sont pas présents par défaut en production et ne reconstituent pas une attaque passée ; protéger les données éventuellement contenues dans les diagnostics.
    Documentation : LLVM — rapport AddressSanitizer en environnement de test

  2. Service concerné — audit et historique à vérifier

    Où les trouver
    Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
    Quoi relever
    Identifier la version du processus et de sa bibliothèque, le traitement de la réponse et les mesures disponibles. Pour Heartbleed, la couche concernée est TLS et peut ne laisser aucune ligne dans les accès HTTP.
    Accès et prérequis
    Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
    Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Si vous utilisez le service

Si une réponse contient les données d’une autre personne, arrêtez la consultation et signalez-la au service. Ne répétez pas la demande pour explorer ce qui serait accessible.

Pour l’équipe qui exploite le service

  1. Signalez une réponse anormale sans chercher à obtenir davantage de données.
  2. Faites corriger le composant et vérifier que les processus utilisent la version corrigée.
  3. Évaluez les secrets exposés et organisez leur remplacement après fermeture du défaut.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

Sur des sujets proches

Débordement de tampon ↗Vol, exfiltration et violation de données ↗Exploitation de vulnérabilités ↗Toutes les fiches ECRAN →