CWE-1239 – Improper Zeroization of Hardware Register

Read Time:1 Minute, 41 Second

Description

The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.

Hardware logic operates on data stored in registers local to the hardware block. Most hardware IPs, including cryptographic accelerators, rely on registers to buffer I/O, store intermediate values, and interface with software. The result of this is that sensitive information, such as passwords or encryption keys, can exist in locations not transparent to the user of the hardware logic. When a different entity obtains access to the IP due to a change in operating mode or conditions, the new entity can extract information belonging to the previous user if no mechanisms are in place to clear register contents. It is important to clear information stored in the hardware if a physical attack on the product is detected, or if the user of the hardware block changes. The process of clearing register contents in a hardware IP is referred to as zeroization in standards for cryptographic hardware modules such as FIPS-140-2 [REF-267].

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-226
CWE-226

 

Consequences

Confidentiality: Varies by Context

The consequences will depend on the information disclosed due to the vulnerability.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Every register potentially containing sensitive information must have a policy specifying how and when information is cleared, in addition to clarifying if it is the responsibility of the hardware logic or IP user to initiate the zeroization procedure at the appropriate time.

Unfortunately, data disclosure can occur even after information has been overwritten/zeroized from the digital perspective. Physical characteristics of the memory can reveal the history of previously written data. For example, if the same value is written repeatedly to a memory location, the corresponding memory cells can become physically altered to a degree that even if the original data is erased it can still be recovered through physical characterization of the memory cells [REF-1055].

CVE References

CWE-1236 – Improper Neutralization of Formula Elements in a CSV File

Read Time:1 Minute, 51 Second

Description

The software saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by spreadsheet software.

User-provided data is often saved to traditional databases. This data can be exported to a CSV file, which allows users to read the data using spreadsheet software such as Excel, Numbers, or Calc. This software interprets entries beginning with ‘=’ as formulas, which are then executed by the spreadsheet software. The software’s formula language often allows methods to access hyperlinks or the local command line, and frequently allows enough characters to invoke an entire script. Attackers can populate data fields which, when saved to a CSV file, may attempt information exfiltration or other malicious activity when automatically executed by the spreadsheet software.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-74
CWE-74

 

Consequences

Confidentiality: Read Application Data, Execute Unauthorized Code or Commands

Current versions of Excel warn users of untrusted content.

 

Potential Mitigations

Phase: Implementation

Effectiveness: Moderate

Description: 

When generating CSV output, ensure that formula-sensitive metacharacters are effectively escaped or removed from all data before storage in the resultant CSV. Risky characters include ‘=’ (equal), ‘+’ (plus), ‘-‘ (minus), and ‘@’ (at).

Unfortunately, there is no perfect solution, since different spreadsheet products act differently.

Phase: Implementation

Effectiveness: Moderate

Description: 

If a field starts with a formula character, prepend it with a ‘ (single apostrophe), which prevents Excel from executing the formula.

It is not clear how effective this mitigation is with other spreadsheet software.

Phase: Architecture and Design

Effectiveness: Limited

Description: 

Certain implementations of spreadsheet software might disallow formulas from executing if the file is untrusted, or if the file is not authored by the current user.

This mitigation has limited effectiveness because it often depends on end users opening spreadsheet software safely.

CVE References

  • CVE-2019-12134
    • Low privileged user can trigger CSV injection through a contact form field value
  • CVE-2019-4521
    • Cloud management product allows arbitrary command execution via CSV injection
  • CVE-2019-17661
    • CSV injection in content management system via formula code in a first or last name

CWE-1235 – Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations

Read Time:31 Second

Description

The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-400

 

Consequences

Availability: DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other), Reduce Performance

Incorrect autoboxing/unboxing would result in reduced performance, which sometimes can lead to resource consumption issues.

 

Potential Mitigations

Phase: Implementation

Description: 

Use of boxed primitives should be limited to certain situations such as when calling methods with typed parameters. Examine the use of boxed primitives prior to use. Use SparseArrays or ArrayMap instead of HashMap to avoid performance overhead.

CVE References

CWE-1234 – Hardware Internal or Debug Modes Allow Override of Locks

Read Time:18 Second

Description

System configuration protection may be bypassed during debug mode.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-667

 

Consequences

Access Control: Bypass Protection Mechanism

Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.

 

Potential Mitigations

Phase: Architecture and Design, Implementation, Testing

Effectiveness: High

Description: 

CVE References

CWE-1233 – Security-Sensitive Hardware Controls with Missing Lock Bit Protection

Read Time:47 Second

Description

The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284
CWE-667

 

Consequences

Access Control: Modify Memory

System Configuration protected by the lock bit can be modified even when the lock is set.

 

Potential Mitigations

Phase: Architecture and Design, Implementation, Testing

Description: 

CVE References

  • CVE-2018-9085
    • Certain servers leave a write protection lock bit
      unset after boot, potentially allowing modification of
      parts of flash memory.
  • CVE-2014-8273
    • Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].

CWE-1232 – Improper Lock Behavior After Power State Transition

Read Time:23 Second

Description

Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-667

 

Consequences

Access Control: Modify Memory

 

Potential Mitigations

Phase: Architecture and Design, Implementation, Testing

Effectiveness: High

Description: 

CVE References

CWE-1231 – Improper Prevention of Lock Bit Modification

Read Time:29 Second

Description

The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284

 

Consequences

Access Control: Modify Memory

Registers protected by lock bit can be modified even when lock is set.

 

Potential Mitigations

Phase: Architecture and Design, Implementation, Testing

Effectiveness: High

Description: 

CVE References

  • CVE-2017-6283
    • chip reset clears critical read/write lock permissions for RSA function

CWE-123 – Write-what-where Condition

Read Time:1 Minute, 26 Second

Description

Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-787
CWE-119
CWE-119

 

Consequences

Integrity, Confidentiality, Availability, Access Control: Modify Memory, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, DoS: Crash, Exit, or Restart, Bypass Protection Mechanism

Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy. If the attacker can overwrite a pointer’s worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data — such as a flag indicating whether the user is an administrator.

Integrity, Availability: DoS: Crash, Exit, or Restart, Modify Memory

Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process.

Access Control, Other: Bypass Protection Mechanism, Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use a language that provides appropriate memory abstractions.

Phase: Operation

Description: 

Use OS-level preventative functionality integrated after the fact. Not a complete solution.

CVE References