CWE - VIEW SLICE: CWE-844: Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011) (4.10)

CWE VIEW: Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)

View ID: 844

Type: Graph

Downloads: Booklet | CSV | XML

Objective

CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the book "The CERT Oracle Secure Coding Standard for Java" published in 2011. This view is considered obsolete as a newer version of the coding standard is available.

Audience

Stakeholder	Description
Software Developers	By following The CERT Oracle Secure Coding Standard for Java, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Product Customers	If a software developer claims to be following The CERT Oracle Secure Coding Standard for Java, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
Educators	Educators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.

Relationships

The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.

Show Details:

Expand All | Collapse All

844 - Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS) - (845)

Weaknesses in this category are related to rules in the Input Validation and Data Sanitization (IDS) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Encoding or Escaping of Output - (116)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)) > 116 (Improper Encoding or Escaping of Output)

The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.Output SanitizationOutput ValidationOutput Encoding

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Externally-Controlled Format String - (134)

The product uses a function that accepts a format string as an argument, but the format string originates from an external source.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Line Delimiters - (144)

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.

The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.

The product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.

The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.

The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.

The product uses a regular expression that does not sufficiently restrict the set of allowed values.

The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters

The product uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL) - (846)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 846 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL))

Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 846 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL)) > 665 (Improper Initialization)

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

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP) - (847)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP))

Weaknesses in this category are related to rules in the Expressions (EXP) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)) > 252 (Unchecked Return Value)

The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

The product defines a signal handler that calls a non-reentrant function.

The product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.

The product uses the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM) - (848)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 848 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM))

Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 848 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)) > 197 (Numeric Truncation Error)

Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.

The product divides a value by zero.

When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ) - (849)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ))

Weaknesses in this category are related to rules in the Object Orientation (OBJ) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) > 374 (Passing Mutable Objects to an Untrusted Method)

The product sends non-cloned mutable data as an argument to a method or function.

Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.

The product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) > 491 (Public cloneable() Method Without Final ('Object Hijack'))

A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.

Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) > 493 (Critical Public Variable Without Final Modifier)

The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) > 498 (Cloneable Class Containing Sensitive Information)

The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.

An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.

The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.

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

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET) - (850)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET))

Weaknesses in this category are related to rules in the Methods (MET) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 487 (Reliance on Package-level Scope)

Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 568 (finalize() Method Without super.finalize())

The product contains a finalize() method that does not call super.finalize().

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 573 (Improper Following of Specification by Caller)

The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined)

The product does not maintain equal hashcodes for equal objects.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 583 (finalize() Method Declared Public)

The product violates secure coding principles for mobile code by declaring a finalize() method public.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 586 (Explicit Call to Finalize())

The product makes an explicit call to the finalize() method from outside the finalizer.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 589 (Call to Non-ubiquitous API)

The product uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 617 (Reachable Assertion)

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.assertion failure

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR) - (851)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR))

Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 209 (Generation of Error Message Containing Sensitive Information)

The product generates an error message that includes sensitive information about its environment, users, or associated data.

The product does not handle or incorrectly handles when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null.

The product does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.

An exception is thrown from a function, but it is not caught.

A J2EE application uses System.exit(), which also shuts down its container.

The product detects a specific error, but takes no actions to handle the error.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 395 (Use of NullPointerException Catch to Detect NULL Pointer Dereference)

Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.

Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.

The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 497 (Exposure of Sensitive System Information to an Unauthorized Control Sphere)

The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.

The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.

The Servlet does not catch all exceptions, which may reveal sensitive debugging information.Missing Catch Block

Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.Unchecked Return Value to NULL Pointer Dereference - (690)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 690 (Unchecked Return Value to NULL Pointer Dereference)

The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.

Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.Improper Check or Handling of Exceptional Conditions - (703)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 703 (Improper Check or Handling of Exceptional Conditions)

The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA) - (852)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA))

Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.

If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.

The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)) > 567 (Unsynchronized Access to Shared Data in a Multithreaded Context)

The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.

The product 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.

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK) - (853)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK))

Weaknesses in this category are related to rules in the Locking (LCK) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 412 (Unrestricted Externally Accessible Lock)

The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 413 (Improper Resource Locking)

The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 609 (Double-Checked Locking)

The product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 667 (Improper Locking)

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 820 (Missing Synchronization)

The product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 833 (Deadlock)

The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI) - (854)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 854 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI))

