All posts by rocco

CWE-12 – ASP.NET Misconfiguration: Missing Custom Error Page

Read Time:50 Second

Description

An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework’s built-in responses.

The mode attribute of the tag defines whether custom or default error pages are used.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-756

 

Consequences

Confidentiality: Read Application Data

Default error pages gives detailed information about the error that occurred, and should not be used in production environments. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.

 

Potential Mitigations

Phase: System Configuration

Description: 

Handle exceptions appropriately in source code. ASP .NET applications should be configured to use custom error pages instead of the framework default page.

Phase: Architecture and Design

Description: 

Do not attempt to process an error or attempt to mask it.

Phase: Implementation

Description: 

Verify return values are correct and do not supply sensitive information about the system.

CVE References

CWE-120 – Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

Read Time:4 Minute, 16 Second

Description

The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.

A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold, or when a program attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the “classic” case in which the program copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-119
CWE-119
CWE-119
CWE-119
CWE-123
CWE-20

 

Consequences

Integrity, Confidentiality, Availability: Modify Memory, Execute Unauthorized Code or Commands

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

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

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

 

Potential Mitigations

Phase: Requirements

Description: 

Phase: Architecture and Design

Description: 

This is not a complete solution, since many buffer overflows are not related to strings.

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: Implementation

Description: 

Phase: Implementation

Description: 

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: 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-60] [REF-61].

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: Build and Compilation, Operation

Description: 

Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.

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).

Phase: Architecture and Design

Description: 

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

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-1999-0046
    • buffer overflow in local program using long environment variable
  • CVE-2002-1337
    • buffer overflow in comment characters, when product increments a counter for a “>” but does not decrement for “
  • CVE-2003-0595
    • By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application’s buffers.
  • CVE-2001-0191
    • By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application’s buffers.

CWE-1204 – Generation of Weak Initialization Vector (IV)

Read Time:2 Minute, 0 Second

Description

The product uses a cryptographic primitive that uses an Initialization
Vector (IV), but the product does not generate IVs that are
sufficiently unpredictable or unique according to the expected
cryptographic requirements for that primitive.

By design, some cryptographic primitives
(such as block ciphers) require that IVs
must have certain properties for the
uniqueness and/or unpredictability of an
IV. Primitives may vary in how important
these properties are. If these properties
are not maintained, e.g. by a bug in the
code, then the cryptography may be weakened
or broken by attacking the IVs themselves.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-330

 

Consequences

Confidentiality: Read Application Data

If the IV is not properly initialized, data that is encrypted can be compromised and information about the data can be leaked. See [REF-1179].

 

Potential Mitigations

Phase: Implementation

Description: 

CVE References

  • CVE-2020-1472
    • ZeroLogon vulnerability – use of a static IV of all zeroes in AES-CFB8 mode
  • CVE-2011-3389
    • BEAST attack in SSL 3.0 / TLS 1.0. In CBC mode, chained initialization vectors are non-random, allowing decryption of HTTPS traffic using a chosen plaintext attack.
  • CVE-2001-0161
    • wireless router does not use 6 of the 24 bits for WEP encryption, making it easier for attackers to decrypt traffic
  • CVE-2001-0160
    • WEP card generates predictable IV values, making it easier for attackers to decrypt traffic
  • CVE-2017-3225
    • device bootloader uses a zero initialization vector during AES-CBC
  • CVE-2016-6485
    • crypto framework uses PHP rand function – which is not cryptographically secure – for an initialization vector
  • CVE-2014-5386
    • encryption routine does not seed the random number generator, causing the same initialization vector to be generated repeatedly
  • CVE-2020-5408
    • encryption functionality in an authentication framework uses a fixed null IV with CBC mode, allowing attackers to decrypt traffic in applications that use this functionality
  • CVE-2017-17704
    • messages for a door-unlocking product use a fixed IV in CBC mode, which is the same after each restart
  • CVE-2017-11133
    • application uses AES in CBC mode, but the pseudo-random secret and IV are generated using math.random, which is not cryptographically strong.
  • CVE-2007-3528
    • Blowfish-CBC implementation constructs an IV where each byte is calculated modulo 8 instead of modulo 256, resulting in less than 12 bits for the effective IV length, and less than 4096 possible IV values.

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

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-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-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-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-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-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