Providing marker flags to send through the interfaces coupled with examination of which users are able to read or manipulate the flags will help verify that the proper isolation has been achieved and is effective.
CWE-1331 Base Stable
Improper Isolation of Shared Resources in Network On Chip (NoC)
This vulnerability occurs when a Network on Chip (NoC) fails to properly separate its internal, shared resources—like buffers, switches, and channels—between trusted and untrusted components. This…
Definition
What is CWE-1331?
This vulnerability occurs when a Network on Chip (NoC) fails to properly separate its internal, shared resources—like buffers, switches, and channels—between trusted and untrusted components. This lack of isolation creates a timing side-channel, allowing untrusted agents to potentially infer sensitive data from trusted ones.
Network on Chips are designed with many shared internal resources to handle data packets from different sources. When resources like internal buffers, crossbars, individual ports, and communication channels are not securely partitioned between trusted and untrusted domains, they become points of contention. This shared access introduces interference, which an attacker can measure and analyze to create a timing channel, potentially leaking information about the trusted agent's activities.
The security threat here is twofold. First, it directly enables side-channel attacks where an attacker can deduce sensitive information by observing timing variations. Second, this improper isolation can cause significant performance degradation, as network interference from untrusted domains reduces overall system throughput and increases latency for legitimate traffic.
Auswirkungen in der Praxis
Real-world CVEs caused by CWE-1331
-
Improper isolation of shared resource in a network-on-chip leads to denial of service
Wie Angreifer es ausnutzen
Angreiferpfad Schritt für Schritt
- 1
Consider a NoC that implements a one-dimensional mesh network with four nodes. This supports two flows: Flow A from node 0 to node 3 (via node 1 and node 2) and Flow B from node 1 to node 2. Flows A and B share a common link between Node 1 and Node 2. Only one flow can use the link in each cycle.
- 2
One of the masters to this NoC implements a cryptographic algorithm (RSA), and another master to the NoC is a core that can be exercised by an attacker. The RSA algorithm performs a modulo multiplication of two large numbers and depends on each bit of the secret key. The algorithm examines each bit in the secret key and only performs multiplication if the bit is 1. This algorithm is known to be prone to timing attacks. Whenever RSA performs multiplication, there is additional network traffic to the memory controller. One of the reasons for this is cache conflicts.
- 3
Since this is a one-dimensional mesh, only one flow can use the link in each cycle. Also, packets from the attack program and the RSA program share the output port of the network-on-chip. This contention results in network interference, and the throughput and latency of one flow can be affected by the other flow's demand.
- 4
There may be different ways to fix this particular weakness.
Verwundbares Codebeispiel
Vulnerable code
Since this is a one-dimensional mesh, only one flow can use the link in each cycle. Also, packets from the attack program and the RSA program share the output port of the network-on-chip. This contention results in network interference, and the throughput and latency of one flow can be affected by the other flow's demand.
The attacker runs a loop program on the core they control, and this causes a cache miss in every iteration for the RSA algorithm. Thus, by observing network-traffic bandwidth and timing, the attack program can determine when the RSA algorithm is doing a multiply operation (i.e., when the secret key bit is 1) and eventually extract the entire, secret key. Angreifer-Payload
Since this is a one-dimensional mesh, only one flow can use the link in each cycle. Also, packets from the attack program and the RSA program share the output port of the network-on-chip. This contention results in network interference, and the throughput and latency of one flow can be affected by the other flow's demand.
The attacker runs a loop program on the core they control, and this causes a cache miss in every iteration for the RSA algorithm. Thus, by observing network-traffic bandwidth and timing, the attack program can determine when the RSA algorithm is doing a multiply operation (i.e., when the secret key bit is 1) and eventually extract the entire, secret key. Sicheres Codebeispiel
Secure Other
There may be different ways to fix this particular weakness.
Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents. 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-1331
- Architecture and Design / Implementation Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.
Erkennungssignale
How to detect CWE-1331
CWE-1331
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Häufig gestellte Fragen Was ist CWE-1331?
Wie gravierend ist CWE-1331?
Welche Sprachen oder Plattformen sind von CWE-1331 betroffen?
Wie kann ich CWE-1331 verhindern?
Wie erkennt und behebt Plexicus CWE-1331?
Wo erfahre ich mehr über CWE-1331?
Frequently asked questions
Was ist CWE-1331?
This vulnerability occurs when a Network on Chip (NoC) fails to properly separate its internal, shared resources—like buffers, switches, and channels—between trusted and untrusted components. This lack of isolation creates a timing side-channel, allowing untrusted agents to potentially infer sensitive data from trusted ones.
Wie gravierend ist CWE-1331?
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-1331 betroffen?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Security Hardware, Not Technology-Specific.
Wie kann ich CWE-1331 verhindern?
Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.
Wie erkennt und behebt Plexicus CWE-1331?
Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-1331 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-1331?
MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/1331.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.
Verwandte Schwachstellen
Weaknesses related to CWE-1331
CWE-653 Parent
Improper Isolation or Compartmentalization
This vulnerability occurs when an application fails to enforce strong boundaries between components that operate at different security…
CWE-1189 Sibling
Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
This vulnerability occurs when a System-on-a-Chip (SoC) fails to properly separate shared hardware resources between secure (trusted) and…
Ressourcen
Further reading
- MITRE — offizielle CWE-1331 https://cwe.mitre.org/data/definitions/1331.html
- SurfNoC: A Low Latency and Provably Non-Interfering Approach to Secure Networks-On-Chip http://cseweb.ucsd.edu/~kastner/papers/isca13-surfNOC.pdf
- Network on a chip https://en.wikipedia.org/wiki/Network_on_a_chip
- A Survey of Network-on-Chip Security Attacks and Countermeasures https://dl.acm.org/doi/fullHtml/10.1145/3450964
- Design of Secure and Trustworthy Network-on-chip Architectures https://www.cise.ufl.edu/research/cad/Publications/charlesThesis.pdf
Bereit, das Wesentliche zu validieren?
Bereit zu validieren, was zählt.
Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.