Monthly Archives: May 2022

CWE

CWE-768 – Incorrect Short Circuit Evaluation

Read Time:43 Second

Description

The software contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.

Modes of Introduction:

– Implementation

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-691

 

Consequences

Confidentiality, Integrity, Availability:

Widely varied consequences are possible if an attacker is aware of an unexpected state in the software after a conditional. It may lead to information exposure, a system crash, or even complete attacker control of the system.

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way.

CVE References

 

CWE

CWE-767 – Access to Critical Private Variable via Public Method

Read Time:39 Second

Description

The software defines a public method that reads or modifies a private variable.

If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.

Modes of Introduction:

– Architecture and Design

Likelihood of Exploit:

 

Related Weaknesses

CWE-668

 

Consequences

Integrity, Other: Modify Application Data, Other

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data.

CVE References

 

CWE

CWE-766 – Critical Data Element Declared Public

Read Time:38 Second

Description

The software declares a critical variable, field, or member to be public when intended security policy requires it to be private.

Modes of Introduction:

– Architecture and Design

Likelihood of Exploit:

 

Related Weaknesses

CWE-1061

 

Consequences

Integrity, Confidentiality: Read Application Data, Modify Application Data

Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.

Other: Reduce Maintainability

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.

CVE References

 

  • CVE-2010-3860
    • variables declared public allows remote read of system properties such as user name and home directory.
CWE

CWE-765 – Multiple Unlocks of a Critical Resource

Read Time:1 Minute, 5 Second

Description

The software unlocks a critical resource more times than intended, leading to an unexpected state in the system.

When software is operating in a concurrent environment and repeatedly unlocks a critical resource, the consequences will vary based on the type of lock, the lock’s implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra calls to unlock will increase the count for the number of available resources, likely resulting in a crash or unpredictable behavior when the system nears capacity.

Modes of Introduction:

– Implementation

Likelihood of Exploit:

 

Related Weaknesses

CWE-667
CWE-675

 

Consequences

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

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.

CVE References

 

  • CVE-2009-0935
    • Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
CWE

CWE-764 – Multiple Locks of a Critical Resource

Read Time:1 Minute, 15 Second

Description

The software locks a critical resource more times than intended, leading to an unexpected state in the system.

When software is operating in a concurrent environment and repeatedly locks a critical resource, the consequences will vary based on the type of lock, the lock’s implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra locking calls will reduce the size of the total available pool, possibly leading to degraded performance or a denial of service. If this can be triggered by an attacker, it will be similar to an unrestricted lock (CWE-412). In the context of a binary lock, it is likely that any duplicate locking attempts will never succeed since the lock is already held and progress may not be possible.

Modes of Introduction:

– Architecture and Design

Likelihood of Exploit:

 

Related Weaknesses

CWE-667
CWE-675
CWE-662
CWE-662

 

Consequences

Availability, Integrity: DoS: Resource Consumption (CPU), DoS: Crash, Exit, or Restart, Unexpected State

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.

CVE References

 

CWE

CWE-763 – Release of Invalid Pointer or Reference

Read Time:57 Second

Description

The application attempts to return a memory resource to the system, but calls the wrong release function or calls the appropriate release function incorrectly.

Modes of Introduction:

– Implementation

Likelihood of Exploit:

 

Related Weaknesses

CWE-404
CWE-404
CWE-404

 

Consequences

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

This weakness may result in the corruption of memory, and perhaps instructions, possibly leading to a crash. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code.

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().

Phase: Implementation

Effectiveness:

Description: 

When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.

Phase: Architecture and Design

Effectiveness:

Description: 

Phase: Architecture and Design

Effectiveness:

Description: 

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Effectiveness:

Description: 

Use a tool that dynamically detects memory management problems, such as valgrind.

CVE References

 

CWE

CWE-762 – Mismatched Memory Management Routines

Read Time:44 Second

Description

The application attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.

Modes of Introduction:

– Implementation

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-763
CWE-404

 

Consequences

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

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().

Phase: Implementation

Effectiveness:

Description: 

Phase: Architecture and Design

Effectiveness:

Description: 

Phase: Architecture and Design

Effectiveness:

Description: 

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Effectiveness:

Description: 

Use a tool that dynamically detects memory management problems, such as valgrind.

CVE References

 

CWE

CWE-761 – Free of Pointer not at Start of Buffer

Read Time:55 Second

Description

The application calls free() on a pointer to a memory resource that was allocated on the heap, but the pointer is not at the start of the buffer.

Modes of Introduction:

– Implementation

Likelihood of Exploit:

 

Related Weaknesses

CWE-763
CWE-404

 

Consequences

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

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

When utilizing pointer arithmetic to traverse a buffer, use a separate variable to track progress through memory and preserve the originally allocated address for later freeing.

Phase: Implementation

Effectiveness:

Description: 

When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.

Phase: Architecture and Design

Effectiveness:

Description: 

Phase: Architecture and Design

Effectiveness:

Description: 

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Effectiveness:

Description: 

Use a tool that dynamically detects memory management problems, such as valgrind.

CVE References

 

  • CVE-2019-11930
    • function “internally calls ‘calloc’ and returns a pointer at an index… inside the allocated buffer. This led to freeing invalid memory.”
CWE

CWE-760 – Use of a One-Way Hash with a Predictable Salt

Read Time:1 Minute, 31 Second

Description

The software uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the software uses a predictable salt as part of the input.

In cryptography, salt refers to some random addition of data to an input before hashing to make dictionary attacks more difficult.

Modes of Introduction:

– Implementation

Likelihood of Exploit:

 

Related Weaknesses

CWE-916

 

Consequences

Access Control: Bypass Protection Mechanism

 

Potential Mitigations

Phase: Architecture and Design

Effectiveness: High

Description: 

Phase: Implementation

Effectiveness: Limited

Description: 

If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also store the salt. Do not use the same salt for every password.

Be aware that salts will not reduce the workload of a targeted attack against an individual hash (such as the password for a critical person), and in general they are less effective than other hashing techniques such as increasing the computation time or memory overhead. Without a built-in workload, modern attacks can compute large numbers of hashes, or even exhaust the entire space of all possible passwords, within a very short amount of time, using massively-parallel computing and GPU, ASIC, or FPGA hardware.

CVE References

 

  • CVE-2008-4905
    • Blogging software uses a hard-coded salt when calculating a password hash.
  • CVE-2002-1657
    • Database server uses the username for a salt when encrypting passwords, simplifying brute force attacks.
  • CVE-2001-0967
    • Server uses a constant salt when encrypting passwords, simplifying brute force attacks.
  • CVE-2005-0408
    • chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.
CWE

CWE-76 – Improper Neutralization of Equivalent Special Elements

Read Time:54 Second

Description

The software properly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.

The software may have a fixed list of special characters it believes is complete. However, there may be alternate encodings, or representations that also have the same meaning. For example, the software may filter out a leading slash (/) to prevent absolute path names, but does not account for a tilde (~) followed by a user name, which on some *nix systems could be expanded to an absolute pathname. Alternately, the software might filter a dangerous “-e” command-line switch when calling an external program, but it might not account for “–exec” or other switches that have the same semantics.

Modes of Introduction:

– Architecture and Design

Likelihood of Exploit: High

 

Related Weaknesses

CWE-75

 

Consequences

Other: Other

 

Potential Mitigations

Phase: Requirements

Effectiveness:

Description: 

Programming languages and supporting technologies might be chosen which are not subject to these issues.

Phase: Implementation

Effectiveness:

Description: 

Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input.

CVE References