zurück zum Artikel

TOCTOU-Schwachstellen zählen zu den schwerwiegendsten in der Common Weakness Enumeration CWE-377 beschriebenen. Sie bedürfen besonderer Vorkehrungen.

Aufbauend auf der Diskussion über "CWE-377 – Unsichere temporäre Dateien und wie man sie vermeidet [1]" ist es wichtig, sich eingehender mit einer heimtückischen Schwachstelle zu befassen, die in diesem Zusammenhang auftreten kann: die TOCTOU-Race-Condition (Time-of-Check to Time-of-Use). TOCTOU-Schwachstellen treten auf, wenn zwischen der Überprüfung einer Ressource (z. B. einer Datei) und ihrer anschließenden Verwendung eine zeitliche Lücke besteht. Böswillige Akteure können diese Lücke insbesondere in Verbindung mit temporären Dateien ausnutzen – und so schwerwiegende Sicherheitsverletzungen auslösen.

In diesem Folgeartikel wird untersucht, wie sich TOCTOU-Bedingungen in Anwendungen manifestieren, vor allem bei der Verwaltung temporärer Dateien. Der Beitrag erörtert aber auch Strategien zur Minderung dieser Risiken, um eine robuste und sichere Anwendungsentwicklung zu gewährleisten.

Secure Coding – Sven Ruppert

Seit 1996 programmiert Sven Java in Industrieprojekten und seit über 15 Jahren weltweit in Branchen wie Automobil, Raumfahrt, Versicherungen, Banken, UN und Weltbank. Seit über 10 Jahren ist er von Amerika bis nach Neuseeland als Speaker auf Konferenzen und Community Events, arbeitete als Developer Advocate für JFrog und Vaadin und schreibt regelmäßig Beiträge für IT-Zeitschriften und Technologieportale. Neben seinem Hauptthema Core Java beschäftigt er sich mit TDD und Secure Coding Practices.

• Secure Coding: Einführung in sichere Programmierpraktiken für Java [2]
• Secure Coding: Unbefugten Zugriff durch Path Traversal (CWE-22) verhindern [3]
• Secure Coding: Best Practices zum Einsatz von Java NIO gegen Path Traversal [4]
• Secure Coding: Mit Unit Testing und Best Practices zu mehr Softwaresicherheit [5]
• Secure Coding: CWE-377 – Unsichere temporäre Dateien und wie man sie vermeidet [6]
• Secure Coding: CWE-377 – TOCTOU-Race-Conditions in den Griff bekommen [7]
• Secure Coding: Sichere Fehlerbehandlung in Java – CWE-778-Risiken vermeiden [8]
• Secure Coding: CWE-1007 – die unsichtbare Gefahr durch visuell ähnliche Zeichen [9]
• Secure Coding: CWE 1123 – Sich selbst modifizierenden Code vermeiden [10]
• Secure Coding: Probleme durch CWE 416 – Use After Free – in Java vermeiden [11]
• Secure Coding: Apache Maven gegen Cache-Poisoning-Attacken rüsten [12]
• Secure Coding: Risiken einschätzen mit dem Exploit Prediction Scoring System [13]
• Secure Coding: Passwort-Hashing zum Schutz vor Brute-Force und Rainbow-Tabellen [14]
• Secure Coding: Sicherere Passwörter mit Salt, Pepper und Hashing [15]
• Secure Coding: Sichere Datenhaltung in der JVM – Risiken und Best Practices [16]

Verständnis von TOCTOU im Kontext von CWE-377

TOCTOU (Time-of-Check to Time-of-Use) ist eine Art Race Condition, die auftritt, wenn der Status einer Ressource (z. B. einer Datei, eines Speichers oder einer Variablen) überprüft (validiert oder verifiziert) und dann in separaten Schritten verwendet (geändert oder darauf zugegriffen) wird. Erlangt ein Angreifer zwischen diesen beiden Schritten Zugriff auf die Ressource und ändert sie, kann er diese Lücke aktiv ausnutzen, um ein schädliches Verhalten einzuleiten oder die Sicherheit einer Anwendung zu gefährden.

TOCTOU bei temporären Dateien

Im Zusammenhang mit dem Erstellen temporärer Dateien entstehen TOCTOU-Schwachstellen, wenn ein Programm auf das Vorhandensein einer Temp-Datei prüft, und diese dann öffnet oder erst erstellt. Gelingt es einem Angreifer, in der Zeit zwischen diesen Vorgängen eine Datei mit demselben Namen zu erstellen, kann er den Inhalt oder die Eigenschaften der Datei kontrollieren, von der das Programm annimmt, dass sie sicher erstellt wird oder auf die zugegriffen werden kann.

Betrachten wir beispielhaft die Abfolge der Vorgänge:

1. Das Programm prüft, ob bereits eine temporäre Datei (z. B. tempfile.txt) existiert.
2. Existiert die Datei nicht, wird sie vom Programm erstellt – ggf. geöffnet.