Weaknesses in this category are related to rules in the Thread APIs (THI) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 854 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)) > 572 (Call to Thread run() instead of start())

The product calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.

The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS) - (855)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 855 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS))

Weaknesses in this category are related to rules in the Thread Pools (TPS) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 855 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)) > 392 (Missing Report of Error Condition)

The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.

The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."

The product's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 13 - Thread-Safety Miscellaneous (TSM) - (856)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 856 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 13 - Thread-Safety Miscellaneous (TSM))

Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO) - (857)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO))

Weaknesses in this category are related to rules in the Input Output (FIO) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 135 (Incorrect Calculation of Multi-Byte String Length)

The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.

The product receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.

During installation, installed file permissions are set to allow anyone to modify those files.

While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 359 (Exposure of Private Personal Information to an Unauthorized Actor)

The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.Privacy violationPrivacy leakPrivacy leakage

Creating and using insecure temporary files can leave application and system data vulnerable to attack.

The product does not release or incorrectly releases a resource before it is made available for re-use.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 405 (Asymmetric Resource Consumption (Amplification))

The product does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 532 (Insertion of Sensitive Information into Log File)

Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.

The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 732 (Incorrect Permission Assignment for Critical Resource)

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 770 (Allocation of Resources Without Limits or Throttling)

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER) - (858)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER))

Weaknesses in this category are related to rules in the Serialization (SER) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)) > 250 (Execution with Unnecessary Privileges)

The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.Resource Exhaustion

The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.

The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, UnpicklingPHP Object Injection

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC) - (859)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC))

Weaknesses in this category are related to rules in the Platform Security (SEC) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 111 (Direct Use of Unsafe JNI)

When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.

A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.

The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.

The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.Adversary-in-the-Middle / AITMMan-in-the-Middle / MITMPerson-in-the-Middle / PITMMonkey-in-the-MiddleMonster-in-the-MiddleOn-path attackInterception attack

The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.Reflection Injection

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV) - (860)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 860 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV))

Weaknesses in this category are related to rules in the Runtime Environment (ENV) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 860 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 860 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)) > 732 (Incorrect Permission Assignment for Critical Resource)

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC) - (861)

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC))

Weaknesses in this category are related to rules in the Miscellaneous (MSC) chapter of The CERT Oracle Secure Coding Standard for Java (2011).

844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)) > 259 (Use of Hard-coded Password)

The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.

The product does not encrypt sensitive or critical information before storage or transmission.

The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.

True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.

A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.

A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.

The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak

The product uses the singleton pattern when creating a resource within a multithreaded environment.

The product contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.

Notes

Relationship

The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.

References

[REF-813] Fred Long, Dhruv Mohindra, Robert C. Seacord, Dean F. Sutherland and David Svoboda. "The CERT Oracle Coding Standard for Java". 1st Edition. Addison-Wesley Professional. 2011-09-18.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	104	out of	933
Categories	17	out of	352
Views	0	out of	47
Total	121	out of	1332

Content History

Submissions
Submission Date	Submitter	Organization
2011-05-24	CWE Content Team	MITRE
2011-05-24
Modifications
Modification Date	Modifier	Organization
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Description, Name, References, View_Audience
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated View_Audience
Previous Entry Names
Change Date	Previous Entry Name
2019-01-03	Weaknesses Addressed by the CERT Java Secure Coding Standard

View Components

Weakness ID: 770

Abstraction: Base
Structure: Simple

View customized information:

Description

Extended Description

Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	665	Improper Initialization
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	400	Uncontrolled Resource Consumption
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	774	Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	789	Memory Allocation with Excessive Size Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1325	Improperly Controlled Sequential Memory Allocation
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	20	Improper Input Validation

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	840	Business Logic Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	400	Uncontrolled Resource Consumption

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Often Prevalent)

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other) When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This code allocates a socket and forks each time it receives a new connection.

(bad code)

Example Language: C

sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {

newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();

}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.

Example 2

In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)

Example Language: C

int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {

printf("Unable to open socket connection");
return(FAIL);

}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {

if (openFileToWrite(filename) > 0) {

while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){

if (!(writeToFile(buffer) > 0))

break;

}

}
closeFile();

}
closeSocket(socket);

}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.

Example 3

In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)

Example Language: C

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{

char *body;

int length = getMessageLength(message[0]);

if (length > 0) {

body = &message[1][0];
processMessageBody(body);
return(SUCCESS);

}
else {

printf("Unable to process message; invalid message length");
return(FAIL);

}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)

