CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.10)  
ID

CWE-1220: Insufficient Granularity of Access Control

Weakness ID: 1220
Abstraction: Base
Structure: Simple
View customized information:
+ Description
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.

+ Relationships
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.1222Insufficient Granularity of Address Regions Protected by Register Locks
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during hardware implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Modify Memory; Read Memory; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Other

High
+ Demonstrative Examples

Example 1

Consider a system with a register for storing AES key for encryption or decryption. The key is 128 bits, implemented as a set of four 32-bit registers. The key registers are assets and registers, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary access controls.

The read-policy register defines which agents can read the AES-key registers, and write-policy register defines which agents can program or write to those registers. Each register is a 32-bit register, and it can support access control for a maximum of 32 agents. The number of the bit when set (i.e., "1") allows respective action from an agent whose identity matches the number of the bit and, if "0" (i.e., Clear), disallows the respective action to that corresponding agent.

(bad code)
Example Language: Other 
Register Field description
AES_ENC_DEC_KEY_0 AES key [0:31] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_1 AES key [32:63] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_2 AES key [64:95] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_4 AES key [96:127] for encryption or decryption
Default 0x00000000
AES_KEY_READ_WRITE_POLICY [31:0] Default 0x00000006 - meaning agent with identities "1" and "2" can both read from and write to key registers

In the above example, there is only one policy register that controls access to both read and write accesses to the AES-key registers, and thus the design is not granular enough to separate read and writes access for different agents. Here, agent with identities "1" and "2" can both read and write.

A good design should be granular enough to provide separate access controls to separate actions. Access control for reads should be separate from writes. Below is an example of such implementation where two policy registers are defined for each of these actions. The policy is defined such that: the AES-key registers can only be read or used by a crypto agent with identity "1" when bit #1 is set. The AES-key registers can only be programmed by a trusted firmware with identity "2" when bit #2 is set.

(mitigation)
 
AES_KEY_READ_POLICY [31:0] Default 0x00000002 - meaning only Crypto engine with identity "1" can read registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3
AES_KEY_WRITE_POLICY [31:0] Default 0x00000004 - meaning only trusted firmware with identity "2" can program registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3

Example 2

Consider the following SoC design. The sram in HRoT has an address range that is readable and writable by unprivileged software and it has an area that is only readable by unprivileged software. The tbus interconnect enforces access control for slaves on the bus but uses only one bit to control both read and write access. Address 0xA0000000 - 0xA000FFFF is readable and writable by the untrusted cores core{0-N} and address 0xA0010000 - 0xA001FFFF is only readable by the untrusted cores core{0-N}.

Hardware Root of Trust

The security policy access control is not granular enough, as it uses one bit to enable both read and write access. This gives write access to an area that should only be readable by unprivileged agents.

Access control logic should differentiate between read and write access and to have sufficient address granularity.

+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • 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

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-05Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-07-16Tortuga Logic
Provided Demonstrative Example for Hardware Root of Trust
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
More information is available — Please select a different filter.
Page Last Updated: January 31, 2023