Legt ein Angreifer eine Datei mit dem Namen tempfile.txt in der Zeit zwischen der Überprüfung und dem Erstellen einer Temp-Datei durch die Anwendung an, interagiert das Programm möglicherweise versehentlich mit der Datei des Angreifers und nicht mit der legitimen, sicheren Datei. Dies kann zu Problemen wie unbefugtem Datenzugriff, Beschädigung oder Rechteausweitung führen.

Detailliertes Codebeispiel einer TOCTOU-Sicherheitslücke:

import java.io.File;
import java.io.IOException;

public class TOCTOUVulnerabilityExample {
    public static void main(String[] args) throws IOException {
        File tempFile = new File("/tmp/tempfile.txt");

        // Time-of-check: Verify whether the file exists
        if (!tempFile.exists()) {
            // Time-of-use: Create the file
            tempFile.createNewFile();
            System.out.println("Temporary file created at: " + tempFile.getAbsolutePath());
        }
    }
}

1. Das Programm prüft zunächst mithilfe der exists()-Methode, ob tempfile.txt existiert.
2. Wenn die Datei nicht existiert, wird mit dem Befehl createNewFile() eine neue Datei mit demselben Namen erstellt.

Die Schwachstelle liegt hier genau zwischen den Zeitpunkten der Methodenaufrufe exists() zum Überprüfen, ob die Datei existiert und dem Aufruf createNewFile(), um die Datei dann auch tatsächlich zu erzeugen. Die zeitliche Lücke zwischen den beiden Methodenaufrufen können Angreifer ausnutzen, um eine eigene, potenziell gefährliche Datei mit dem Namen tempfile.txt einzuschleusen.

Ausnutzen von TOCTOU in temporären Dateien

Angreifer können TOCTOU-Schwachstellen auf verschiedene Arten ausnutzen:

File Pre-Creation: Der Angreifer erstellt eine Datei mit demselben Namen wie die beabsichtigte temporäre Datei in einem Verzeichnis, auf das die Anwendung zugreifen kann. Wenn die Dateiberechtigungen schwach sind, kann der Angreifer die Kontrolle über den Inhalt dieser Datei erlangen.

Symlink Attack: Der Angreifer kann einen symbolischen Link (Symlink) erstellen, der auf eine vertrauliche Datei (z. B. /etc/passwd) mit demselben Namen wie die temporäre Datei verweist. Wenn das Programm versucht, in die temporäre Datei zu schreiben oder daraus zu lesen, greift es möglicherweise stattdessen auf die vertrauliche Datei zu, was zu Datenbeschädigung oder Informationslecks führen kann.

Privilege Escalation: Wird ein Programm mit erhöhten Rechten ausgeführt (z. B. als Root), könnte ein Angreifer die TOCTOU-Race-Condition ausnutzen, um Dateien oder Daten zu ändern, auf die er sonst nicht zugreifen oder die er nicht ändern darf.

Verhindern von TOCTOU-Schwachstellen in Java

Um TOCTOU-Schwachstellen zu verhindern, insbesondere beim Umgang mit temporären Dateien, sollten Entwickler verschiedene Best Practices befolgen, die das Risiko einer Race Condition minimieren:

1. Verwenden Sie atomare Operationen

Atomare Operationen sind untrennbar miteinander verbunden. Sie werden entweder vollständig abgeschlossen oder treten überhaupt nicht auf, sodass ein Angreifer keine Möglichkeit zum Eingreifen hat. Die Methode File.createTempFile() von Java ist beim Erstellen temporärer Dateien atomar. Das bedeutet, dass die Dateierstellung und Namensgenerierung in einem einzigen Schritt erfolgt, wodurch das typische TOCTOU-Zeitfenster entfällt.

import java.io.File;
import java.io.IOException;

public class AtomicTempFileCreation {
    public static void main(String[] args) throws IOException {
        // Atomic operation to create a temporary file
        File tempFile = File.createTempFile("tempfile_", ".tmp");
        tempFile.deleteOnExit();
        System.out.println("Secure temporary file created at: " + tempFile.getAbsolutePath());
    }
}

File.createTempFile() stellt sicher, dass die Datei sowohl einen eindeutigen Namen hat als auch sicher erstellt wird, ohne dass die Anwendung Race Conditions ausgesetzt wird.

2. Verwenden von sicheren Verzeichnissen

Temporäre Dateien müssen in einem sicheren, privaten Verzeichnis, auf das andere Benutzer keinen Zugriff haben, platziert werden. Dies schränkt die Möglichkeiten von Angreifern deutlich ein, TOCTOU-Schwachstellen auszunutzen, da sie Dateien in diesen Verzeichnissen nicht einfach ablegen oder manipulieren können.

3. Nutzen von Files und Path (NIO.2-API)

