Applications, sites et API

Particuliers et entreprises

Débordement d’entier

Integer overflow / Integer wraparound

Un calcul dépasse les valeurs représentables et peut produire une taille ou une décision incorrecte.

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

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 reçoit un fichier qui annonce beaucoup d’éléments. Pour réserver de la mémoire, il multiplie leur nombre par leur taille. Le résultat dépasse la capacité du nombre utilisé et devient trop petit. La réservation peut alors être insuffisante pour la suite du traitement.

Comment cela fonctionne

Les nombres entiers informatiques ont des limites qui dépendent de leur type. Un calcul hors de ces limites peut être refusé, changer de valeur ou avoir un comportement non défini selon le langage et le type. Si le programme utilise ce résultat comme une taille ou un compteur fiable, une entrée malveillante peut modifier sa décision. Les conséquences peuvent toucher la mémoire ou une règle de gestion.

Comment le piège fonctionne
  1. Des nombres sont reçus

    Le fichier annonce des quantités ou des tailles.

  2. Le calcul dépasse sa capacité

    Le résultat ne représente plus la quantité attendue.

  3. La suite utilise ce résultat

    Réservation trop petite ou décision incorrecte.

Ce que vous pouvez faire

Vos premiers réflexes

Mettez à jour les logiciels qui ouvrent vos documents. Signalez un plantage en conservant le fichier et son contexte, sans chercher à en modifier les tailles vous-même.

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

Faites contrôler les calculs qui précèdent les allocations et les décisions métier. Vérifiez les conversions et les tests de valeurs limites dans les composants réellement déployés.

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

Choisir un entier plus grand déplace sa limite. Cela ne remplace pas un contrôle du résultat et des conversions qui suivent.

À vous de décider

Remplacer un petit compteur par un compteur plus grand suffit-il à garantir que tous ses calculs restent corrects ?

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

Voir la réponse expliquée

Non. Le nouveau type possède encore des limites, et le résultat peut être converti ensuite dans un type plus petit. Les opérations et les conversions doivent être vérifiées avant leur utilisation.

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 calcul de taille réserve moins de place que nécessaire

Ce cas fictif utilise volontairement un entier non signé de huit bits pour rendre le calcul lisible. Il représente les valeurs de 0 à 255. Quarante éléments de huit octets demandent 320 octets ; le résultat stocké dans ce modèle revient à 64, soit 320 modulo 256.

La réservation de 64 octets ne suffit donc pas à une copie de 320 octets. La trace précise copy_performed=false : l’exercice s’arrête avant cette copie. Il établit une sous-allocation dans le modèle, sans démontrer une écriture hors limites ni une exploitation en production. Les entiers signés d’un programme réel ne suivent pas nécessairement ce bouclage.

La correction refuse la taille avant l’allocation. Vérifier seulement que le résultat stocké est petit laisserait passer l’erreur : le contrôle doit couvrir les opérandes, l’opération et les conversions. Stagefright illustre une chaîne réelle reliant un calcul de taille à une corruption mémoire ; le modèle huit bits ne reconstitue pas cette vulnérabilité.

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
Fichier reçuQuantités non fiables
LecteurCalcul de taille
AllocateurRéservation mémoire
Équipe de testModèle arithmétique isolé
  1. Action

    Annonce de quarante éléments

    Fichier reçu vers Lecteur

    Trace huit octets par élément

  2. Action sur place

    Calcul dans le modèle huit bits

    Lecteur

    Trace 320 devient 64

  3. Action

    Demande de réservation

    Lecteur vers Allocateur

    Trace 64 octets

  4. Réponse

    Mémoire réservée

    Allocateur vers Lecteur

    Trace taille insuffisante

  5. Action

    Comparaison avant copie

    Lecteur vers Équipe de test

    Trace 320 octets nécessaires

  6. Action sur place

    Constat de sous-allocation

    Équipe de test

    Trace copie non effectuée

  7. Refus / blocage

    Vérification de la correction

    Équipe de test vers Lecteur

    Trace refus avant allocation

Comment repérer cette attaque

