CWE-1310 Base Draft

Missing Ability to Patch ROM Code

A system or System-on-Chip (SoC) lacks a mechanism to update its initial boot code stored in Read-Only Memory (ROM), permanently exposing devices to unfixable security vulnerabilities.

Definition

What is CWE-1310?

A system or System-on-Chip (SoC) lacks a mechanism to update its initial boot code stored in Read-Only Memory (ROM), permanently exposing devices to unfixable security vulnerabilities.
Many secure systems start by running foundational code from an immutable ROM, which establishes a hardware Root of Trust. Since this ROM code is permanently etched into the chip during manufacturing, any security flaws discovered after the device ships become permanent. This creates a critical, unchangeable weakness in every deployed unit. Without a built-in patching capability for this ROM stage, the entire system remains vulnerable to exploitation. Attackers can target these unfixable flaws to compromise the boot process, potentially bypassing all subsequent security layers and taking full control of the SoC.
Auswirkungen in der Praxis

Real-world CVEs caused by CWE-1310

Bisher sind in MITREs Katalog keine öffentlichen CVE-Referenzen mit dieser CWE verknüpft.

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

  1. 1

    A System-on-Chip (SOC) implements a Root-of-Trust (RoT) in ROM to boot secure code. However, at times this ROM code might have security vulnerabilities and need to be patched. Since ROM is immutable, it can be impossible to patch.

  2. 2

    ROM does not have built-in application-programming interfaces (APIs) to patch if the code is vulnerable. Implement mechanisms to patch the vulnerable ROM code.

  3. 3

    The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.

  4. 4

    The above implementation causes the ROM data to be hardcoded for the linux system (rom_rdata_linux) regardless of the value of ariane_boot_sel_i. Therefore, the data (rom_rdata_patch) from the patchable ROM code is never used [REF-1396]. This weakness disables the ROM's ability to be patched. If attackers uncover security vulnerabilities in the ROM, the users must replace the entire device. Otherwise, the weakness exposes the system to a vulnerable state forever. A fix to this issue is to enable rom_rdata to be selected from the patchable rom (rom_rdata_patch) [REF-1397].

Verwundbares Codebeispiel

Vulnerable Verilog

The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.

Verwundbar Verilog 
...

```
   bootrom i_bootrom_patch (
  	 .clk_i ,
  	 .req_i ( rom_req ),
  	 .addr_i ( rom_addr ),
  	 .rdata_o ( rom_rdata_patch )
   );
   bootrom_linux i_bootrom_linux (
  	 .clk_i ,
  	 .req_i ( rom_req ),
  	 .addr_i ( rom_addr ),
  	 .rdata_o ( rom_rdata_linux )
   );
```
assign rom_rdata = (ariane_boot_sel_i) ? rom_rdata_linux : rom_rdata_linux;** 
 ...
Sicheres Codebeispiel

Secure Verilog

The above implementation causes the ROM data to be hardcoded for the linux system (rom_rdata_linux) regardless of the value of ariane_boot_sel_i. Therefore, the data (rom_rdata_patch) from the patchable ROM code is never used [REF-1396]. This weakness disables the ROM's ability to be patched. If attackers uncover security vulnerabilities in the ROM, the users must replace the entire device. Otherwise, the weakness exposes the system to a vulnerable state forever. A fix to this issue is to enable rom_rdata to be selected from the patchable rom (rom_rdata_patch) [REF-1397].

Sicher Verilog 
...

```
   bootrom i_bootrom_patch (
  	 .clk_i ,
  	 .req_i ( rom_req ),
  	 .addr_i ( rom_addr ),
  	 .rdata_o ( rom_rdata_patch )
   );
   bootrom_linux i_bootrom_linux (
  	 .clk_i ,
  	 .req_i ( rom_req ),
  	 .addr_i ( rom_addr ),
  	 .rdata_o ( rom_rdata_linux )
   );
```
assign rom_rdata = (ariane_boot_sel_i) ? rom_rdata_patch : rom_rdata_linux;** 
 ...
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Präventions-Checkliste

How to prevent CWE-1310

  • Architecture and Design / Implementation Secure patch support to allow ROM code to be patched on the next boot.
  • Architecture and Design / Implementation Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.
Erkennungssignale

How to detect CWE-1310

SAST High

Führe statische Analyse (SAST) auf der Codebasis aus und suche im Datenfluss nach dem unsicheren Muster.

DAST Moderate

Führe dynamische Application-Security-Tests gegen den Live-Endpoint aus.

Runtime Moderate

Beobachte Runtime-Logs auf ungewöhnliche Exception-Traces, fehlerhafte Eingaben oder Versuche, Autorisierung zu umgehen.

Code review Moderate

Code Review: Markiere jeden neuen Code, der Eingaben von dieser Oberfläche ohne validierte Framework-Helper verarbeitet.

Plexicus Auto-Fix

Plexicus erkennt CWE-1310 automatisch und öffnet in unter 60 Sekunden einen Fix-PR.

Codex Remedium scannt jeden Commit, identifiziert genau diese Schwachstelle und liefert einen reviewer-ready Pull Request mit dem Patch. Keine Tickets. Keine Hand-offs.

Demo anfordern Plexicus kostenlos testen
Häufig gestellte Fragen

Frequently asked questions

Was ist CWE-1310?

A system or System-on-Chip (SoC) lacks a mechanism to update its initial boot code stored in Read-Only Memory (ROM), permanently exposing devices to unfixable security vulnerabilities.

Wie gravierend ist CWE-1310?

MITRE hat für diese Schwachstelle keine Exploit-Wahrscheinlichkeit veröffentlicht. Behandle sie als mittlere Auswirkung, bis dein Threat Model anderes belegt.

Welche Sprachen oder Plattformen sind von CWE-1310 betroffen?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, System on Chip.

Wie kann ich CWE-1310 verhindern?

Secure patch support to allow ROM code to be patched on the next boot. Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.

Wie erkennt und behebt Plexicus CWE-1310?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-1310 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.

Wo erfahre ich mehr über CWE-1310?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/1310.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Verwandte Schwachstellen

Weaknesses related to CWE-1310

CWE-1329 Parent

Reliance on Component That is Not Updateable

This vulnerability occurs when a product depends on a component that cannot be updated or patched to fix security flaws or critical bugs.

CWE-1277 Sibling

Firmware Not Updateable

This vulnerability occurs when a hardware product lacks a mechanism for users to install firmware updates, leaving known security flaws…

Ressourcen

Further reading

Bereit, wenn du es bist

Schluss mit dem Bezahlen pro Entwickler.
Schließ den Kreislauf.

Plexicus ist die KI-native ASPM, die scannt, filtert, fixt, pentestet und erklärt — autonom. Unbegrenzte Entwickler, unbegrenzte Repos, Fair-Use-KI-Aktionen. Echter kostenloser Tarif, €269/mo jährlich, wenn du bereit bist.

Kostenlos starten Demo buchen