Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

New to CWE? click here!
2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.11)  

CWE-1262: Improper Access Control for Register Interface

Weakness ID: 1262
Abstraction: Base
Structure: Simple
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Edit Custom Filter

+ Description
The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
+ Extended Description

Software commonly accesses peripherals in a System-on-Chip (SoC) or other device through a memory-mapped register interface. Malicious software could tamper with any security-critical hardware data that is accessible directly or indirectly through the register interface, which could lead to a loss of confidentiality and integrity.

+ 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)
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
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)
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.
Architecture and DesignThis weakness may be exploited if the register interface design does not adequately protect hardware assets from software.
ImplementationMis-implementation of access control policies may inadvertently allow access to hardware assets through the register interface.
+ 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.


Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)


Class: Not Architecture-Specific (Undetermined Prevalence)


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.

Technical Impact: Read Memory; Read Application Data; Modify Memory; Modify Application Data; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Unexpected State; Alter Execution Logic

Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.
+ Demonstrative Examples

Example 1

The register interface provides software access to hardware functionality. This functionality is an attack surface. This attack surface may be used to run untrusted code on the system through the register interface. As an example, cryptographic accelerators require a mechanism for software to select modes of operation and to provide plaintext or ciphertext data to be encrypted or decrypted as well as other functions. This functionality is commonly provided through registers.

(bad code)
Cryptographic key material stored in registers inside the cryptographic accelerator can be accessed by software.
(good code)
Key material stored in registers should never be accessible to software. Even if software can provide a key, all read-back paths to software should be disabled.
+ Observed Examples
virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.
Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.
+ Potential Mitigations

Phase: Architecture and Design

Design proper policies for hardware register access from software.

Phase: Implementation

Ensure that access control policies for register access are implemented in accordance with the specified design.
+ Weakness Ordinalities
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.

Effectiveness: Moderate

Manual Analysis

Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.

Effectiveness: Moderate

Simulation / Emulation

Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.

Effectiveness: Moderate

Formal Verification

Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.

Effectiveness: High

Automated Analysis

Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.

Effectiveness: High

Architecture or Design Review

Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.

Effectiveness: Moderate


Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.

Effectiveness: Moderate

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-08Nicole FernTortuga Logic
+ Contributions
Contribution DateContributorOrganization
2021-10-11Anders Nordstrom, Alric AlthoffTortuga Logic
Provided detection methods and observed examples
2021-10-12Nicole FernRiscure
Provided detection methods
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Register Interface Allows Software Access to Sensitive Data or Security Settings
Page Last Updated: April 27, 2023