Example Language: C

unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}

Example 4

In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)

Example Language: Java

public void acceptConnections() {

try {

ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {

Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();

}
serverSocket.close();

} catch (IOException ex) {...}

}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)

Example Language: Java

public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {

try {

ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {

hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);

}
serverSocket.close();

} catch (IOException ex) {...}

}

Example 5

An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:

[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.

Example 6

Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

(bad code)

Example Language: C

bar connection() {

foo = malloc(1024);
return foo;

}

endConnection(bar foo) {

free(foo);

}

int main() {

while(1) {

foo=connection();

}

endConnection(foo)

}

Observed Examples

Reference	Description
CVE-2022-21668	Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
CVE-2009-4017	Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
CVE-2009-2726	Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
CVE-2009-2540	Large integer value for a length property in an object causes a large amount of memory allocation.
CVE-2009-2054	Product allows exhaustion of file descriptors when processing a large number of TCP packets.
CVE-2008-5180	Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
CVE-2008-1700	Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CVE-2005-4650	CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
CVE-2020-15100	web application scanner attempts to read an excessively large file created by a user, causing process termination
CVE-2020-7218	Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service

Potential Mitigations

Phase: Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Phase: Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Phase: Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Note: This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Phase: Architecture and Design

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: Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:

recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays

uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Phase: Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Ensure that all failures in resource allocation place the system into a safe posture.

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

Detection Methods

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	857	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	858	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	861	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	985	SFP Secondary Cluster: Unrestricted Consumption
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1147	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1148	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1152	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)

Notes

Relationship

This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)	FIO04-J	Close resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)	SER12-J	Avoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011)	MSC05-J	Do not exhaust heap space

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-125	Flooding
CAPEC-130	Excessive Allocation
CAPEC-147	XML Ping of the Death
CAPEC-197	Exponential Data Expansion
CAPEC-229	Serialized Data Parameter Blowup
CAPEC-230	Serialized Data with Nested Payloads
CAPEC-231	Oversized Serialized Data Payloads
CAPEC-469	HTTP DoS
CAPEC-482	TCP Flood
CAPEC-486	UDP Flood
CAPEC-487	ICMP Flood
CAPEC-488	HTTP Flood
CAPEC-489	SSL Flood
CAPEC-490	Amplification
CAPEC-491	Quadratic Data Expansion
CAPEC-493	SOAP Array Blowup
CAPEC-494	TCP Fragmentation
CAPEC-495	UDP Fragmentation
CAPEC-496	ICMP Fragmentation
CAPEC-528	XML Flood

References

[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.

[REF-387] D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.

[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23. <http://blogs.sans.org/appsecstreetfighter/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2009-05-13	CWE Content Team	MITRE
2009-05-13
Modifications
Modification Date	Modifier	Organization
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Related_Attack_Patterns
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Demonstrative_Examples, Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Detection_Factors, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Related_Attack_Patterns
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors

Weakness ID: 405

Abstraction: Class
Structure: Simple

View customized information:

Description

Extended Description

This can lead to poor performance due to "amplification" of resource consumption, typically in a non-linear fashion. This situation is worsened if the product allows malicious users or attackers to consume more resources than their access level permits.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	664	Improper Control of a Resource Through its Lifetime
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	406	Insufficient Control of Network Message Volume (Network Amplification)
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	407	Inefficient Algorithmic Complexity
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	408	Incorrect Behavior Order: Early Amplification
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	409	Improper Handling of Highly Compressed Data (Data Amplification)
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1050	Excessive Platform Resource Consumption within a Loop
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1072	Data Resource Access without Use of Connection Pooling
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1073	Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1084	Invokable Control Element with Excessive File or Data Access Operations
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1089	Large Data Table with Excessive Number of Indices
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1094	Excessive Index Range Scan for a Data Resource
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1176	Inefficient CPU Computation
PeerOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	404	Improper Resource Shutdown or Release

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation
Operation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Client Server (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Amplification; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other) Sometimes this is a factor in "flood" attacks, but other types of amplification exist.	High

Demonstrative Examples

Example 1

This code listens on a port for DNS requests and sends the result to the requesting address.

(bad code)

Example Language: Python

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) )
while true:

data = sock.recvfrom(1024)
if not data:

break

