CWE

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

CWE

CWE-1224 – Improper Restriction of Write-Once Bit Fields

Read Time:32 Second

Description

The hardware design control register “sticky bits” or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284

 

Consequences

Confidentiality, Integrity, Availability, Access Control: Varies by Context

System configuration cannot be programmed in a secure way.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

During hardware design all register write-once or sticky fields must be evaluated for proper configuration.

Phase: Testing

Description: 

The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.

CVE References

CWE

CWE-1223 – Race Condition for Write-Once Attributes

Read Time:32 Second

Description

A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-362

 

Consequences

Access Control: Bypass Protection Mechanism

System configuration cannot be programmed in a secure way.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

During hardware design all register write-once or sticky fields must be evaluated for proper configuration.

Phase: Testing

Description: 

The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.

CVE References

CWE

CWE-1222 – Insufficient Granularity of Address Regions Protected by Register Locks

Read Time:30 Second

Description

The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-1220

 

Consequences

Access Control: Other

System security configuration cannot be defined in a way that does not conflict with functional requirements of device.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

CVE References

CWE

CWE-1221 – Incorrect Register Defaults or Module Parameters

Read Time:35 Second

Description

Hardware description language code incorrectly defines register defaults or hardware IP parameters to insecure values.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-665

 

Consequences

Confidentiality, Integrity, Availability, Access Control: Varies by Context

Degradation of system functionality, or loss of access control enforcement can occur.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

During hardware design, all the system parameters and register defaults must be reviewed to identify security sensitive settings.

Phase: Implementation

Description: 

The default values of these security sensitive settings need to be defined as part of the design review phase.

Phase: Testing

Description: 

Testing phase should use automated tools to test that values are configured per design specifications.

CVE References

CWE

CWE-1220 – Insufficient Granularity of Access Control

Read Time:33 Second

Description

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-284

 

Consequences

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

 

Potential Mitigations

Phase: Architecture and Design, Implementation, Testing

Effectiveness: High

Description: 

CVE References

CWE

CWE-122 – Heap-based Buffer Overflow

Read Time:2 Minute, 13 Second

Description

A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-788
CWE-787

 

Consequences

Availability: DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Integrity, Confidentiality, Availability, Access Control: Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Modify Memory

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker’s code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.

Integrity, Confidentiality, Availability, Access Control, Other: Execute Unauthorized Code or Commands, 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:

Description: 

Pre-design: Use a language or compiler that performs automatic bounds checking.

Phase: Architecture and Design

Description: 

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Build and Compilation

Description: 

Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible, but should not be relied upon.

Phase: Implementation

Description: 

Implement and perform bounds checking on input.

Phase: Implementation

Description: 

Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.

Phase: Operation

Description: 

Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.

CVE References

  • CVE-2007-4268
    • Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
  • CVE-2009-2523
    • Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
  • CVE-2021-29529
    • Chain: machine-learning product can have a heap-based
      buffer overflow (CWE-122) when some integer-oriented bounds are
      calculated by using ceiling() and floor() on floating point values
      (CWE-1339)
CWE

CWE-121 – Stack-based Buffer Overflow

Read Time:2 Minute, 24 Second

Description

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which they place arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a “write-what-where” condition.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-788
CWE-787

 

Consequences

Availability: Modify Memory, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Integrity, Confidentiality, Availability, Access Control: Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy.

Integrity, Confidentiality, Availability, Access Control, Other: Modify Memory, Execute Unauthorized Code or Commands, 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: 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: Architecture and Design

Description: 

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Build and Compilation

Description: 

Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.

Phase: Implementation

Description: 

Implement and perform bounds checking on input.

Phase: Implementation

Description: 

Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.

Phase: Operation

Description: 

Use OS-level preventative functionality, such as ASLR. This is not a complete solution.

CVE References

CWE

CWE-1209 – Failure to Disable Reserved Bits

Read Time:38 Second

Description

The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-710

 

Consequences

Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation: Varies by Context

This type of weakness all depends on the capabilities of the logic being controlled or configured by the reserved bits

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Description: 

Phase: Integration

Description: 

CVE References

News, Advisories and much more

Exit mobile version