Applications, sites et API

Particuliers et entreprises

Utilisation de mémoire après libération

Use-after-free / UAF

Un programme réutilise une zone mémoire qu’il a déjà libérée.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 4 min
Je pense être concerné : que faire ?
Illustration pédagogique : utilisation de mémoire après libération.

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 outil ferme un aperçu de document, mais une tâche retardée conserve une référence vers cet aperçu. Quand elle reprend, la mémoire a déjà été libérée. Le programme peut planter ou manipuler le contenu d’un autre objet qui occupe maintenant cette place.

Comment cela fonctionne

Un programme réserve de la mémoire pour ses objets, puis la libère lorsqu’ils ne servent plus. Un défaut apparaît si une autre partie du programme continue à utiliser une ancienne référence. L’emplacement peut être réattribué entre-temps. Une personne qui contrôle certaines entrées peut parfois influencer ce nouveau contenu et détourner le traitement. Les effets dépendent du programme et de ses protections.

Comment le piège fonctionne
  1. Un objet est fermé

    Sa mémoire devient disponible.

  2. Une ancienne référence reste active

    Une tâche retardée conserve son adresse.

  3. La tâche utilise la mauvaise mémoire

    Le programme peut planter ou agir autrement.

Ce que vous pouvez faire

Vos premiers réflexes

Mettez le logiciel à jour et signalez un plantage lié à une fermeture ou une annulation. Notez l’heure et conservez le document sans le rouvrir pour reproduire la panne.

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

Faites rechercher les références conservées par les tâches retardées. Corrigez leur gestion, puis testez les annulations et les fermetures avec la version réellement utilisée.

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

Une zone libérée peut conserver son ancien contenu pendant un moment. Une lecture qui semble réussir ne rend pas cette référence valide.

À vous de décider

L’aperçu est fermé, mais une tâche peut encore lire son ancienne mémoire sans planter. Cette lecture est-elle correcte ?

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

Voir la réponse expliquée

Non. La durée de vie de l’objet est terminée. Le contenu peut encore sembler intact, ou déjà appartenir à un autre objet. Le fournisseur doit corriger la référence conservée.

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 rappel utilise l’aperçu après sa destruction

Dans ce cas fictif, l’aperçu preview-A est libéré après sa fermeture. Un rappel différé tente ensuite de le consulter. Le diagnostic heap-use-after-free relie l’accès à une allocation dont la durée de vie est terminée. Il faut lire les piles d’allocation, de libération et d’accès du rapport original pour retrouver les chemins concernés.

La reconstitution montre une lecture invalide dans le laboratoire. Aucun élément n’établit ici une exécution hostile en production. Le contenu présent à cette adresse peut différer d’un essai à l’autre, et le résultat dépend des conditions d’exécution.

La version corrigée annule le rappel avant la destruction de l’objet et garantit qu’aucun rappel en cours ne le consulte encore. Cette synchronisation doit aussi couvrir les fermetures simultanées et les erreurs de traitement. Le cas Internet Explorer cité dans les sources illustre le même type de défaut dans un autre composant.

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
UtilisateurDocument non fiable
Service d’aperçuGestion de la fermeture
Objet d’aperçuMémoire réservée
Rappel différéTraitement asynchrone
  1. Action

    Ouverture de l’aperçu

    Utilisateur vers Service d’aperçu

    Trace preview-31

  2. Action

    Création de l’objet

    Service d’aperçu vers Objet d’aperçu

    Trace preview-A

  3. Action

    Planification du rappel

    Service d’aperçu vers Rappel différé

    Trace référence conservée

  4. Action

    Fermeture et libération

    Service d’aperçu vers Objet d’aperçu

    Trace event=freed

  5. Action

    Consultation tardive

    Rappel différé vers Objet d’aperçu

    Trace heap-use-after-free

  6. Réponse

    Erreur de mémoire en test

    Objet d’aperçu vers Service d’aperçu

    Trace prise de contrôle non établie

  7. Refus / blocage

    Annulation et synchronisation après correction

    Service d’aperçu vers Rappel différé

    Trace avant la libération

Comment repérer cette attaque

Indices à rechercher

  • Des plantages surviennent après une fermeture, une annulation ou un traitement retardé.
  • Un diagnostic mémoire relie l’accès à un objet déjà libéré.
  • Le processus réalise ensuite une opération étrangère au traitement attendu.

Rapprocher les fermetures et annulations des plantages du processus de traitement. Sur une copie instrumentée, examiner les trois piles qui décrivent l’allocation, la libération et l’accès ultérieur. Rechercher à part les actions inattendues du processus réel.

Quelles informations comparer

Suivre preview-A dans la reproduction, depuis sa création jusqu’au rappel. Vérifier l’ordre des événements dans le processus concerné, puis comparer sa version à celle déployée sans confondre les deux environnements.

Ce que ces indices ne permettent pas de conclure

Un diagnostic d’utilisation après libération établit un accès invalide dans le test. Il ne prouve ni le contrôle du nouveau contenu ni une exécution de code hostile dans le service de production.

Comment réagir

Suspendre le traitement vulnérable des documents non fiables et préserver les versions utiles. Appliquer la correction de durée de vie puis vérifier les processus chargés. Étendre l’enquête si des actions hostiles sont établies avec leurs droits.

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. Un rappel ne peut plus accéder à l’objet après sa destruction, même s’il était déjà en cours.
  2. Les essais instrumentés couvrent fermeture, annulation et traitement normal.
  3. Le composant corrigé est effectivement chargé par les services exposés.

À vous de raisonner

Le rapport situe l’accès dans un rappel après la libération. Mettre la référence principale à zéro suffit-il si le rappel conserve sa propre copie ?

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. Il faut aussi traiter la référence détenue par le rappel et synchroniser les tâches déjà en cours. Le test doit montrer que l’objet reste vivant pendant tout accès autorisé, ou que cet accès ne peut plus se produire.

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.

diagnostic
Résumé pédagogique du constat mémoire ; le rapport natif contient les piles qu’il faut examiner séparément.
code_execution
Conclusion limitée aux preuves du cas : not_established signifie que l’exécution hostile n’est pas démontrée.

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":"preview-31","environment":"isolated_test","object":"preview-A","event":"allocated"}
{"case":"preview-31","object":"preview-A","event":"freed"}
{"case":"preview-31","event":"deferred_callback","diagnostic":"heap-use-after-free","code_execution":"not_established"}
{"case":"preview-32","build":"fixed","event":"callback_cancelled_before_release"}
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
    Conserver le diagnostic heap-use-after-free et les piles d’allocation, de libération et d’accès. Relier ces éléments à la compilation instrumentée et aux symboles correspondants.
    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 la fermeture de l’aperçu, l’annulation et les rappels associés. Ces étapes nécessitent une instrumentation adaptée ; un journal d’accès HTTP ne décrit pas la durée de vie des objets.
    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 le logiciel à jour et signalez un plantage lié à une fermeture ou une annulation. Notez l’heure et conservez le document sans le rouvrir pour reproduire la panne.

Pour l’équipe qui exploite le service

  1. Conservez l’heure, le fichier concerné et la version du logiciel sans relancer le document.
  2. Faites isoler le traitement exposé et appliquer le correctif du fournisseur.
  3. Examinez les effets observés avec les droits du processus pendant la période vulnérable.

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 ↗Exploitation de vulnérabilités ↗Toutes les fiches ECRAN →