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…

Définition

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.
Impact réel

Real-world CVEs caused by CWE-1331

  • Improper isolation of shared resource in a network-on-chip leads to denial of service

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

  1. 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. 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. 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. 4

    There may be different ways to fix this particular weakness.

Exemple de code vulnérable

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.

Vulnérable
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.
Charge utile de l'attaquant

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.

Charge utile de l'attaquant
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.
Exemple de code sécurisé

Secure Other

There may be different ways to fix this particular weakness.

Sécurisé Other
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.
Liste de contrôle de prévention

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.
Signaux de détection

How to detect CWE-1331

Manual Analysis Moderate

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

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.

Questions fréquentes

Frequently asked questions

Qu'est-ce que 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.

Quelle est la gravité de CWE-1331 ?

MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.

Quels langages ou plateformes sont affectés par CWE-1331 ?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Security Hardware, Not Technology-Specific.

Comment puis-je prévenir CWE-1331 ?

Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.

Comment Plexicus détecte et corrige CWE-1331 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-1331 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.

Où puis-je en savoir plus sur CWE-1331 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/1331.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Prêt à valider l'essentiel ?

Prêt à valider ce qui compte.

Plexicus est Proof-Driven AppSec : findings validés, compréhension contextuelle et remédiation relue — ancrée dans la preuve, scopée avec vous.

Qualification

Vérifiez si l'AI Swarm Pentest convient à votre environnement.

Partagez le contexte minimum. Nous vérifierons le périmètre et indiquerons la prochaine étape commerciale.

Avant d'envoyer — vérifiez que vous correspondez

0 / 280

Sans engagement. Si vous ne correspondez pas, nous vous le dirons.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Tour privé Pour les investisseurs