Unsachgemäße Verhinderung der Sperrbit-Modifikation

Beschreibung

Unsachgemäße Verhinderung der Sperrbit-Modifikation tritt auf, wenn ein System ein vertrauenswürdiges Sperrbit verwendet, um den Zugriff auf Register oder Ressourcen einzuschränken, aber die Modifikation des Sperrbits selbst nach der Initialisierung nicht verhindert. Hardware-Geräte sperren typischerweise Konfigurationskontrollen nach dem Einschalten über einen Sperrbit-Mechanismus, der weitere Schreibvorgänge auf geschützte Register deaktiviert. Design- oder Implementierungsfehler können jedoch Angreifern ermöglichen, das Sperrbit nach der Initialisierung zu modifizieren oder zu löschen, was potenziell geschützte Funktionen entsperrt und die Systemsicherheit kompromittiert.

Risiko

Schwachstellen bei der Sperrbit-Modifikation haben schwerwiegende Sicherheitsauswirkungen. Geschützte Konfigurationen können entsperrt und modifiziert werden. Sicherheitseinstellungen können nach dem Boot deaktiviert werden. Debug-Schnittstellen können wieder aktiviert werden. Secure-Boot-Schutz kann umgangen werden. Fuse-basierter Schutz kann umgangen werden. Firmware-Integrität kann kompromittiert werden. Rechteeskalation kann möglich sein. Hardware-Sicherheitsgrenzen können verletzt werden.

Lösung

Schützen Sie Sperrbits vor Modifikation nach dem Setzen. Stellen Sie sicher, dass Sperrbits nicht von Software nach der Initialisierung gelöscht werden können. Verwenden Sie hardware-erzwungene Write-Once-Sperrmechanismen. Überprüfen Sie, dass alle Reset-Pfade den Sperrbit-Zustand erhalten. Entfernen Sie Peripherie-Reset-Signale aus den Sperrbit-Reset-Bedingungen. Testen Sie die Sperrbit-Persistenz über alle Systemzustände. Implementieren Sie redundante Sperrmechanismen. Prüfen Sie Sperrbit-Implementierungen auf Umgehungspfade. Erwägen Sie die Verwendung irreversibler Fuses für kritische Sperren.

Häufige Auswirkungen

Auswirkung	Details
Zugriffskontrolle	Bereich: Zugriffskontrolle Speicher modifizieren – Geschützte Register können verändert werden, obwohl die Sperre vermeintlich aktiv ist, was den Zugriffskontrollschutz kompromittiert.
Integrität	Bereich: Integrität Umgehung von Schutzmechanismen – Sicherheitskonfigurationen können nach vermeintlicher Sicherung entsperrt und modifiziert werden.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: Sperrbit kann durch Peripherie-Reset gelöscht werden

module vulnerable_register_lock (
    input wire clk,
    input wire rst_ni,
    input wire jtag_unlock,
    input wire rst_peripheral,  // Peripherie-spezifischer Reset
    input wire [31:0] write_data,
    input wire write_enable,
    input wire lock_write,
    output reg [31:0] protected_register,
    output reg register_locked
);

    always @(posedge clk or negedge rst_ni) begin
        // VERWUNDBAR: Sperr-Reset enthält Peripherie-Reset
        // Angreifer kann Peripherie-Reset auslösen, um Sperre zu löschen!
        if (~(rst_ni && ~jtag_unlock && ~rst_peripheral)) begin
            register_locked <= 1'b0;  // Sperre gelöscht!
            protected_register <= 32'h0;
        end
        else begin
            if (lock_write && !register_locked) begin
                register_locked <= 1'b1;
            end

            if (write_enable && !register_locked) begin
                protected_register <= write_data;
            end
        end
    end

endmodule

Sichere Lösung

// SICHER: Sperrbit vor Modifikation geschützt

module secure_register_lock (
    input wire clk,
    input wire rst_ni,
    input wire jtag_unlock,
    input wire rst_peripheral,
    input wire [31:0] write_data,
    input wire write_enable,
    input wire lock_write,
    output reg [31:0] protected_register,
    output reg register_locked
);

    always @(posedge clk or negedge rst_ni) begin
        // SICHER: Sperre nur durch globalen Reset oder authentifizierten JTAG gelöscht
        // Peripherie-Reset beeinflusst Sperre NICHT
        if (~rst_ni) begin
            register_locked <= 1'b0;
            protected_register <= 32'h0;
        end
        else if (jtag_unlock) begin
            // Nur authentifizierter JTAG kann Sperre löschen
            register_locked <= 1'b0;
        end
        else begin
            // Sperre kann nur von 0 auf 1 wechseln
            if (lock_write && !register_locked) begin
                register_locked <= 1'b1;
            end
            // Sperre kann nicht von Software gelöscht werden

            if (write_enable && !register_locked) begin
                protected_register <= write_data;
            end
        end
    end

endmodule

---

CVE-Beispiele

• CVE-2017-6283: Chip-Reset löscht kritische RSA-Funktions-Lese/Schreib-Sperrberechtigungen
• OpenPiton SoC-Schwachstellen von HACK@DAC'21 zeigten Sperrbit-Umgehung durch Peripherie-Reset

---

Verwandte CWEs

• CWE-284: Improper Access Control (übergeordnet)
• CWE-1199: General Circuit and Logic Design Concerns (Kategoriemitglied)
• CWE-1224: Improper Restriction of Write-Once Bit Fields (verwandt)
• CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection (verwandt)

---

Referenzen

1. MITRE Corporation. "CWE-1231: Improper Prevention of Lock Bit Modification." https://cwe.mitre.org/data/definitions/1231.html
2. Richtlinien zum Design von Hardware-Sicherheits-Sperrbits
3. OpenPiton SoC-Sicherheitsanalyse