CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

What is Improper Isolation of Shared Resources on System-on-a-Chip (SoC)?

• Overview: Improper Isolation of Shared Resources on System-on-a-Chip (SoC) occurs when shared resources on an SoC, such as pins or other hardware components, are not properly isolated between trusted and untrusted agents, potentially allowing unauthorized access to sensitive functions or data.

• Exploitation Methods:

• Attackers can exploit this vulnerability by accessing or interfering with shared resources that should be restricted to trusted agents.
• Common attack patterns include unauthorized data access, manipulation of hardware functions, and escalation of privileges by exploiting shared resources.

• Security Impact:

• Direct consequences of successful exploitation include unauthorized data access, data leakage, and potential manipulation of system functions.
• Potential cascading effects include compromised system integrity, loss of data confidentiality, and disruption of services.
• Business impact may involve financial loss, damage to reputation, legal liabilities, and loss of customer trust.

• Prevention Guidelines:

• Specific code-level fixes include implementing strict access controls and ensuring proper configuration of pin multiplexing to separate trusted and untrusted functions.
• Security best practices involve regular security audits, thorough testing of resource isolation, and applying the principle of least privilege.
• Recommended tools and frameworks include using SoC-specific security features, employing hardware security modules, and leveraging automated tools for resource isolation verification.

Corgea can automatically detect and fix Improper Isolation of Shared Resources on System-on-a-Chip (SoC) in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: Not specified

Affected Languages: Not Language-Specific

Affected Technologies: System on Chip

Vulnerable Code Example

# Vulnerable code demonstrating improper isolation of shared resources on a System-on-a-Chip (SoC)
class SoC:
    def __init__(self):
        # Shared resource between trusted and untrusted components
        self.shared_memory = [0] * 1024  # Shared memory is directly accessible

class TrustedComponent:
    def __init__(self, soc):
        self.soc = soc

    def write_data(self, data):
        # Trusted component writing data to shared memory
        self.soc.shared_memory[0:len(data)] = data  # Data written without access control

class UntrustedComponent:
    def __init__(self, soc):
        self.soc = soc

    def read_data(self):
        # Untrusted component accessing shared memory without restrictions
        return self.soc.shared_memory  # Unrestricted access to shared memory

# Example of usage
soc = SoC()
trusted = TrustedComponent(soc)
untrusted = UntrustedComponent(soc)

trusted.write_data([1, 2, 3, 4])
print(untrusted.read_data())  # Exposes trusted data to untrusted component

In this vulnerable example, both trusted and untrusted components have unrestricted access to shared_memory. This lack of isolation allows untrusted components to read sensitive data written by trusted components, posing a security risk.

How to fix Improper Isolation of Shared Resources on System-on-a-Chip (SoC)?

To address this vulnerability, the shared resources between trusted and untrusted components should be properly isolated. Implement access control mechanisms to enforce strict permissions on who can read or write to these resources. Here are some best practices:

1. Access Control: Implement access control lists (ACLs) or role-based access control (RBAC) to manage permissions for different components.
2. Memory Protection: Use memory protection units (MPUs) or similar hardware features to prevent untrusted components from accessing sensitive areas of memory.
3. Encapsulation: Encapsulate shared resources and expose them through controlled interfaces, ensuring that only authorized components have access.

Fixed Code Example

# Fixed code with proper isolation of shared resources
class SoC:
    def __init__(self):
        # Privately encapsulated shared resource
        self._trusted_memory = [0] * 1024  # Encapsulated memory to prevent direct access

    def write_trusted_data(self, data):
        # Controlled write interface for trusted components
        if len(data) <= len(self._trusted_memory):
            self._trusted_memory[0:len(data)] = data  # Write operation with boundary check

    def read_trusted_data(self):
        # Controlled read interface for trusted components
        return self._trusted_memory  # Only trusted components can access

class TrustedComponent:
    def __init__(self, soc):
        self.soc = soc

    def write_data(self, data):
        # Trusted component using controlled interface
        self.soc.write_trusted_data(data)

class UntrustedComponent:
    def __init__(self, soc):
        self.soc = soc

    def get_limited_data(self):
        # Untrusted component cannot access trusted memory directly
        # Only provide access to non-sensitive data or limited API
        return "Access Denied"  # Prevents unauthorized access to sensitive data

# Example of usage
soc = SoC()
trusted = TrustedComponent(soc)
untrusted = UntrustedComponent(soc)

trusted.write_data([1, 2, 3, 4])
print(untrusted.get_limited_data())  # Does not expose trusted data

In the fixed code example, the shared memory is encapsulated within the SoC class and accessed through controlled methods. This ensures that only authorized components can manipulate or read it. Untrusted components are denied access to sensitive data, effectively isolating shared resources and preventing security breaches. The interface also includes checks to prevent buffer overflows, further enhancing security.