Eine Race Condition (Wettlaufsituation) ist ein Fehler, bei dem das Ergebnis vom Timing paralleler Vorgänge abhängt – Angreifer schieben sich zwischen eine Prüfung und die darauf beruhende Aktion.
Wie Race Conditions entstehen
Moderne Software erledigt vieles parallel: Threads, Prozesse und Anfragen teilen sich Dateien, Speicher und Datenbankeinträge. Prüft der Code zuerst etwas und handelt dann in einem getrennten Schritt, kann sich der Zustand dazwischen ändern. Dieses klassische Muster heißt TOCTOU (Time-of-Check to Time-of-Use, CWE-367); die allgemeine Schwäche ist CWE-362.
Beispiele:
- Ein privilegiertes Programm prüft, ob eine Datei sicher ist, und öffnet sie dann – inzwischen hat der Angreifer sie durch einen symbolischen Link auf eine Systemdatei ersetzt.
- Ein Onlineshop prüft, ob ein Gutschein unbenutzt ist, und löst ihn dann ein; viele gleichzeitige Anfragen lösen ihn mehrfach ein („Limit Overrun“).
- Im Kernel geben zwei Threads dasselbe Objekt frei oder ändern es, was zu Speicherkorruption wie Use-After-Free führt.
Warum das wichtig ist
Race Conditions sind im Test schwer zu finden, weil sie nur bei bestimmtem Timing auftreten; Angreifer können sie durch Wiederholung dennoch zuverlässig auslösen. Der Fehler Dirty COW im Linux-Kernel (CVE-2016-5195) erlaubte jedem lokalen Nutzer Root-Rechte über eine Race Condition in der Speicherverwaltung und wurde aktiv ausgenutzt, auch auf Android. Viele lokale Rechteausweitungen in Windows und Linux beruhen auf Race Conditions, und in Webanwendungen ermöglichen sie finanziellen Betrug. Neben Pufferüberläufen gehören sie zu den technisch anspruchsvollsten Sicherheitslücken.
So verhindern Sie Race Conditions
- Atomare Operationen, Sperren und Datenbanktransaktionen mit passenden Constraints verwenden.
- Getrennte Prüf-und-Nutzungs-Schritte bei Dateien vermeiden; mit Dateihandles statt Pfaden arbeiten.
- Sensible Web-Operationen idempotent gestalten und Anfragen begrenzen.
- Mit Nebenläufigkeitswerkzeugen, Fuzzern und Thread Sanitizern testen.
