CWE-1331: Improper Isolation of Shared Resources in Network On Chip (NoC)

What is Improper Isolation of Shared Resources in Network On Chip (NoC)?

• Overview: Improper Isolation of Shared Resources in Network On Chip (NoC) occurs when the internal resources of a NoC, such as buffers and channels, are not correctly isolated between trusted and untrusted entities. This improper isolation can allow untrusted agents to interfere with or infer data from trusted agents through timing channels.

• Exploitation Methods:

• Attackers can exploit this vulnerability by sending specially crafted packets to create contention in shared resources, observing timing variations to infer sensitive information.
• Common attack patterns include side-channel attacks, where attackers analyze the timing or resource usage patterns to extract confidential data.

• Security Impact:

• Direct consequences of successful exploitation include unauthorized access to sensitive data and information leakage through timing channels.
• Potential cascading effects include degraded network performance, increased latency, and throughput reduction due to resource contention.
• Business impact can involve loss of data confidentiality, potential compliance violations, and damage to the organization's reputation.

• Prevention Guidelines:

• Specific code-level fixes include implementing proper isolation mechanisms and partitioning critical resources to prevent sharing between trusted and untrusted domains.
• Security best practices involve using access controls and resource allocation policies to limit the interaction between different trust domains.
• Recommended tools and frameworks include using hardware-based isolation technologies and adopting secure NoC architectures that inherently separate trusted and untrusted traffic.

Corgea can automatically detect and fix Improper Isolation of Shared Resources in Network On Chip (NoC) in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: Not specified

Affected Languages: Not Language-Specific

Affected Technologies: Security Hardware, Not Technology-Specific

"Network-on-chip" (NoC) is a commonly-used term used for hardware interconnect fabrics used by multicore Systems-on-Chip (SoC). Communication between modules on the chip uses packet-based methods, with improved efficiency and scalability compared to bus architectures [REF-1241].

Vulnerable Code Example

# Simulates a Network on Chip (NoC) that improperly isolates shared resources
class NetworkOnChip:
    def __init__(self):
        self.shared_memory = {}  # Shared memory resource accessible to all agents

    def process_request(self, agent_id, data):
        # All agents can access the shared_memory directly
        self.shared_memory[agent_id] = data
        return self.shared_memory

Explanation:

• Vulnerability: The shared_memory is directly accessible to all agents, both trusted and untrusted. This lack of isolation allows any agent to read or modify the data of other agents, potentially leading to data leakage, unauthorized data modification, and timing attacks.

How to fix Improper Isolation of Shared Resources in Network On Chip (NoC)?

To mitigate this vulnerability, proper isolation mechanisms need to be implemented to ensure that shared resources are only accessible by authorized agents. This can be achieved by:

1. Access Controls: Implement strict access controls to ensure only trusted agents can access or modify shared resources.
2. Data Encryption: Encrypt data stored in shared resources to protect it from unauthorized access and tampering.
3. Sandboxing: Use sandboxing techniques to isolate the execution environments of different agents, preventing them from affecting each other.

Fixed Code Example

from cryptography.fernet import Fernet

class SecureNetworkOnChip:
    def __init__(self):
        self.shared_memory = {}  # Encapsulated memory resource
        self.keys = {}  # Unique encryption keys for each agent

    def register_agent(self, agent_id):
        # Generate and store a unique encryption key for each agent
        self.keys[agent_id] = Fernet.generate_key()

    def process_request(self, agent_id, data):
        if agent_id not in self.keys:
            raise ValueError("Agent not registered")

        # Encrypt the data with the agent's unique key
        cipher_suite = Fernet(self.keys[agent_id])
        encrypted_data = cipher_suite.encrypt(data.encode())

        # Store encrypted data, accessible only by the agent with the correct key
        self.shared_memory[agent_id] = encrypted_data

    def retrieve_data(self, agent_id):
        if agent_id not in self.keys:
            raise ValueError("Agent not registered")

        # Decrypt and return the data for the specific agent
        cipher_suite = Fernet(self.keys[agent_id])
        encrypted_data = self.shared_memory.get(agent_id, None)
        
        if encrypted_data:
            return cipher_suite.decrypt(encrypted_data).decode()
        else:
            return None

Explanation:

• Access Controls: Each agent is registered with a unique encryption key, ensuring only authorized agents can access their data.
• Data Encryption: Data for each agent is encrypted before storage, isolating it from unauthorized agents.
• Encapsulation: The shared memory is now encapsulated within the class, and direct access is mediated through controlled interfaces that check for agent registration and use encryption to maintain data integrity and confidentiality.