Remanente Daten nach Speicherlöschung lesbar

Beschreibung

Remanente Daten nach Speicherlöschung lesbar tritt auf, wenn vertrauliche Informationen, die in Speicherschaltkreisen gespeichert sind, nach dem Löschen oder Bereinigen lesbar oder wiederherstellbar bleiben. Datenremanenz tritt auf, wenn Speicherinhalte nach Löschoperationen bestehen bleiben, aufgrund von Leistungsoptimierungsdesigns, die Metadaten aber nicht tatsächliche Inhalte löschen, physikalischen Eigenschaften von Speicherschaltkreisen (SRAM/DRAM-Ladungserhaltung beeinflusst durch Strom, Auffrischungsraten, Temperatur) oder unvollständiger Implementierung sicherer Löschverfahren. Dies ermöglicht unbefugten Zugriff auf sensible Informationen nach Geräte-Reset oder Zweitverwendung.

Risiko

Remanente Daten haben schwerwiegende Auswirkungen. Vertrauliche Daten nach Löschung wiederherstellbar. Daten des Vorbesitzers zugänglich. Kryptografische Schlüssel extrahierbar. Authentifizierungsdaten exponiert. Datenschutzverletzungen. Regulatorische Compliance-Verstoße. Risiken beim Geräteweiterverkauf. Cold-Boot-Angriffe ermöglicht. Speicherforensik möglich. Hohes Risiko bei Eigentümerwechsel oder Außerdienststellung von Geräten.

Lösung

Implementieren Sie während der Architektur- und Entwurfsphase mehrfaches Speicherüberschreiben mit bekannten Mustern vor der Löschung. Verwenden Sie kryptografisches Löschen bei selbstverschlüsselnden Speichergeräten. Wenden Sie physische Löschwerkzeuge an (z.B. UV-basiertes EEPROM-Löschen). Verwenden Sie physische Zerstörung für außer Betrieb genommene Geräte. Testen Sie Speicherinhalte nach Löschoperationen. Führen Sie Architektur- und Entwurfsprüfung von Bereinigungsimplementierungen durch.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Vertrauliche Daten von nicht vertrauenswürdigen Agenten nach Speicherlöschung lesbar.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: Software-Speicherbehandlung mit Remanenz

#include <stdlib.h>
#include <string.h>

// VERWUNDBAR: Einfaches free löscht Speicher nicht
void vulnerable_free_key(uint8_t* key, size_t len) {
    // VERWUNDBAR: free() löscht Speicherinhalte nicht
    free(key);
    // Schlüsseldaten noch im Speicher!
}

// VERWUNDBAR: memset kann wegoptimiert werden
void vulnerable_clear_buffer(uint8_t* buffer, size_t len) {
    // VERWUNDBAR: Compiler kann dies wegoptimieren
    memset(buffer, 0, len);
    free(buffer);
}

// VERWUNDBAR: Unvollständiger Werksreset
void vulnerable_factory_reset(void) {
    // VERWUNDBAR: Setzt nur Konfiguration zurück
    reset_configuration_to_defaults();
    // VERWUNDBAR: Benutzerdaten, WLAN-Passwörter etc. bleiben
}

Sichere Lösung

// SICHER: Software-Speicherbehandlung ohne Remanenz

#include <stdlib.h>
#include <string.h>
#include <stdint.h>

// SICHER: Sichere Speicherbereinigung, die nicht wegoptimiert wird
static void secure_memzero(void* ptr, size_t len) {
    volatile uint8_t* p = (volatile uint8_t*)ptr;
    while (len--) {
        *p++ = 0;
    }
    __asm__ __volatile__("" ::: "memory");
}

// SICHER: Sichere Schlüsselfreigabe
void secure_free_key(uint8_t* key, size_t len) {
    if (key) {
        // SICHER: Vor Freigabe bereinigen
        secure_memzero(key, len);
        free(key);
    }
}

// SICHER: Sichere Passwortbehandlung auf dem Stack
void secure_process_password(const char* password) {
    char local_copy[256];
    size_t len = strlen(password);
    if (len >= sizeof(local_copy)) len = sizeof(local_copy) - 1;
    memcpy(local_copy, password, len);
    local_copy[len] = '\0';

    process_authentication(local_copy);

    // SICHER: Stack-Daten vor Rückkehr bereinigen
    secure_memzero(local_copy, sizeof(local_copy));
}

// SICHER: Umfassender Werksreset
void secure_factory_reset(void) {
    // SICHER: Mehrstufige Datenlöschung gemäß NIST-Richtlinien
    secure_erase_partition("/data");
    secure_erase_partition("/cache");
    secure_erase_secure_element();
    reset_configuration_to_defaults();

    // Löschung verifizieren
    if (!verify_data_erased("/data")) {
        secure_erase_partition_extended("/data", 3);
    }
}

---

CVE-Beispiele

• CVE-2019-8575: Apple AirPort Extreme/Time Capsule Werksreset-Schwachstelle, die das Abrufen von WLAN-Name und WPA2-Schlüssel des Vorbesitzers ermöglichte.
• CVE-2020-1938: Speicheroffenlegung durch unvollständige Pufferbereinigung in Apache Tomcat.

---

Verwandte CWEs

• CWE-1301: Insufficient or Incomplete Data Removal within Hardware Component (Eltern)
• CWE-226: Sensitive Information in Resource Not Removed Before Reuse (verwandt)
• CWE-244: Improper Clearing of Heap Memory Before Release (verwandt)

---

Referenzen

1. MITRE Corporation. "CWE-1330: Remanent Data Readable after Memory Erase." https://cwe.mitre.org/data/definitions/1330.html
2. NIST SP 800-88 Revision 1. "Guidelines for Media Sanitization" (2014)
3. DoD 5220.22-M. "National Industrial Security Program Operating Manual"