Die NIO.2-API von Java (java.nio.file) bietet erweiterte Dateiverarbeitungsmechanismen, einschließlich atomarer Dateioperationen. Beispielsweise ermöglicht Files.createTempFile() das Erstellen atomarer Dateien mit anpassbaren Dateiattributen, wie etwa sicheren Berechtigungen, wodurch sich das Risiko von TOCTOU-Schwachstellen weiter reduzieren lässt.

import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.PosixFilePermissions;
import java.util.Set;

public class SecureAtomicTempFile {
    public static void main(String[] args) throws IOException {
        // Create a temporary file with atomic operations and secure permissions
        Path tempFile = Files.createTempFile("secure_tempfile_", ".tmp", 
            PosixFilePermissions.asFileAttribute(PosixFilePermissions.fromString("rw-------")));
        System.out.println("Secure temporary file created at: " + tempFile.toAbsolutePath());
    }
}

Dieser Ansatz kombiniert das Erstellen atomarer Dateien mit restriktiven Dateiberechtigungen und verringert sowohl das Auftreten von TOCTOU-Schwachstellen als auch andere potenzielle Sicherheitsrisiken.

Fazit

TOCTOU-Schwachstellen stellen ein erhebliches Sicherheitsrisiko beim Umgang mit temporären Dateien dar, insbesondere wenn diese Dateien auf unsichere oder nicht-atomare Weise erstellt werden. Der Schlüssel zur Vermeidung dieser Schwachstellen liegt in der Beseitigung der Lücke zwischen dem Zeitpunkt der Überprüfung und dem Zeitpunkt der Nutzung, typischerweise durch den Einsatz atomarer Dateierstellungsmethoden – etwa die von sicheren APIs wie File.createTempFile() oder Files.createTempFile().

Durch das Verständnis der mit den TOCTOU-Race-Conditions verbundenen Risiken und das Befolgen von Best Practices können Entwickler sicherstellen, dass ihre Java-Anwendungen diesen Angriffen standhalten und die Integrität und Sicherheit der Software aufrechterhalten bleibt.

Happy Coding
Sven

(map [17])

URL dieses Artikels:
https://www.heise.de/-10081613

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Secure-Coding-CWE-377-Unsichere-temporaere-Dateien-und-wie-man-sie-vermeidet-10028888.html
[2] https://www.heise.de/hintergrund/Secure-Coding-Einfuehrung-in-sichere-Programmierpraktiken-fuer-Java-9982115.html
[3] https://www.heise.de/hintergrund/Secure-Coding-Unbefugten-Zugriff-durch-Path-Traversal-CWE-22-verhindern-9982270.html
[4] https://www.heise.de/hintergrund/Secure-Coding-Best-Practices-zum-Einsatz-von-Java-NIO-gegen-Path-Traversal-9990635.html
[5] https://www.heise.de/hintergrund/Secure-Coding-Mit-Unit-Testing-und-Best-Practices-zu-mehr-Softwaresicherheit-10005155.html
[6] https://www.heise.de/hintergrund/Secure-Coding-CWE-377-Unsichere-temporaere-Dateien-und-wie-man-sie-vermeidet-10028888.html
[7] https://www.heise.de/hintergrund/Secure-Coding-CWE-377-TOCTOU-Race-Conditions-in-den-Griff-bekommen-10081613.html
[8] https://www.heise.de/hintergrund/Secure-Coding-Sichere-Fehlerbehandlung-in-Java-CWE-778-Risiken-vermeiden-10084007.html
[9] https://www.heise.de/hintergrund/Secure-Coding-CWE-1007-die-unsichtbare-Gefahr-durch-visuell-aehnliche-Zeichen-10188217.html
[10] https://www.heise.de/hintergrund/Secure-Coding-CWE-1123-Sich-selbst-modifizierenden-Code-vermeiden-10194617.html
[11] https://www.heise.de/hintergrund/Secure-Coding-Probleme-durch-CWE-416-Use-After-Free-in-Java-vermeiden-10233417.html
[12] https://www.heise.de/hintergrund/Secure-Coding-Apache-Maven-gegen-Cache-Poisoning-Attacken-ruesten-10244779.html
[13] https://www.heise.de/hintergrund/Secure-Coding-Risiken-einschaetzen-mit-dem-Exploit-Prediction-Scoring-System-10252792.html
[14] https://www.heise.de/hintergrund/Secure-Coding-Passwort-Hashing-zum-Schutz-vor-Brute-Force-und-Rainbow-Tabellen-10265244.html
[15] https://www.heise.de/hintergrund/Secure-Coding-Sicherere-Passwoerter-mit-Salt-Pepper-und-Hashing-10274977.html
[16] https://www.heise.de/hintergrund/Secure-Coding-Sichere-Datenhaltung-in-der-JVM-Risiken-und-Best-Practices-10281133.html
[17] mailto:map@ix.de

Copyright © 2024 Heise Medien