(requestIP, nameToResolve) = parseUDPpacket(data)
record = resolveName(nameToResolve)
sendResponse(requestIP,record)

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.

Example 2

This data prints the contents of a specified file requested by a user.

(bad code)

Example Language: PHP

function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){

echo $file;
return true;

}
else{

echo 'You are not authorized to view this file';

}
return false;

}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.

Example 3

The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

(attack code)

Example Language: XML

<?xml version="1.0"?>
<!DOCTYPE MaliciousDTD [
<!ENTITY ZERO "A">
<!ENTITY ONE "&ZERO;&ZERO;">
<!ENTITY TWO "&ONE;&ONE;">
...
<!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
]>
<data>&THIRTYTWO;</data>

Example 4

This example attempts to check if an input string is a "sentence" [REF-1164].

(bad code)

Example Language: JavaScript

var test_string = "Bad characters: $@#";
var bad_pattern = /^(\w+\s?)*$/i;
var result = test_string.search(bad_pattern);

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases.

To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

(good code)

Example Language: JavaScript

var test_string = "Bad characters: $@#";
var good_pattern = /^((?=(\w+))\2\s?)*$/i;
var result = test_string.search(good_pattern);

Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.

Example 5

An adversary can cause significant resource consumption on a server by filtering the cryptographic algorithms offered by the client to the ones that are the most resource-intensive on the server side. After discovering which cryptographic algorithms are supported by the server, a malicious client can send the initial cryptographic handshake messages that contains only the resource-intensive algorithms. For some cryptographic protocols, these messages can be completely prefabricated, as the resource-intensive part of the handshake happens on the server-side first (such as TLS), rather than on the client side. In the case of cryptographic protocols where the resource-intensive part should happen on the client-side first (such as SSH), a malicious client can send a forged/precalculated computation result, which seems correct to the server, so the resource-intensive part of the handshake is going to happen on the server side. A malicious client is required to send only the initial messages of a cryptographic handshake to initiate the resource-consuming part of the cryptographic handshake. These messages are usually small, and generating them requires minimal computational effort, enabling a denial-of-service attack. An additional risk is the fact that higher key size increases the effectiveness of the attack. Cryptographic protocols where the clients have influence over the size of the used key (such as TLS 1.3 or SSH) are most at risk, as the client can enforce the highest key size supported by the server.

Observed Examples

Reference	Description
CVE-1999-0513	Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
CVE-2003-1564	Parsing library allows XML bomb
CVE-2004-2458	Tool creates directories before authenticating user.
CVE-2020-10735	Python has "quadratic complexity" issue when converting string to int with many digits in unexpected bases
CVE-2020-5243	server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
CVE-2013-5211	composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
CVE-2002-20001	Diffie-Hellman (DHE) Key Agreement Protocol allows attackers to send arbitrary numbers that are not public keys, which causes the server to perform expensive, unnecessary computation of modular exponentiation.
CVE-2022-40735	The Diffie-Hellman Key Agreement Protocol allows use of long exponents, which are more computationally expensive than using certain "short exponents" with particular properties.

Potential Mitigations

Phase: Architecture and Design

An application must make resources available to a client commensurate with the client's access level.

Phase: Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.

Phase: System Configuration

Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.

Effectiveness: High

Note: Business requirements may prevent disabling resource-intensive algorithms.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	730	OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	855	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	857	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	977	SFP Secondary Cluster: Design
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1145	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1147	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Asymmetric resource consumption (amplification)
OWASP Top Ten 2004	A9	CWE More Specific	Denial of Service
WASC	41		XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011)	TPS00-J		Use thread pools to enable graceful degradation of service during traffic bursts
The CERT Oracle Secure Coding Standard for Java (2011)	FIO04-J		Release resources when they are no longer needed

References

[REF-1164] Ilya Kantor. "Catastrophic backtracking". 2020-12-13. <https://javascript.info/regexp-catastrophic-backtracking>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	PLOVER
2006-07-19
Contributions
Contribution Date	Contributor	Organization
2021-11-11	Szilɕrd Pfeiffer	Balasys IT Security
2021-11-11	Submitted content that led to modifications in applicable platforms, common consequences, potential mitigations, demonstrative examples, observed examples.
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Description
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Common_Consequences, Other_Notes
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Taxonomy_Mappings
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Description
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Functional_Areas
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Time_of_Introduction

Weakness ID: 319

Abstraction: Base
Structure: Simple

