CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (4.1)  
ID

CWE-1262: Register Interface Allows Software Access to Sensitive Data or Security Settings

Weakness ID: 1262
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Memory-mapped registers provide access to hardware functionality from software and if not properly secured can result in loss of confidentiality and integrity.
+ Extended Description

It is common for software to access peripherals in an SoC through a memory-mapped register interface. Any security-critical data accessible directly or indirectly through the register interface must have a clearly defined access control policy which is correctly implemented to protect assets in the hardware design from software.

+ Relationships

The table(s) below 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
+ 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

The 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 DesignThis weakness can manifest if the register interface design does not adequately protect hardware assets from software.
ImplementationImplementation of access control policies may not match and allow access to hardware assets through the register interface.
+ Applicable Platforms
The listings below show 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: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

The table below 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

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 violated if the information can be read out by software through the register interface.

Registers storing security state, settings, other security-critical data can be corruptible by software if protections are not in place.

+ Demonstrative Examples

Example 1

The register interface provides software access to hardware functionality but can also be viewed as an attack surface if untrusted code can execute in the system. As an example, cryptographic accelerators require a mechanism for software to select modes of operation, provide plaintext or ciphertext data to be encrypted/decrypted etc. 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.
+ Potential Mitigations

Phase: Architecture and Design

Design proper policies for how and if hardware registers can be accessed by software.

Phase: Implementation

Ensure access control policies for software in relation to hardware are implemented in accordance with intended design.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-08Nicole FernTortuga Logic
More information is available — Please select a different filter.
Page Last Updated: June 25, 2020