Applications, sites et API

Particuliers et entreprises

Débordement de tampon

Buffer overflow

Une écriture dépasse la zone mémoire prévue et peut détourner le programme.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 5 min
Je pense être concerné : que faire ?
Illustration pédagogique : débordement de tampon.

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 convertit un fichier reçu. Le lecteur réserve de la mémoire, mais y copie plus de données que la place disponible. Le service peut s’arrêter. Dans certaines conditions, cette écriture permet aussi à un attaquant de détourner les instructions exécutées.

Comment cela fonctionne

Un tampon est une zone de mémoire réservée à des données. Un débordement se produit lorsqu’un programme écrit au-delà de ses limites. Il peut écraser une valeur voisine, provoquer une panne ou modifier le déroulement du programme. Le défaut peut se trouver dans une bibliothèque utilisée pour lire une image ou traiter une connexion. Une personne peut donc être exposée en ouvrant un document avec un logiciel vulnérable, ou en utilisant un service qui le traite pour elle.

Comment le piège fonctionne
  1. Une entrée est traitée

    Un fichier ou un message arrive au programme.

  2. Une copie dépasse la place prévue

    Des données voisines sont écrasées.

  3. Le programme se comporte autrement

    Panne, altération ou parfois exécution détournée.

Ce que vous pouvez faire

Vos premiers réflexes

Installez les mises à jour et signalez un plantage répété avec la version du logiciel et l’heure. Conservez le document concerné sans le rouvrir pour essayer de reproduire la panne.

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

Inventoriez les lecteurs et bibliothèques exposés aux fichiers reçus. Faites corriger le composant, isolez ses traitements et examinez l’activité du processus pendant la période vulnérable.

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

Un plantage ne prouve pas une prise de contrôle. Inversement, certains débordements peuvent être exploités sans panne visible.

À vous de décider

Votre lecteur se ferme après l’ouverture d’un document. Cela prouve-t-il que quelqu’un contrôle votre ordinateur ?

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

Voir la réponse expliquée

Non. Le plantage peut avoir plusieurs causes. Un défaut mémoire est une piste à faire examiner, et une prise de contrôle exige d’autres éléments. Notez le contexte, évitez de relancer le document et signalez-le au support.

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

Un lecteur d’images écrit au-delà du tampon prévu

Dans ce cas fictif, un lecteur d’images s’arrête pendant le traitement du fichier img-42. La copie instrumentée du lecteur confirme une écriture de 96 octets dans une zone qui n’en contient que 64. Le défaut de bornes est établi dans cet environnement de test. Le résultat ne démontre pas une prise de contrôle du service en production.

La première ligne conserve cette limite avec code_execution=not_established. Le rapport mémoire réel doit être examiné avec la version exacte du programme, les symboles et la pile d’appels. Son diagnostic permet de retrouver la copie fautive et le calcul de taille en amont. Les droits du processus de traitement et ses connexions servent ensuite à évaluer l’exposition.

Après correction, le lecteur refuse cette entrée avant la copie. Il faut aussi vérifier les tailles limites et les formats valides : traiter ce seul fichier ne couvre pas toutes les variantes. EternalBlue, documenté par Rapid7, illustre historiquement une corruption de mémoire dans un autre composant, SMB ; le scénario d’image présenté ici ne reconstitue pas cette attaque.

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
ExpéditeurEntrée non fiable
Service d’importFrontière applicative
Lecteur natifProcessus limité
Équipe techniqueLaboratoire isolé
  1. Action

    Envoi du fichier

    Expéditeur vers Service d’import

    Trace identifiant img-42

  2. Action

    Demande de conversion

    Service d’import vers Lecteur natif

    Trace version reader-a

  3. Action sur place

    Écriture au-delà du tampon

    Lecteur natif

    Trace plantage observé

  4. Réponse

    Échec du traitement

    Lecteur natif vers Service d’import

    Trace exécution détournée non établie

  5. Action

    Transmission d’une copie préservée

    Service d’import vers Équipe technique

    Trace fichier et versions

  6. Action sur place

    Analyse instrumentée

    Équipe technique

    Trace WRITE au-delà de 64 octets

  7. Refus / blocage

    Validation du lecteur corrigé

    Équipe technique vers Lecteur natif

    Trace refus avant copie

Comment repérer cette attaque