View customized information:

Description

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Extended Description

Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data.

Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries.

When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	5	J2EE Misconfiguration: Data Transmission Without Encryption
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	614	Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	199	Information Management Errors

Relevant to the view "Hardware Design" (CWE-1194)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1207	Debug and Test Problems

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1013	Encrypt Data

Modes Of Introduction

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design	For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.
Operation
System Configuration

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality	Technical Impact: Read Application Data; Modify Files or Directories Anyone can read the information by gaining access to the channel being used for communication.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)

Example Language: Java

try {

URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();

}
catch (IOException e) {

//...

}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

Example 2

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors used cleartext transmission of sensitive information in their OT products.

Example 3

A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed.

Example 4

The following Azure CLI command lists the properties of a particular storage account:

(informative)

Example Language: Shell

az storage account show -g {ResourceGroupName} -n {StorageAccountName}

The JSON result might be:

(bad code)

Example Language: JSON

{

"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"

}

The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.).

Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as:

(good code)

Example Language: Shell

az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true:

(good code)

Example Language: JSON

{

"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"

}

Note: to enable secure transfer using Azure's Portal instead of the command line:

1. Open the Create storage account pane in the Azure portal.
2. In the Advanced page, select the Enable secure transfer checkbox.

Observed Examples

Reference	Description
CVE-2022-29519	Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
CVE-2022-30312	Building Controller uses a protocol that transmits authentication credentials in plaintext.
CVE-2022-31204	Programmable Logic Controller (PLC) sends password in plaintext.
CVE-2002-1949	Passwords transmitted in cleartext.
CVE-2008-4122	Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
CVE-2008-3289	Product sends password hash in cleartext in violation of intended policy.
CVE-2008-4390	Remote management feature sends sensitive information including passwords in cleartext.
CVE-2007-5626	Backup routine sends password in cleartext in email.
CVE-2004-1852	Product transmits Blowfish encryption key in cleartext.
CVE-2008-0374	Printer sends configuration information, including administrative password, in cleartext.
CVE-2007-4961	Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
CVE-2007-4786	Product sends passwords in cleartext to a log server.
CVE-2005-3140	Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.

Potential Mitigations

Phase: Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Implementation

When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	818	OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	858	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	859	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	934	OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1148	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1346	OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures

Notes

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Plaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011)	SEC06-J	Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011)	SER02-J	Sign then seal sensitive objects before sending them outside a trust boundary
Software Fault Patterns	SFP23	Exposed Data
ISA/IEC 62443	Part 3-3	Req SR 4.1
ISA/IEC 62443	Part 4-2	Req CR 4.1B

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-102	Session Sidejacking
CAPEC-117	Interception
CAPEC-383	Harvesting Information via API Event Monitoring
CAPEC-477	Signature Spoofing by Mixing Signed and Unsigned Content
CAPEC-65	Sniff Application Code

References

[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.

[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.

[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.

[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Sections 3.1 and 3.10. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.

[REF-1309] Microsoft. "Require secure transfer to ensure secure connections". 2022-07-24. <https://learn.microsoft.com/en-us/azure/storage/common/storage-require-secure-transfer>. URL validated: 2023-01-24.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	PLOVER
2006-07-19
Contributions
Contribution Date	Contributor	Organization
2023-01-24	Accellera IP Security Assurance (IPSA) Working Group	Accellera Systems Initiative
2023-01-24	Submitted original contents of CWE-1324 and reviewed its integration into this entry.
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Detection_Factors, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Observed_Examples, Related_Attack_Patterns
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Potential_Mitigations
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Applicable_Platforms, References
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23	CWE Content Team	MITRE
2018-01-23	updated Abstraction
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships, Type
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Plaintext Transmission of Sensitive Information

Weakness ID: 362

Abstraction: Class
Structure: Simple

View customized information:

Description

Extended Description

This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

A race condition occurs within concurrent environments, and is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc.

A race condition violates these properties, which are closely related:

Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.
Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	691	Insufficient Control Flow Management
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	364	Signal Handler Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	366	Race Condition within a Thread
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	368	Context Switching Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	421	Race Condition During Access to Alternate Channel
ParentOf	Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.	689	Permission Race Condition During Resource Copy
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1223	Race Condition for Write-Once Attributes
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1298	Hardware Logic Contains Race Conditions
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	662	Improper Synchronization

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

Languages

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other) When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion (CWE-400).
Availability	Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Confidentiality Integrity	Technical Impact: Read Files or Directories; Read Application Data When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account.

(bad code)

Example Language: Perl

$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {

FatalError("Bad Transfer Amount");

}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {

FatalError("Insufficient Funds");

}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Suppose the balance is initially 100.00. An attack could be constructed as follows:

(attack code)

Example Language: Other

In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00

At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database.

To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Example 2

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)

Example Language: C

void f(pthread_mutex_t *mutex) {

pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);

}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)

