CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

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

CWE-1384: Improper Handling of Physical or Environmental Conditions

Weakness ID: 1384
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
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 does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.
+ Extended Description

Hardware products are typically only guaranteed to behave correctly within certain physical limits or environmental conditions. Such products cannot necessarily control the physical or external conditions to which they are subjected. However, the inability to handle such conditions can undermine a product's security. For example, an unexpected physical or environmental condition may cause the flipping of a bit that is used for an authentication decision. This unexpected condition could occur naturally or be induced artificially by an adversary.

Physical or environmental conditions of concern are:

  • Atmospheric characteristics: extreme temperature ranges, etc.
  • Interference: electromagnetic interference (EMI), radio frequency interference (RFI), etc.
  • Assorted light sources: white light, ultra-violet light (UV), lasers, infrared (IR), etc.
  • Power variances: under-voltages, over-voltages, under-current, over-current, etc.
  • Clock variances: glitching, overclocking, clock stretching, etc.
  • Component aging and degradation
  • Materials manipulation: focused ion beams (FIB), etc.
  • Exposure to radiation: x-rays, cosmic radiation, etc.
+ 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

Technical Impact: Varies by Context; Unexpected State

Consequences of this weakness are highly dependent on the role of affected components within the larger product.
+ Potential Mitigations

Phase: Requirements

In requirements, be specific about expectations for how the product will perform when it exceeds physical and environmental boundary conditions, e.g., by shutting down.

Phases: Architecture and Design; Implementation

Where possible, include independent components that can detect excess environmental conditions and have the capability to shut down the product.

Phases: Architecture and Design; Implementation

Where possible, use shielding or other materials that can increase the adversary's workload and reduce the likelihood of being able to successfully trigger a security-related failure.
+ 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.703Improper Check or Handling of Exceptional Conditions
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1247Improper Protection Against Voltage and Clock Glitches
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1261Improper Handling of Single Event Upsets
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1332Improper Handling of Faults that Lead to Instruction Skips
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1351Improper Handling of Hardware Behavior in Exceptionally Cold Environments
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.1388Physical Access Issues and Concerns
+ 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 DesignThe product's design might not consider checking and handling extreme conditions.
ManufacturingFor hardware manufacturing, sub-par components might be chosen that are not able to handle the expected environmental conditions.
+ 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.

Technologies

Class: System on Chip (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ Observed Examples
ReferenceDescription
Lack of anti-glitch protections allows an attacker to launch a physical attack to bypass the secure boot and read protected eFuses.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1367ICS Dependencies (& Architecture): External Physical Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ References
[REF-1248] Securing Energy Infrastructure Executive Task Force (SEI ETF). "Categories of Security Vulnerabilities in ICS". ICS Communications / 2. Unreliability. 2022-03-09. <https://inl.gov/wp-content/uploads/2022/03/SEI-ETF-NCSV-TPT-Categories-of-Security-Vulnerabilities-ICS-v1_03-09-22.pdf>.
[REF-1255] Sergei P. Skorobogatov. "Semi-invasive attacks - A new approach to hardware security analysis". 2005-04. <https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf>.
[REF-1285] Texas Instruments. "Physical Security Attacks Against Silicon Devices". 2022-01-31. <https://www.ti.com/lit/an/swra739/swra739.pdf?ts=1644234570420>.
[REF-1286] Lennert Wouters, Benedikt Gierlichs and Bart Preneel. "On The Susceptibility of Texas Instruments SimpleLink Platform Microcontrollers to Non-Invasive Physical Attacks". 1.2. 2022-03-14. <https://eprint.iacr.org/2022/328.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2022-04-21
(CWE 4.7, 2022-04-28)
CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2022-05-13Members of the Hardware CWE Special Interest Group
Provided feedback on descriptions
+ Modifications
Modification DateModifierOrganization
2022-06-28CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationships, Type
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2022-06-28Improper Handling of Extreme Physical Environment Conditions
Page Last Updated: July 16, 2024