All posts by rocco

CWE-1357 – Reliance on Uncontrolled Component

Read Time:58 Second

Description

The product’s design or architecture is built from multiple separate components, but one or more components are not under complete control of the developer, such as a third-party software library or a physical component that is built by an original equipment manufacturer (OEM).

Modes of Introduction:

– Requirements

 

 

Related Weaknesses

CWE-710

 

Consequences

Other: Reduce Maintainability

 

Potential Mitigations

Phase: Architecture and Design, Implementation, Integration, Manufacturing

Description: 

Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], “An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.”

Phase: Operation, Patching and Maintenance

Description: 

Continue to monitor changes in each of the product’s components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, etc.

CVE References

  • CVE-2020-9054
    • Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are “end-of-support” and cannot be patched (CWE-1277). [REF-1097]

CWE-138 – Improper Neutralization of Special Elements

Read Time:2 Minute, 23 Second

Description

The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.

Most languages and protocols have their own special elements such as characters and reserved words. These special elements can carry control implications. If software does not prevent external control or influence over the inclusion of such special elements, the control flow of the program may be altered from what was intended. For example, both Unix and Windows interpret the symbol < ("less than") as meaning "read input from a file". Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-707

 

Consequences

Confidentiality, Integrity, Availability, Other: Execute Unauthorized Code or Commands, Alter Execution Logic, DoS: Crash, Exit, or Restart

 

Potential Mitigations

Phase: Implementation

Description: 

Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their software system. One defense is to create an allowlist (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the allowlist. Properly encode your output, and quote any elements that have special meaning to the component with which you are communicating.

Phase: Implementation

Description: 

Phase: Implementation

Description: 

Use and specify an appropriate output encoding to ensure that the special elements are well-defined. A normal byte sequence in one encoding could be a special element in another.

Phase: Implementation

Description: 

Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

Phase: Implementation

Description: 

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

CVE References

  • CVE-2001-0677
    • Read arbitrary files from mail client by providing a special MIME header that is internally used to store pathnames for attachments.
  • CVE-2000-0703
    • Setuid program does not cleanse special escape sequence before sending data to a mail program, causing the mail program to process those sequences.
  • CVE-2003-0020
    • Multi-channel issue. Terminal escape sequences not filtered from log files.
  • CVE-2003-0083
    • Multi-channel issue. Terminal escape sequences not filtered from log files.

CWE-1384 – Improper Handling of Extreme Physical Environment Conditions

Read Time:46 Second

Description

The product does not properly detect and handle extreme conditions in the product’s physical environment, such as temperature, radiation, humidity, power, or other physical phenomena.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-703

 

Consequences

Confidentiality, Integrity, Availability: 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

Description: 

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

Phase: Architecture and Design, Implementation

Description: 

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

Phase: Architecture and Design, Implementation

Description: 

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.

CVE References

CWE-1304 – Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation

Read Time:1 Minute, 29 Second

Description

The product performs a power save/restore
operation, but it does not ensure that the integrity of
the configuration state is maintained and/or verified between
the beginning and ending of the operation.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284
CWE-345
CWE-1271

 

Consequences

Confidentiality, Integrity: DoS: Instability, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (Other), Gain Privileges or Assume Identity, Bypass Protection Mechanism, Alter Execution Logic, Quality Degradation, Unexpected State, Reduce Maintainability, Reduce Performance, Reduce Reliability

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Inside the IP, incorporate integrity checking
on the configuration state via a cryptographic
hash. The hash can be protected inside the IP such as
by storing it in internal registers which never lose
power. Before powering down, the IP performs a hash of
the configuration and saves it in these persistent
registers. Upon restore, the IP performs a hash of the
saved configuration and compares it with the
saved hash. If they do not match, then the IP should
not trust the configuration.

Phase: Integration

Description: 

Outside the IP, incorporate integrity checking
of the configuration state via a trusted agent. Before
powering down, the trusted agent performs a hash of the
configuration and saves the hash in persistent storage.
Upon restore, the IP requests the trusted agent
validate its current configuration. If the
configuration hash is invalid, then the IP should not
trust the configuration.

Phase: Integration

Description: 

Outside the IP, incorporate a protected
environment that prevents undetected modification of
the configuration state by untrusted agents. Before
powering down, a trusted agent saves the IP’s
configuration state in this protected location that
only it is privileged to. Upon restore, the trusted
agent loads the saved state into the IP.

CVE References

CWE-131 – Incorrect Calculation of Buffer Size

Read Time:5 Minute, 12 Second

Description

The software does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-682
CWE-682
CWE-682
CWE-682
CWE-119

 

Consequences

Integrity, Availability, Confidentiality: DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands, Read Memory, Modify Memory

If the incorrect calculation is used in the context of memory allocation, then the software may create a buffer that is smaller or larger than expected. If the allocated buffer is smaller than expected, this could lead to an out-of-bounds read or write (CWE-119), possibly causing a crash, allowing arbitrary code execution, or exposing sensitive data.

 

Potential Mitigations

Phase: Implementation

Description: 

When allocating a buffer for the purpose of transforming, converting, or encoding an input, allocate enough memory to handle the largest possible encoding. For example, in a routine that converts “&” characters to “&” for HTML entity encoding, the output buffer needs to be at least 5 times as large as the input buffer.

Phase: Implementation

Description: 

Phase: Implementation

Description: 

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Phase: Architecture and Design

Description: 

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Implementation

Description: 

When processing structured incoming data containing a size field followed by raw data, identify and resolve any inconsistencies between the size field and the actual size of the data (CWE-130).

Phase: Implementation

Description: 

When allocating memory that uses sentinels to mark the end of a data structure – such as NUL bytes in strings – make sure you also include the sentinel in your calculation of the total amount of memory that must be allocated.

Phase: Implementation

Effectiveness: Moderate

Description: 

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131). Additionally, this only addresses potential overflow issues. Resource consumption / exhaustion issues are still possible.