Example Language: C

int f(pthread_mutex_t *mutex) {

int result;

result = pthread_mutex_lock(mutex);
if (0 != result)

return result;

/* access shared resource */

return pthread_mutex_unlock(mutex);

}

Example 3

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.

Observed Examples

Reference	Description
CVE-2022-29527	Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
CVE-2021-1782	Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
CVE-2021-0920	Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2020-6819	Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2019-18827	chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
CVE-2019-1161	Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and deleted.
CVE-2015-1743	TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
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].
CVE-2008-5044	Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
CVE-2008-2958	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-1570	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-0058	Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
CVE-2008-0379	Race condition during initialization triggers a buffer overflow.
CVE-2007-6599	Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
CVE-2007-6180	chain: race condition triggers NULL pointer dereference
CVE-2007-5794	Race condition in library function could cause data to be sent to the wrong process.
CVE-2007-3970	Race condition in file parser leads to heap corruption.
CVE-2008-5021	chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
CVE-2009-4895	chain: race condition for an argument value, possibly resulting in NULL dereference
CVE-2009-3547	chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
CVE-2006-5051	Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).

Potential Mitigations

Phase: Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Phase: Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.

Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Phase: Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Phase: Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Phase: Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Phase: Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Phase: Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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.

Detection Methods

Black Box

Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.

White Box

Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Race conditions may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior.

Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect.

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Cost effective for partial coverage:

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner

Web Services Scanner

Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Framework-based Fuzzer

Cost effective for partial coverage:

Fuzz Tester

Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	743	CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	801	2010 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	852	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	882	CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	988	SFP Secondary Cluster: Race Condition Window
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1142	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1376	ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses

Notes

Research Gap

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Research Gap

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Race Conditions
The CERT Oracle Secure Coding Standard for Java (2011)	VNA03-J		Do not assume that a group of calls to independently atomic methods is atomic

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-26	Leveraging Race Conditions
CAPEC-29	Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.