Indices à rechercher

  • Un service plante de façon répétée pendant le traitement d’une même catégorie d’entrée.
  • Un rapport d’analyse mémoire signale une écriture au-delà d’une allocation.
  • Un programme lance un processus ou établit une connexion sans rapport avec sa fonction.

Rapprocher les plantages d’une même version, les fichiers traités et les diagnostics mémoire obtenus sur une reproduction isolée. Rechercher séparément les processus enfants, écritures et connexions inattendus du service pendant l’exposition.

Quelles informations comparer

Relier le même fichier préservé à la version déployée puis à sa reproduction instrumentée. Séparer les résultats du laboratoire des événements de production, dont les protections et la disposition mémoire peuvent différer.

Ce que ces indices ne permettent pas de conclure

Le diagnostic WRITE établit une écriture invalide dans le test. Il ne prouve pas une exécution hostile sur le service réel. Des journaux absents ou incomplets empêchent de conclure sur certains effets.

Comment réagir

Retirer le processus de traitement vulnérable du traitement des entrées non fiables, préserver les éléments nécessaires puis appliquer le correctif. Vérifier les autres usages du lecteur. Si une activité hostile est établie, étendre l’enquête aux ressources accessibles avec ses droits ; le redémarrage seul ne corrige pas la copie.

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 tailles invalides sont refusées avant toute écriture, et les formats valides restent utilisables.
  2. Les tests instrumentés couvrent les limites et le calcul de taille, avec la version corrigée du lecteur.
  3. Le service charge effectivement le composant corrigé et conserve des droits limités.

À vous de raisonner

Le lecteur instrumenté signale WRITE avec 96 octets copiés pour 64 disponibles. Pouvez-vous conclure que le service de production a exécuté le code d’un attaquant ?

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

Comparer avec le raisonnement expliqué

Non. Le test confirme la copie hors limites dans cette version et ce contexte. Pour conclure à une exécution détournée en production, il faut d’autres preuves sur l’activité du processus et les effets observés. Il faut corriger le défaut même si ces preuves manquent.

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.

copy_bytes
Taille fictive de la copie présentée dans l’enveloppe pédagogique ; le rapport AddressSanitizer natif doit être lu séparément.
code_execution
État de preuve ajouté par l’analyste dans le cas : not_established signifie non démontré, et non impossible.

Reconstitution d’un traitement et de son analyse en laboratoire

JSONL

Enveloppes pédagogiques inventées, pas un export natif AddressSanitizer. Les identifiants et mesures décrivent uniquement ce cas fictif ; aucun contenu de fichier n’est reproduit.

{"case":"img-42","environment":"service","build":"reader-a","result":"crash","code_execution":"not_established"}
{"case":"img-42","environment":"isolated_test","build":"reader-a-asan","access":"WRITE","available_bytes":64,"copy_bytes":96,"result":"out_of_bounds"}
{"case":"img-42","environment":"isolated_test","build":"reader-b-asan","result":"rejected_before_copy"}
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
    Dans la reproduction isolée, relever le type d’accès, la taille, la pile d’appels et l’allocation concernée. Conserver la version compilée et les symboles utilisés pour interpréter le rapport.
    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
    Retrouver le fichier traité, son empreinte, la tâche, le processus de traitement et la version réellement chargée. Préserver les rapports de plantage sans les publier : ils peuvent contenir des données privées.
    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

  3. Linux — auditd

    Où les trouver
    Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
    Quoi relever
    Si la collecte existait, reconstituer les processus enfants et les opérations du processus de traitement pendant la période exposée. Un plantage et un lancement doivent être reliés au même hôte et au bon processus.
    Accès et prérequis
    Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
    Documentation : Linux — auditd

Si vous pensez être concerné

Si vous utilisez le service

Installez les mises à jour et signalez un plantage répété avec la version du logiciel et l’heure. Conservez le document concerné sans le rouvrir pour essayer de reproduire la panne.

Pour l’équipe qui exploite le service

  1. Conservez l’heure, la version du logiciel et le fichier concerné sans le rouvrir sur un poste de travail.
  2. Faites isoler le traitement vulnérable et appliquer le correctif validé.
  3. Recherchez les effets du plantage et toute activité inhabituelle du processus.

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

Lecture hors limites de la mémoire ↗Débordement d’entier ↗Utilisation de mémoire après libération ↗Exploitation de vulnérabilités ↗Déni de service, simple ou distribué ↗Toutes les fiches ECRAN →