Applications, sites et API
Particuliers et entreprisesExploitation d’une erreur de concurrence
Race condition / Time-of-check time-of-use / TOCTOU
Une ressource change entre sa vérification et son utilisation, ou des opérations se chevauchent mal.
Je pense être concerné : que faire ?
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 vérifie un fichier, puis l’ouvre un peu plus tard pour effectuer une opération. Dans cet intervalle, une autre action remplace le fichier désigné par le même nom. Le service utilise alors une ressource différente de celle qu’il vient de contrôler.
Comment cela fonctionne
Lorsque plusieurs opérations peuvent avancer en même temps, leur ordre peut modifier le résultat. Une erreur de concurrence devient exploitable si un attaquant peut influencer cet ordre et contourner une règle. Le cas TOCTOU concerne le temps entre la vérification d’une ressource et son utilisation. D’autres erreurs de concurrence touchent les comptes, les quotas ou les transactions.
- Une ressource est contrôlée
Le service décide qu’il peut l’utiliser.
- Une autre opération la modifie
L’état change avant l’action suivante.
- Le service agit sur le nouvel état
Le contrôle précédent peut être contourné.
Ce que vous pouvez faire
Vos premiers réflexes
Signalez un résultat incohérent avec l’heure et l’action réalisée. Ne répétez pas les demandes pour provoquer des doubles opérations ou explorer les données accessibles.
Si vous êtes responsable du service ou de l’organisation
Faites vérifier les opérations qui contrôlent puis réutilisent une ressource. Protégez les répertoires de travail et testez la cohérence lorsque plusieurs actions se chevauchent.
Réduire le délai entre deux opérations ne supprime pas la possibilité qu’une autre opération s’intercale.
À vous de décider
Le service a vérifié le nom du fichier une milliseconde avant de l’ouvrir. Cela garantit-il que le fichier ouvert est celui qui a été contrôlé ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Une autre opération peut remplacer la ressource pendant cet intervalle. Le service doit garantir la cohérence entre le contrôle et l’action, par exemple en conservant une référence sûre vers l’objet vérifié.
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 chemin garde son nom mais change de ressource avant l’action
Le cas fictif compare des identifiants d’objets et un ordre enregistré dans le laboratoire. Le service contrôle object-A, puis une autre opération remplace la ressource désignée. À l’utilisation, il atteint object-B. La décision de départ ne porte donc pas sur l’objet utilisé.
L’exercice emploie deux fichiers factices. real_sensitive_file_affected=false indique qu’aucun fichier sensible réel n’a été affecté ; ce résultat ne prouve pas une élévation de privilèges. Pour un incident réel, il faut établir les permissions, le compte du service et les modifications effectivement réalisées.
Dans le test corrigé, l’action reste attachée à object-A. Le maintien d’une référence ne suffit toutefois que si les propriétés utiles de l’objet sont elles aussi protégées. Les tests doivent couvrir les liens, les remplacements et les changements de contenu que permet l’environnement. ABRT illustre une course réelle sur des opérations de fichiers, distincte de ce scénario.
Le déroulement en schéma
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.
- Action
Contrôle de la ressource
Service vers Ressource A
Trace sequence=1
- Réponse
Autorisation sur object-A
Ressource A vers Service
Trace allowed=true
- Action
Remplacement pendant l’intervalle
Autre opération vers Ressource B
Trace sequence=2
- Action
Utilisation après remplacement
Service vers Ressource B
Trace sequence=3
- Réponse
Action sur object-B
Ressource B vers Service
Trace autre objet
- Action sur place
Comparaison des identités
Service
Trace A diffère de B
- Action
Vérification du chemin corrigé
Service vers Ressource A
Trace objet vérifié conservé
Comment repérer cette attaque
Indices à rechercher
- La ressource utilisée ne correspond pas à celle dont le contrôle a été enregistré.
- Une anomalie apparaît seulement sous certaines charges ou avec des opérations simultanées.
- Une modification de fichier survient dans l’intervalle d’une opération privilégiée.
Comparer l’identité de la ressource contrôlée à celle effectivement utilisée, puis rechercher les changements intercalés. Examiner les permissions du répertoire et le contexte du processus privilégié ; une suite d’heures proches ne suffit pas à reconstruire cet enchaînement.
Quelles informations comparer
Dans race-14, comparer la séquence de laboratoire et les identifiants object-A puis object-B. En production, préciser la source de chaque événement et ses limites temporelles avant de conclure à une substitution.
Ce que ces indices ne permettent pas de conclure
Une proximité horaire ou un chemin identique ne démontre pas la course. Le cas utilise des ressources factices et ne prouve ni modification d’un fichier sensible réel ni élévation de privilèges.
Comment réagir
Suspendre le chemin exposé, préserver les traces de modification et protéger le répertoire concerné. Corriger la cohérence des opérations puis examiner les fichiers et droits effectivement altérés avant toute restauration.
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.
- Le contrôle et l’action portent sur la même ressource et les propriétés nécessaires restent valides.
- Les remplacements et liens possibles sont couverts par les essais de concurrence.
- Les permissions déployées limitent les écritures et les opérations normales restent disponibles.
À vous de raisonner
La course ne se reproduit plus après l’ajout d’un délai plus court. Cette observation valide-t-elle la correction ?
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 délai peut réduire la probabilité de l’interférence tout en laissant la fenêtre ouverte. Il faut vérifier la garantie de cohérence et tester un entrelacement contrôlé dans lequel l’autre opération tente de modifier la ressource.
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.
resource_id- Identité fictive de l’objet, à distinguer du nom de chemin ; sa collecte réelle dépend des outils du système.
sequence- Ordre ajouté par l’instrumentation du laboratoire ; il ne représente pas un ordre universel déduit de plusieurs horloges.
Reconstitution pédagogique du cas en laboratoire
JSONLValeurs 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":"race-14","environment":"isolated_test","sequence":1,"event":"check","resource_id":"object-A","allowed":true}
{"case":"race-14","sequence":2,"event":"replacement","resource_id":"object-B"}
{"case":"race-14","sequence":3,"event":"use","resource_id":"object-B","real_sensitive_file_affected":false}
{"case":"race-15","build":"fixed","checked_resource":"object-A","used_resource":"object-A","result":"consistent"}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.
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
- Relever l’identité de la ressource au contrôle et à l’utilisation, ainsi que les identifiants de tâche. Documenter comment l’instrumentation du service établit cet ordre et quelles propriétés sont vérifié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.
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 les règles d’audit étaient présentes, relier remplacements, ouvertures et changements de droits aux bons processus. Les noms de chemins doivent être rapprochés des identités d’objets disponibles.
- 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.
Si vous pensez être concerné
Si vous utilisez le service
Signalez un résultat incohérent avec l’heure et l’action réalisée. Ne répétez pas les demandes pour provoquer des doubles opérations ou explorer les données accessibles.
Pour l’équipe qui exploite le service
- Conservez les identifiants des opérations, leurs heures et les versions du service.
- Faites suspendre le chemin vulnérable et protéger les ressources modifiables.
- Vérifiez les opérations déjà réalisées et restaurez les droits ou données altérés si nécessaire.
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
- CWE-367 : course entre vérification et utilisation — cwe.mitre.org
- CWE-362 : accès concurrents sans synchronisation suffisante — cwe.mitre.org
- Rapid7 : ABRT raceabrt, CVE-2015-3315 — rapid7.com