[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <http://www.ddj.com/cpp/184403766>.

[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.

[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.

[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.

[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.

[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <http://www.blakewatts.com/namedpipepaper.html>.

[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.

[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.

[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <http://blogs.sans.org/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>.

[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	PLOVER
2006-07-19
Contributions
Contribution Date	Contributor	Organization
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples, Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, References, Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, References, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Observed_Examples, References
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Observed_Examples, Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Common_Consequences, Description
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Race Conditions

2010-12-13	Race Condition

Weakness ID: 502

Abstraction: Base
Structure: Simple

View customized information:

Description

The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.

Extended Description

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption.

Data that is untrusted can not be trusted to be well-formed.

When developers place no restrictions on "gadget chains," or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

Alternate Terms

Marshaling, Unmarshaling:	Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.
Pickling, Unpickling:	In Python, the "pickle" functionality is used to perform serialization and deserialization.
PHP Object Injection:	Some PHP application researchers use this term when attacking unsafe use of the unserialize() function; but it is also used for CWE-915.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	913	Improper Control of Dynamically-Managed Code Resources
PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	915	Improperly Controlled Modification of Dynamically-Determined Object Attributes

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	913	Improper Control of Dynamically-Managed Code Resources

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1019	Validate Inputs

Background Details

Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred ("serialization"), then extracting the serialized data to reconstruct the original object ("deserialization").

Modes Of Introduction

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation

Applicable Platforms

Languages

Java (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

Common Consequences

Scope	Impact	Likelihood
Integrity	Technical Impact: Modify Application Data; Unexpected State Attackers can modify unexpected objects or data that was assumed to be safe from modification.
Availability	Technical Impact: DoS: Resource Consumption (CPU) If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other	Technical Impact: Varies by Context The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation.

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This code snippet deserializes an object from a file and uses it as a UI button:

(bad code)

Example Language: Java

try {

File file = new File("object.obj");
ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
javax.swing.JButton button = (javax.swing.JButton) in.readObject();
in.close();

}

This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.

To mitigate this, explicitly define final readObject() to prevent deserialization. An example of this is:

(good code)

Example Language: Java

private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); }

Example 2

In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [REF-467], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token.

(bad code)

Example Language: Python

try {

class ExampleProtocol(protocol.Protocol):
def dataReceived(self, data):

# Code that would be here would parse the incoming data
# After receiving headers, call confirmAuth() to authenticate

def confirmAuth(self, headers):
try:
token = cPickle.loads(base64.b64decode(headers['AuthToken']))
if not check_hmac(token['signature'], token['data'], getSecretKey()):
raise AuthFail
self.secure_data = token['data']
except:
raise AuthFail

}

Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess module and execute /bin/sh.

Observed Examples

Reference	Description
CVE-2019-12799	chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
CVE-2015-8103	Deserialization issue in commonly-used Java library allows remote execution.
CVE-2015-4852	Deserialization issue in commonly-used Java library allows remote execution.
CVE-2013-1465	Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
CVE-2012-3527	Use of PHP unserialize function on untrusted input in content management system might allow code execution.
CVE-2012-0911	Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
CVE-2012-0911	Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
CVE-2011-2520	Python script allows local users to execute code via pickled data.
CVE-2012-4406	Unsafe deserialization using pickle in a Python script.
CVE-2003-0791	Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.

Potential Mitigations

Phases: Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Phase: Implementation

When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Phase: Implementation

Explicitly define a final object() to prevent deserialization.

Phases: Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

Phase: Implementation

Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	858	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	994	SFP Secondary Cluster: Tainted Input to Variable
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1034	OWASP Top Ten 2017 Category A8 - Insecure Deserialization
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1148	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1308	CISQ Quality Measures - Security
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1340	CISQ Data Protection Measures
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1354	OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses

Notes

Maintenance

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
CLASP		Deserialization of untrusted data
The CERT Oracle Secure Coding Standard for Java (2011)	SER01-J	Do not deviate from the proper signatures of serialization methods
The CERT Oracle Secure Coding Standard for Java (2011)	SER03-J	Do not serialize unencrypted, sensitive data
The CERT Oracle Secure Coding Standard for Java (2011)	SER06-J	Make defensive copies of private mutable components during deserialization
The CERT Oracle Secure Coding Standard for Java (2011)	SER08-J	Do not use the default serialized form for implementation defined invariants
Software Fault Patterns	SFP25	Tainted input to variable

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-586	Object Injection

References

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.

[REF-461] Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <http://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>.

[REF-462] Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27. <http://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>.

[REF-463] Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28. <http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>.

[REF-464] Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <http://heine.familiedeelstra.com/security/unserialize>.

[REF-465] Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26. <http://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>.

[REF-466] Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://nadiana.com/python-pickle-insecure>.

[REF-467] Nelson Elhage. "Exploiting misuse of Python's "pickle"". 2011-03-20. <https://blog.nelhage.com/2011/03/exploiting-pickle/>.

[REF-468] Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21. <https://www.slideshare.net/frohoff1/deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	CLASP
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Description, Other_Notes, Potential_Mitigations
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Demonstrative_Examples
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Observed_Examples, References, Relationships
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Type
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Observed_Examples, References, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Alternate_Terms, Potential_Mitigations
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description

Common Weakness Enumeration

CWE VIEW: Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)

View Components

CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

CWE-582: Array Declared Public, Final, and Static

CWE-405: Asymmetric Resource Consumption (Amplification)

CWE-289: Authentication Bypass by Alternate Name

CWE-302: Authentication Bypass by Assumed-Immutable Data

CWE-589: Call to Non-ubiquitous API

CWE-572: Call to Thread run() instead of start()

CWE-300: Channel Accessible by Non-Endpoint

CWE-319: Cleartext Transmission of Sensitive Information

CWE-498: Cloneable Class Containing Sensitive Information

CWE-182: Collapse of Data into Unsafe Value

CWE-486: Comparison of Classes by Name

CWE-595: Comparison of Object References Instead of Object Contents

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

CWE-766: Critical Data Element Declared Public

CWE-493: Critical Public Variable Without Final Modifier

CWE-833: Deadlock

CWE-397: Declaration of Throws for Generic Exception

CWE-502: Deserialization of Untrusted Data

CWE-390: Detection of Error Condition Without Action

CWE-111: Direct Use of Unsafe JNI