Indices à rechercher

  • Un calcul de taille donne une valeur incohérente avec le nombre d’éléments annoncé.
  • Un lecteur plante sur un fichier contenant des tailles inhabituelles.
  • Une instrumentation numérique signale un calcul ou une conversion hors des limites prévues.

Suivre les valeurs depuis le fichier jusqu’au calcul, à l’allocation et à la copie prévue. Comparer la quantité mathématique attendue à la valeur effectivement représentée. Vérifier les contrôles numériques activés sur la compilation de test.

Quelles informations comparer

Rapprocher les opérandes de size-8, le modèle huit bits et la réservation de 64 octets. Rechercher ensuite la copie prévue, en conservant ici la limite explicite : elle n’a pas été effectuée dans le test.

Ce que ces indices ne permettent pas de conclure

Ce modèle montre une erreur arithmétique et une réservation insuffisante. Sans copie observée, il ne prouve pas un débordement mémoire. Les règles du type signé ou d’un autre langage peuvent produire un comportement différent.

Comment réagir

Corriger le calcul et les conversions avant toute réservation ou décision fondée sur leur résultat. Préserver le fichier et le binaire, examiner les autres lecteurs qui partagent cette routine et traiter les effets réellement constatés.

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 quantités non représentables sont refusées avant toute allocation.
  2. Les essais couvrent les bornes, les conversions et les formats légitimes.
  3. Le composant corrigé est chargé et les décisions en aval utilisent une taille vérifiée.

À vous de raisonner

Le résultat stocké vaut 64, inférieur à la taille maximale autorisée. Ce seul contrôle suffit-il lorsque le calcul attendu valait 320 ?

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 calcul a déjà perdu l’information avant le contrôle. Il faut vérifier les opérandes et la représentabilité du résultat avant l’opération, ou employer une opération contrôlée, puis vérifier les conversions.

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.

stored_bytes
Valeur représentée après le calcul dans le modèle pédagogique non signé ; ce champ n’est pas un événement natif du système.
copy_performed
Indicateur de l’exercice : false conserve le fait que la copie dangereuse a été arrêtée avant son exécution.

Reconstitution pédagogique du cas en laboratoire

JSONL

Valeurs et événements fictifs réunis pour expliquer le cas. Ce format est une reconstitution, pas un export natif du logiciel ou du système cité.

{"case":"size-8","environment":"isolated_test","model":"unsigned_8_bit","count":40,"item_bytes":8,"expected_bytes":320,"stored_bytes":64}
{"case":"size-8","allocation_bytes":64,"requested_copy_bytes":320,"copy_performed":false,"production_exploit":"not_established"}
{"case":"size-9","build":"fixed","result":"size_rejected_before_allocation"}
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 : contrôles numériques en environnement de test

    Où les trouver
    Dans la sortie d’erreur du lecteur compilé avec l’instrumentation adaptée, ou dans les artefacts de sa chaîne de tests. Conserver le diagnostic, les types et l’emplacement de l’opération avec les symboles correspondants.
    Quoi relever
    Relever les diagnostics numériques activés et le type exact de l’opération. Documenter les options de compilation : la vérification du débordement non signé est distincte des contrôles de comportement indéfini.
    Accès et prérequis
    Copie de test autorisée et options de compilation documentées. Le groupe undefined ne couvre pas le bouclage des entiers non signés ; ce contrôle demande une option distincte. Un diagnostic actuel ne reconstitue pas les opérations passées en production.
    Documentation : LLVM : contrôles numériques 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
    Conserver sur des données factices le nombre d’éléments, la taille unitaire et les tailles calculées puis allouées. Ces champs doivent être ajoutés au lecteur si son instrumentation ne les fournit pas.
    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

Mettez à jour les logiciels qui ouvrent vos documents. Signalez un plantage en conservant le fichier et son contexte, sans chercher à en modifier les tailles vous-même.

Pour l’équipe qui exploite le service

  1. Conservez le fichier, l’heure et les versions concernées sans relancer le traitement.
  2. Faites corriger le calcul en amont et suspendre le chemin exposé si nécessaire.
  3. Examinez l’allocation, la copie et les décisions qui utilisent le résultat incorrect.

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 ↗Lecture hors limites de la mémoire ↗Utilisation de mémoire après libération ↗Toutes les fiches ECRAN →