Category Archives: CWE

CWE-654 – Reliance on a Single Factor in a Security Decision

Read Time:56 Second

Description

A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-657
CWE-693

 

Consequences

Access Control: Gain Privileges or Assume Identity

If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor.

Non-Repudiation: Hide Activities

It can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security).

Phase: Architecture and Design

Description: 

Use redundant access rules on different choke points (e.g., firewalls).

CVE References

CWE-655 – Insufficient Psychological Acceptability

Read Time:41 Second

Description

The software has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-657
CWE-693

 

Consequences

Access Control: Bypass Protection Mechanism

By bypassing the security mechanism, a user might leave the system in a less secure state than intended by the administrator, making it more susceptible to compromise.

 

Potential Mitigations

Phase: Testing

Description: 

Where possible, perform human factors and usability studies to identify where your product’s security mechanisms are difficult to use, and why.

Phase: Architecture and Design

Description: 

Make the security mechanism as seamless as possible, while also providing the user with sufficient details when a security decision produces unexpected results.

CVE References

CWE-656 – Reliance on Security Through Obscurity

Read Time:1 Minute, 28 Second

Description

The software uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.

This reliance on “security through obscurity” can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-657
CWE-693
CWE-259
CWE-321
CWE-472

 

Consequences

Confidentiality, Integrity, Availability, Other: Other

The security mechanism can be bypassed easily.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysis of proprietary protocols, inferring file formats, and others.

Phase: Architecture and Design

Description: 

When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication.

CVE References

  • CVE-2006-6588
    • Reliance on hidden form fields in a web application. Many web application vulnerabilities exist because the developer did not consider that “hidden” form fields can be processed using a modified client.
  • CVE-2006-7142
    • Hard-coded cryptographic key stored in executable program.
  • CVE-2005-4002
    • Hard-coded cryptographic key stored in executable program.
  • CVE-2006-4068
    • Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.

CWE-657 – Violation of Secure Design Principles

Read Time:19 Second

Description

The product violates well-established principles for secure design.

This can introduce resultant weaknesses or make it easier for developers to introduce related weaknesses during implementation. Because code is centered around design, it can be resource-intensive to fix design problems.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-710

 

Consequences

Other: Other

 

Potential Mitigations

CVE References

CWE-66 – Improper Handling of File Names that Identify Virtual Resources

Read Time:33 Second

Description

The product does not handle or incorrectly handles a file name that identifies a “virtual” resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.

Virtual file names are represented like normal file names, but they are effectively aliases for other resources that do not behave like normal files. Depending on their functionality, they could be alternate entities. They are not necessarily listed in directories.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-706

 

Consequences

Other: Other

 

Potential Mitigations

CVE References

CWE-662 – Improper Synchronization

Read Time:28 Second

Description

The software utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-664
CWE-691
CWE-362

 

Consequences

Integrity, Confidentiality, Other: Modify Application Data, Read Application Data, Alter Execution Logic

 

Potential Mitigations

Phase: Implementation

Description: 

Use industry standard APIs to synchronize your code.

CVE References

CWE-663 – Use of a Non-reentrant Function in a Concurrent Context

Read Time:40 Second

Description

The software calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call the same function or otherwise influence its state.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-662

 

Consequences

Integrity, Confidentiality, Other: Modify Memory, Read Memory, Modify Application Data, Read Application Data, Alter Execution Logic

 

Potential Mitigations

Phase: Implementation

Description: 

Use reentrant functions if available.

Phase: Implementation

Description: 

Add synchronization to your non-reentrant function.

Phase: Implementation

Description: 

In Java, use the ReentrantLock Class.

CVE References

  • CVE-2001-1349
    • unsafe calls to library functions from signal handler
  • CVE-2004-2259
    • SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.

CWE-664 – Improper Control of a Resource Through its Lifetime

Read Time:15 Second

Description

The software does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

 

Consequences

Other: Other

 

Potential Mitigations

Phase: Testing

Description: 

Use Static analysis tools to check for unreleased resources.

CVE References

CWE-665 – Improper Initialization

Read Time:3 Minute, 13 Second

Description

The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.

This can have security implications when the associated resource is expected to have certain properties or values, such as a variable that determines whether a user has been authenticated or not.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-664

 

Consequences

Confidentiality: Read Memory, Read Application Data

When reusing a resource such as memory or a program variable, the original contents of that resource may not be cleared before it is sent to an untrusted party.

Access Control: Bypass Protection Mechanism

If security-critical decisions rely on a variable having a “0” or equivalent value, and the programming language performs this initialization on behalf of the programmer, then a bypass of security may occur.

Availability: DoS: Crash, Exit, or Restart

The uninitialized data may contain values that cause program flow to change in ways that the programmer did not intend. For example, if an uninitialized variable is used as an array index in C, then its previous contents may produce an index that is outside the range of the array, possibly causing a crash or an exit in other environments.

 

Potential Mitigations

Phase: Requirements

Description: 

Phase: Architecture and Design

Description: 

Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.

Phase: Implementation

Description: 

Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.

Phase: Implementation

Description: 

Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization.

Phase: Implementation

Description: 

Avoid race conditions (CWE-362) during initialization routines.

Phase: Build and Compilation

Description: 

Run or compile your software with settings that generate warnings about uninitialized variables or data.

Phase: Testing

Description: 

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

CVE References

  • CVE-2001-1471
    • chain: an invalid value prevents a library file from being included, skipping initialization of key variables, leading to resultant eval injection.
  • CVE-2008-3637
    • Improper error checking in protection mechanism produces an uninitialized variable, allowing security bypass and code execution.
  • CVE-2008-4197
    • Use of uninitialized memory may allow code execution.
  • CVE-2008-2934
    • Free of an uninitialized pointer leads to crash and possible code execution.
  • CVE-2007-3749
    • OS kernel does not reset a port when starting a setuid program, allowing local users to access the port and gain privileges.
  • CVE-2008-0063
    • Product does not clear memory contents when generating an error message, leading to information leak.
  • CVE-2008-0062
    • Lack of initialization triggers NULL pointer dereference or double-free.
  • CVE-2008-0081
    • Uninitialized variable leads to code execution in popular desktop application.
  • CVE-2008-3688
    • chain: Uninitialized variable leads to infinite loop.
  • CVE-2008-3475
    • chain: Improper initialization leads to memory corruption.
  • CVE-2008-5021
    • Composite: race condition allows attacker to modify an object while it is still being initialized, causing software to access uninitialized memory.
  • CVE-2005-1036
    • Chain: Bypass of access restrictions due to improper authorization (CWE-862) of a user results from an improperly initialized (CWE-909) I/O permission bitmap
  • CVE-2008-3597
    • chain: game server can access player data structures before initialization has happened leading to NULL dereference
  • CVE-2009-2692
    • chain: uninitialized function pointers can be dereferenced allowing code execution
  • CVE-2009-0949
    • chain: improper initialization of memory can lead to NULL dereference
  • CVE-2009-3620
    • chain: some unprivileged ioctls do not verify that a structure has been initialized before invocation, leading to NULL dereference

CWE-666 – Operation on Resource in Wrong Phase of Lifetime

Read Time:36 Second

Description

The software performs an operation on a resource at the wrong phase of the resource’s lifecycle, which can lead to unexpected behaviors.

When a developer wants to initialize, use or release a resource, it is important to follow the specifications outlined for how to operate on that resource and to ensure that the resource is in the expected state. In this case, the software wants to perform a normally valid operation, initialization, use or release, on a resource when it is in the incorrect phase of its lifetime.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-664

 

Consequences

Other: Other

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Follow the resource’s lifecycle from creation to release.

CVE References