COMMON WEAKNESS ENUMERATIONIncomplete

CWE-1220

Insufficient Granularity of Access Control

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.

Abstraction

Base

Structure

Simple

Likelihood of Exploit

Medium

Understand the problem

What is the problem?

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.

Extended description

Integrated circuits and hardware engines can expose accesses to assets (device configuration, keys, etc.) to trusted firmware or a software module (commonly set by BIOS/bootloader). This access is typically access-controlled. Upon a power reset, the hardware or system usually starts with default values in registers, and the trusted firmware (Boot firmware) configures the necessary access-control protection. A common weakness that can exist in such protection schemes is that access controls or policies are not granular enough. This condition allows agents beyond trusted agents to access assets and could lead to a loss of functionality or the ability to set up the device securely. This further results in security risks from leaked, sensitive, key material to modification of device configuration.

Root cause

How and when does the problem arise?

Lifecycle phase

Architecture and Design

Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.

Lifecycle phase

Implementation

Such issues could be introduced during hardware implementation and identified later during Testing or System Configuration phases.

Risk

What does successful exploitation lead to?

Modify MemoryRead MemoryExecute Unauthorized Code or CommandsGain Privileges or Assume IdentityBypass Protection MechanismOther

Affected security scopes: Confidentiality, Integrity, Availability, Access Control

Defence

How is it prevented and fixed?

Architecture and Design · Implementation · Testing

Defence to apply across several lifecycle phases

Detail
- Access-control-policy protections must be reviewed for design inconsistency and common weaknesses. - Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.

Effectiveness: High