Phase: Implementation

Description: 

Use sizeof() on the appropriate data type to avoid CWE-467.

Phase: Implementation

Description: 

Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity. This will simplify validation and will reduce surprises related to unexpected casting.

Phase: Architecture and Design

Description: 

Phase: Build and Compilation

Effectiveness: Defense in Depth

Description: 

This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Effectiveness: Defense in Depth

Description: 

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Effectiveness: Defense in Depth

Description: 

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-61] [REF-60].

This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software’s state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

Description: 

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

Phase: Architecture and Design, Operation

Description: 

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design, Operation

Effectiveness: Limited

Description: 

The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

CVE References

  • CVE-2004-1363
    • substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed
  • CVE-2004-0747
    • substitution overflow: buffer overflow using expansion of environment variables
  • CVE-2005-2103
    • substitution overflow: buffer overflow using a large number of substitution strings
  • CVE-2005-3120
    • transformation overflow: product adds extra escape characters to incoming data, but does not account for them in the buffer length
  • CVE-2003-0899
    • transformation overflow: buffer overflow when expanding “>” to “>”, etc.
  • CVE-2001-0334
    • expansion overflow: buffer overflow using wildcards
  • CVE-2001-0248
    • expansion overflow: long pathname + glob = overflow
  • CVE-2001-0249
    • expansion overflow: long pathname + glob = overflow
  • CVE-2002-0184
    • special characters in argument are not properly expanded
  • CVE-2005-0490
    • needs closer investigation, but probably expansion-based
  • CVE-2004-0940
    • needs closer investigation, but probably expansion-based
  • CVE-2008-0599
    • Chain: Language interpreter calculates wrong buffer size (CWE-131) by using “size = ptr ? X : Y” instead of “size = (ptr ? X : Y)” expression.

CWE-1310 – Missing Ability to Patch ROM Code

Read Time:57 Second

Description

Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-1329

 

Consequences

Other: Varies by Context, Reduce Maintainability

When the system is unable to be patched, it can be left in a vulnerable state.

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Effectiveness: Moderate

Description: 

Secure patch support to allow ROM code to be patched on the next boot.

Some parts of the hardware initialization or signature verification done to authenticate patches will always be “not patchable.”

Phase: Architecture and Design, Implementation

Effectiveness: Moderate

Description: 

Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.

Patches that use hardware fuses will have limitations in terms of size and the number of patches that can be supported. Note that some parts of the hardware initialization or signature verification done to authenticate patches will always be “not patchable.”

CVE References

CWE-1311 – Improper Translation of Security Attributes by Fabric Bridge

Read Time:34 Second

Description

The bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284

 

Consequences

Confidentiality, Integrity, Access Control: Modify Memory, Read Memory, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Execute Unauthorized Code or Commands

 

Potential Mitigations

Phase: Architecture and Design

Description: 

The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.

Phase: Implementation

Description: 

Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.

CVE References

CWE-1312 – Missing Protection for Mirrored Regions in On-Chip Fabric Firewall

Read Time:30 Second

Description

The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284
CWE-1251

 

Consequences

Confidentiality, Integrity, Access Control: Modify Memory, Read Memory, Bypass Protection Mechanism

 

Potential Mitigations

Phase: Architecture and Design

Description: 

The fabric firewall should apply the same protections as the original region to the mirrored regions.

Phase: Implementation

Description: 

The fabric firewall should apply the same protections as the original region to the mirrored regions.

CVE References

CWE-1313 – Hardware Allows Activation of Test or Debug Logic at Runtime

Read Time:1 Minute, 42 Second

Description

During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284

 

Consequences

Confidentiality, Integrity, Availability: Modify Memory, Read Memory, DoS: Crash, Exit, or Restart, DoS: Instability, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other), Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Alter Execution Logic, Quality Degradation, Unexpected State, Reduce Performance, Reduce Reliability

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Insert restrictions on when the hardware’s test or debug features can be activated. For example, during normal operating modes, the hardware’s privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.

Phase: Implementation

Description: 

Insert restrictions on when the hardware’s test or debug features can be activated. For example, during normal operating modes, the hardware’s privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.

Phase: Integration

Description: 

Insert restrictions on when the hardware’s test or debug features can be activated. For example, during normal operating modes, the hardware’s privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.

CVE References

CWE-1314 – Missing Write Protection for Parametric Data Values

Read Time:50 Second

Description

The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-862
CWE-1299

 

Consequences

Availability: Quality Degradation, DoS: Resource Consumption (Other)

Sensor value manipulation, particularly thermal or power, may allow physical damage to occur or disabling of the device by a false fault shutdown causing a Denial-Of-Service.

 

Potential Mitigations

Phase: Architecture and Design

Effectiveness: High

Description: 

Access controls for sensor blocks should ensure that only trusted software is allowed to change threshold limits and sensor parametric data.

CVE References

  • CVE-2017-8252
    • Kernel can inject faults in computations during the execution of TrustZone leading to information disclosure in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice and Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking.