Abhängigkeit von nicht aktualisierbarer Komponente

Beschreibung

Die Abhängigkeit von einer nicht aktualisierbaren Komponente tritt auf, wenn ein Produkt eine Komponente enthält, die nicht aktualisiert oder gepatcht werden kann, um Schwachstellen oder kritische Fehler zu beheben. Wenn Komponenten keine Aktualisierbarkeit besitzen, können Organisationen entdeckte Sicherheitsprobleme oder Defekte nicht beheben, was Betreiber zwingt, zwischen Akzeptanz des laufenden Risikos oder kostspieligen Austausch zu wählen. Das Problem ist besonders akut in Branchen wie Gesundheitswesen und Industriesteuerung, wo Geräte jahrzehntelang betrieben werden. Sowohl Hardware (ROM, Firmware) als auch Software (nicht gewartete Treiber/Bibliotheken) können diese Schwachstelle aufweisen.

Risiko

Nicht aktualisierbare Komponenten haben schwerwiegende Auswirkungen. Bekannte Schwachstellen bleiben auf unbestimmte Zeit ausnutzbar. Sicherheitspatches können nicht angewendet werden. Regulatorische Compliance unmöglich. Kostspieliger Geräteaustausch erforderlich. Erweiterte Expositionsfenster. Lieferkettenrisiken. End-of-Support-Szenarien. Permanente Sicherheitslücken. Legacy-System-Schwachstellen. Hohe Auswirkung in Branchen mit länger Lebensdauer (Medizin, Industrie, Automobil).

Lösung

Fordern Sie Aktualisierbarkeit für alle Komponenten einschließlich ROM und Firmware während der Anforderungsphase. Entwerfen Sie Systemarchitekturen, die Komponentenaktualisierungen und die notwendige Infrastruktur während der Entwurfsphase unterstützen. Für Hardware implementieren Sie im-Feld-patchbare Mechanismen über Hardware-Fuses (mäßige Wirksamkeit). Entwickeln Sie die notwendige Funktionalität zur Komponentenaktualisierung während der Implementierungsphase. Planen Sie End-of-Life und Aktualisierungsmechanismen von Anfang an.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Bekannte Schwachstellen exponieren vertrauliche Daten auf unbestimmte Zeit.
Integrität	Bereich: Integrität Integritätskompromittierungen können nicht durch Patching behoben werden.
Zugriffskontrolle	Bereich: Zugriffskontrolle Schutzmechanismus-Umgehungen bleiben ausnutzbar.
Verfügbarkeit	Bereich: Verfügbarkeit Denial-of-Service-Schwachstellen bestehen ohne Patches fort.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: Eingebettetes System mit nicht aktualisierbarer Firmware

#include <stdint.h>

// VERWUNDBAR: Firmware im Execute-in-Place-ROM
const uint8_t __attribute__((section(".rom"))) firmware[] = {
    // Gesamtes Firmware-Image
    // Einschließlich aller Schwachstellen
    // Kann nach der Fertigung nicht geändert werden
};

// VERWUNDBAR: Fest kodierte Zugangsdaten
const char __attribute__((section(".rom"))) jtag_password[] = "factory_default";

// VERWUNDBAR: Kein Aktualisierungsmechanismus
void check_for_updates(void) {
    // Nicht implementiert - Aktualisierungen nicht möglich
    return;
}

Sichere Lösung

// SICHER: Eingebettetes System mit Firmware-Aktualisierungsfähigkeit

#include <stdint.h>
#include <stdbool.h>

typedef struct {
    uint32_t version;
    uint32_t size;
    uint8_t  signature[64];
    uint8_t  data[];
} firmware_update_t;

#define FIRMWARE_REGION_A   0x10000000
#define FIRMWARE_REGION_B   0x10100000

// SICHER: Sicherer Aktualisierungsmechanismus
bool secure_apply_update(const firmware_update_t* update) {
    // SICHER: Signatur verifizieren
    if (!verify_firmware_signature(update)) return false;

    // SICHER: Version prüfen (Anti-Rollback)
    uint32_t current_version = get_current_firmware_version();
    if (update->version <= current_version) return false;

    // SICHER: In inaktive Region schreiben
    uint32_t inactive_region = get_inactive_region();
    if (!write_firmware(inactive_region, update->data, update->size)) return false;

    // SICHER: Geschriebene Daten verifizieren
    if (!verify_firmware_integrity(inactive_region, update)) {
        erase_region(inactive_region);
        return false;
    }

    // SICHER: Aktive Region umschalten
    set_active_firmware(inactive_region);
    increment_version_counter();
    return true;
}

// SICHER: Zugangsdaten in aktualisierbarem Speicher
bool update_credentials(const uint8_t* new_key, size_t key_len) {
    return secure_write_credential(new_key, key_len);
}

// SICHER: Schlüsselwiderrufunterstützung
bool revoke_key(uint32_t key_id) {
    return add_to_revocation_list(key_id);
}

---

CVE-Beispiele

• CVE-2020-9054: Zyxel-NAS-Geräte mit OS-Command-Injection-Schwachstellen, die End-of-Support sind und ungepatcht bleiben.
• CVE-2019-11477: Linux-Kernel-TCP-Schwachstelle, die Geräte mit nicht aktualisierbarer Firmware betrifft.

---

Verwandte CWEs

• CWE-664: Improper Control of a Resource Through its Lifetime (Eltern)
• CWE-1357: Reliance on Insufficiently Trustworthy Component (Eltern)
• CWE-1277: Firmware Not Updateable (Kind)
• CWE-1310: Missing Ability to Patch ROM Code (Kind)

---

Referenzen

1. MITRE Corporation. "CWE-1329: Reliance on Component That is Not Updateable." https://cwe.mitre.org/data/definitions/1329.html
2. FDA. "Postmarket Management of Cybersecurity in Medical Devices"
3. NIST. "Guidelines for IoT Device Security"