CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-844: Weaknesses Addressed by the CERT Java Secure Coding Standard (2.10)  
ID

CWE VIEW: Weaknesses Addressed by the CERT Java Secure Coding Standard

Mapping-Friendly:
View ID: 844
Structure: Graph
Status: Incomplete
Presentation Filter:
+ View Data

View Objective

CWE entries in this view (graph) are fully or partially eliminated by following the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this view is incomplete.

+ View Audience
StakeholderDescription
Developers

By following the CERT Java Secure Coding Standard, 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.

Software_Customers

If a software developer claims to be following the CERT Java Secure Coding standard, 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
844 - Weaknesses Addressed by the CERT Java Secure Coding Standard
+CategoryCategoryCERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS) - (845)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS))
Weaknesses in this category are related to rules in the Input Validation and Data Sanitization section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness VariantWeakness VariantAuthentication Bypass by Alternate Name - (289)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 289 (Authentication Bypass by Alternate Name)
The software 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.
*CategoryCategoryCleansing, Canonicalization, and Comparison Errors - (171)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 171 (Cleansing, Canonicalization, and Comparison Errors)
Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
*Weakness BaseWeakness BaseCollapse of Data into Unsafe Value - (182)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 182 (Collapse of Data into Unsafe Value)
The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
*Weakness ClassWeakness ClassImproper Encoding or Escaping of Output - (116)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 116 (Improper Encoding or Escaping of Output)
The software 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
*Weakness BaseWeakness BaseImproper Handling of Highly Compressed Data (Data Amplification) - (409)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 409 (Improper Handling of Highly Compressed Data (Data Amplification))
The software does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
*Weakness VariantWeakness VariantImproper Neutralization of Escape, Meta, or Control Sequences - (150)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The software 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.
*Weakness VariantWeakness VariantImproper Neutralization of Line Delimiters - (144)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 144 (Improper Neutralization of Line Delimiters)
The software 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.
*Weakness BaseWeakness BaseImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software 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
*Weakness BaseWeakness BaseInappropriate Encoding for Output Context - (838)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 838 (Inappropriate Encoding for Output Context)
The software 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.
*Weakness BaseWeakness BaseIncorrect Behavior Order: Validate Before Canonicalize - (180)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 180 (Incorrect Behavior Order: Validate Before Canonicalize)
The software validates input before it is canonicalized, which prevents the software from detecting data that becomes invalid after the canonicalization step.
*Weakness BaseWeakness BasePermissive Regular Expression - (625)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 625 (Permissive Regular Expression)
The product uses a regular expression that does not sufficiently restrict the set of allowed values.
*Weakness BaseWeakness BaseUse of Externally-Controlled Format String - (134)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 134 (Use of Externally-Controlled Format String)
The software uses a function that accepts a format string as an argument, but the format string originates from an external source.
*Weakness VariantWeakness VariantUse of Non-Canonical URL Paths for Authorization Decisions - (647)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The software 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.
+CategoryCategoryCERT Java Secure Coding Section 01 - Declarations and Initialization (DCL) - (846)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 846 (CERT Java Secure Coding Section 01 - Declarations and Initialization (DCL))
Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness ClassWeakness ClassImproper Initialization - (665)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 846 (CERT Java Secure Coding Section 01 - Declarations and Initialization (DCL)) > 665 (Improper Initialization)
The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
+CategoryCategoryCERT Java Secure Coding Section 02 - Expressions (EXP) - (847)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP))
Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseComparison of Object References Instead of Object Contents - (595)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 595 (Comparison of Object References Instead of Object Contents)
The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
*Weakness VariantWeakness VariantSignal Handler Use of a Non-reentrant Function - (479)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 479 (Signal Handler Use of a Non-reentrant Function)
The program defines a signal handler that calls a non-reentrant function.
*Weakness BaseWeakness BaseUnchecked Return Value - (252)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 252 (Unchecked Return Value)
The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*Weakness VariantWeakness VariantUse of Wrong Operator in String Comparison - (597)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 597 (Use of Wrong Operator in String Comparison)
The product uses the wrong operator when comparing a string, such as using "==" when the equals() method should be used instead.
+CategoryCategoryCERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM) - (848)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM))
Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseDivide By Zero - (369)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)) > 369 (Divide By Zero)
The product divides a value by zero.
*Weakness BaseWeakness BaseIncorrect Conversion between Numeric Types - (681)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)) > 681 (Incorrect Conversion between Numeric Types)
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.
*Weakness BaseWeakness BaseNumeric Truncation Error - (197)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - 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.
+CategoryCategoryCERT Java Secure Coding Section 04 - Object Orientation (OBJ) - (849)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ))
Weaknesses in this category are related to rules in the Object Orientation (OBJ) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness VariantWeakness VariantArray Declared Public, Final, and Static - (582)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 582 (Array Declared Public, Final, and Static)
The program declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
*Weakness VariantWeakness VariantCloneable Class Containing Sensitive Information - (498)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*Weakness VariantWeakness VariantComparison of Classes by Name - (486)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 486 (Comparison of Classes by Name)
The program compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
*Weakness VariantWeakness VariantCritical Public Variable Without Final Modifier - (493)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*Weakness VariantWeakness VariantCritical Variable Declared Public - (766)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 766 (Critical Variable Declared Public)
The software declares a critical variable or field to be public when intended security policy requires it to be private.
*Weakness BaseWeakness BasePassing Mutable Objects to an Untrusted Method - (374)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 374 (Passing Mutable Objects to an Untrusted Method)
The program sends non-cloned mutable data as an argument to a method or function.
*Weakness VariantWeakness VariantPublic Static Field Not Marked Final - (500)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 500 (Public Static Field Not Marked Final)
An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.
*Weakness VariantWeakness VariantPublic cloneable() Method Without Final ('Object Hijack') - (491)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*Weakness BaseWeakness BaseReturning a Mutable Object to an Untrusted Caller - (375)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 375 (Returning a Mutable Object to an Untrusted Caller)
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
*Weakness VariantWeakness VariantUse of Inner Class Containing Sensitive Data - (492)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 492 (Use of Inner Class Containing Sensitive Data)
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.
+CategoryCategoryCERT Java Secure Coding Section 05 - Methods (MET) - (850)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET))
Weaknesses in this category are related to rules in the Methods (MET) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness VariantWeakness VariantCall to Non-ubiquitous API - (589)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 589 (Call to Non-ubiquitous API)
The software 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.
*Weakness VariantWeakness VariantExplicit Call to Finalize() - (586)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 586 (Explicit Call to Finalize())
The software makes an explicit call to the finalize() method from outside the finalizer.
*Weakness ClassWeakness ClassImproper Following of Specification by Caller - (573)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 573 (Improper Following of Specification by Caller)
The software does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
*Weakness BaseWeakness BaseObject Model Violation: Just One of Equals and Hashcode Defined - (581)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined)
The software does not maintain equal hashcodes for equal objects.
*Weakness VariantWeakness VariantReachable Assertion - (617)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - 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.
*Weakness VariantWeakness VariantReliance on Package-level Scope - (487)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - 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.
*Weakness VariantWeakness Variantfinalize() Method Declared Public - (583)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 583 (finalize() Method Declared Public)
The program violates secure coding principles for mobile code by declaring a finalize() method public.
*Weakness VariantWeakness Variantfinalize() Method Without super.finalize() - (568)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 568 (finalize() Method Without super.finalize())
The software contains a finalize() method that does not call super.finalize().
+CategoryCategoryCERT Java Secure Coding Section 06 - Exceptional Behavior (ERR) - (851)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR))
Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseDeclaration of Throws for Generic Exception - (397)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 397 (Declaration of Throws for Generic Exception)
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*Weakness ClassWeakness ClassDetection of Error Condition Without Action - (390)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 390 (Detection of Error Condition Without Action)
The software detects a specific error, but takes no actions to handle the error.
*Weakness VariantWeakness VariantExposure of System Data to an Unauthorized Control Sphere - (497)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 497 (Exposure of System Data to an Unauthorized Control Sphere)
Exposing system data or debugging information helps an adversary learn about the system and form an attack plan.
*Weakness ClassWeakness ClassImproper Check or Handling of Exceptional Conditions - (703)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 703 (Improper Check or Handling of Exceptional Conditions)
The software does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the software.
*Weakness VariantWeakness VariantImproper Cleanup on Thrown Exception - (460)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 460 (Improper Cleanup on Thrown Exception)
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.
*Weakness VariantWeakness VariantImproper Handling of Missing Values - (230)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 230 (Improper Handling of Missing Values)
The software 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.
*Weakness VariantWeakness VariantImproper Handling of Undefined Values - (232)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 232 (Improper Handling of Undefined Values)
The software does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.
*Weakness ClassWeakness ClassIncorrect Control Flow Scoping - (705)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
*Weakness BaseWeakness BaseInformation Exposure Through an Error Message - (209)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 209 (Information Exposure Through an Error Message)
The software generates an error message that includes sensitive information about its environment, users, or associated data.
*Weakness VariantWeakness VariantJ2EE Bad Practices: Use of System.exit() - (382)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 382 (J2EE Bad Practices: Use of System.exit())
A J2EE application uses System.exit(), which also shuts down its container.
*Weakness BaseWeakness BaseReturn Inside Finally Block - (584)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 584 (Return Inside Finally Block)
The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.
*Weakness BaseWeakness BaseUncaught Exception - (248)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 248 (Uncaught Exception)
An exception is thrown from a function, but it is not caught.
*Weakness BaseWeakness BaseUncaught Exception in Servlet - (600)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 600 (Uncaught Exception in Servlet )
The Servlet does not catch all exceptions, which may reveal sensitive debugging information.Missing Catch Block
*Compound Element: ChainCompound Element: ChainUnchecked Return Value to NULL Pointer Dereference - (690)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
*Weakness BaseWeakness BaseUse of NullPointerException Catch to Detect NULL Pointer Dereference - (395)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
+CategoryCategoryCERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA) - (852)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA))
Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness ClassWeakness ClassConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program 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.
*Weakness BaseWeakness BaseImproper Synchronization - (662)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 662 (Improper Synchronization)
The software attempts to use a shared resource in an exclusive manner, but does not prevent or incorrectly prevents use of the resource by another thread or process.
*Weakness BaseWeakness BaseRace Condition within a Thread - (366)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 366 (Race Condition within a Thread)
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.
*Weakness BaseWeakness BaseUnsynchronized Access to Shared Data in a Multithreaded Context - (567)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - 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.
*Weakness BaseWeakness BaseImproper Locking - (667)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 667 (Improper Locking)
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
*Weakness BaseWeakness BaseImproper Resource Locking - (413)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 413 (Improper Resource Locking)
The software does not lock or does not correctly lock a resource when the software must have exclusive access to the resource.
+CategoryCategoryCERT Java Secure Coding Section 08 - Locking (LCK) - (853)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK))
Weaknesses in this category are related to rules in the Locking (LCK) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseDeadlock - (833)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 833 (Deadlock)
The software contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
*Weakness BaseWeakness BaseDouble-Checked Locking - (609)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 609 (Double-Checked Locking)
The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
*Weakness BaseWeakness BaseImproper Locking - (667)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 667 (Improper Locking)
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
*Weakness BaseWeakness BaseImproper Resource Locking - (413)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 413 (Improper Resource Locking)
The software does not lock or does not correctly lock a resource when the software must have exclusive access to the resource.
*Weakness BaseWeakness BaseMissing Synchronization - (820)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 820 (Missing Synchronization)
The software utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
*Weakness BaseWeakness BaseUnrestricted Externally Accessible Lock - (412)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 412 (Unrestricted Externally Accessible Lock)
The software 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.
+CategoryCategoryCERT Java Secure Coding Section 09 - Thread APIs (THI) - (854)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 854 (CERT Java Secure Coding Section 09 - Thread APIs (THI))
Weaknesses in this category are related to rules in the Thread APIs (THI) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness VariantWeakness VariantCall to Thread run() instead of start() - (572)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 854 (CERT Java Secure Coding Section 09 - Thread APIs (THI)) > 572 (Call to Thread run() instead of start())
The program 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.
*Weakness ClassWeakness ClassIncorrect Control Flow Scoping - (705)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 854 (CERT Java Secure Coding Section 09 - Thread APIs (THI)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
+CategoryCategoryCERT Java Secure Coding Section 10 - Thread Pools (TPS) - (855)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS))
Weaknesses in this category are related to rules in the Thread Pools (TPS) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseInsufficient Resource Pool - (410)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS)) > 410 (Insufficient Resource Pool)
The software'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.
*Weakness BaseWeakness BaseMissing Report of Error Condition - (392)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS)) > 392 (Missing Report of Error Condition)
The software encounters an error but does not provide a status code or return value to indicate that an error has occurred.
*Weakness ClassWeakness ClassAsymmetric Resource Consumption (Amplification) - (405)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS)) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*CategoryCategoryCERT Java Secure Coding Section 11 - Thread-Safety Miscellaneous (TSM) - (856)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 856 (CERT Java Secure Coding Section 11 - Thread-Safety Miscellaneous (TSM))
Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+CategoryCategoryCERT Java Secure Coding Section 12 - Input Output (FIO) - (857)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO))
Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness ClassWeakness ClassAsymmetric Resource Consumption (Amplification) - (405)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*Weakness ClassWeakness ClassExposure of Private Information ('Privacy Violation') - (359)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 359 (Exposure of Private Information ('Privacy Violation'))
The software does not properly prevent private data (such as credit card numbers) from being accessed by actors who either (1) are not explicitly authorized to access the data or (2) do not have the implicit consent of the people to which the data is related. Privacy leakPrivacy leakage
*Weakness VariantWeakness VariantImproper Handling of Windows Device Names - (67)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 67 (Improper Handling of Windows Device Names)
The software 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.
*Weakness BaseWeakness BaseImproper Resource Shutdown or Release - (404)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 404 (Improper Resource Shutdown or Release)
The program does not release or incorrectly releases a resource before it is made available for re-use.
*Weakness BaseWeakness BaseIncomplete Cleanup - (459)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 459 (Incomplete Cleanup)
The software does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup
*Weakness BaseWeakness BaseIncorrect Calculation of Multi-Byte String Length - (135)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 135 (Incorrect Calculation of Multi-Byte String Length)
The software does not correctly calculate the length of strings that can contain wide or multi-byte characters.
*Weakness VariantWeakness VariantIncorrect Default Permissions - (276)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 276 (Incorrect Default Permissions)
The software, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
*Weakness VariantWeakness VariantIncorrect Execution-Assigned Permissions - (279)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the software sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
*Weakness VariantWeakness VariantInformation Exposure Through Cleanup Log Files - (542)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 542 (Information Exposure Through Cleanup Log Files)
The application does not properly protect or delete a log file related to cleanup.
*Weakness VariantWeakness VariantInformation Exposure Through Log Files - (532)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 532 (Information Exposure Through Log Files)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*Weakness VariantWeakness VariantInformation Exposure Through Server Log Files - (533)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 533 (Information Exposure Through Server Log Files)
A server.log file was found. This can give information on whatever application left the file. Usually this can give full path names and system information, and sometimes usernames and passwords.
*Weakness BaseWeakness BaseInsecure Temporary File - (377)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 377 (Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
*Weakness BaseWeakness BaseUse of Incorrect Byte Ordering - (198)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 198 (Use of Incorrect Byte Ordering)
The software 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.
*Weakness BaseWeakness BaseAllocation of Resources Without Limits or Throttling - (770)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
*Weakness ClassWeakness ClassIncorrect Permission Assignment for Critical Resource - (732)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategoryCERT Java Secure Coding Section 13 - Serialization (SER) - (858)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER))
Weaknesses in this category are related to rules in the Serialization (SER) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness VariantWeakness VariantDeserialization of Untrusted Data - (502)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 502 (Deserialization of Untrusted Data)
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, Unpickling
*Weakness ClassWeakness ClassExecution with Unnecessary Privileges - (250)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 250 (Execution with Unnecessary Privileges)
The software 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.
*Weakness VariantWeakness VariantSerializable Class Containing Sensitive Data - (499)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 499 (Serializable Class Containing Sensitive Data)
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.
*Weakness BaseWeakness BaseUncontrolled Resource Consumption ('Resource Exhaustion') - (400)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion'))
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
*Weakness BaseWeakness BaseAllocation of Resources Without Limits or Throttling - (770)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
*Weakness VariantWeakness VariantCall to Non-ubiquitous API - (589)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 589 (Call to Non-ubiquitous API)
The software 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.
*Weakness BaseWeakness BaseCleartext Transmission of Sensitive Information - (319)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 319 (Cleartext Transmission of Sensitive Information)
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+CategoryCategoryCERT Java Secure Coding Section 14 - Platform Security (SEC) - (859)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC))
Weaknesses in this category are related to rules in the Platform Security (SEC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness VariantWeakness VariantAuthentication Bypass by Assumed-Immutable Data - (302)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 302 (Authentication Bypass by Assumed-Immutable Data)
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
*Weakness ClassWeakness ClassChannel Accessible by Non-Endpoint ('Man-in-the-Middle') - (300)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle'))
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.
*Weakness BaseWeakness BaseCleartext Transmission of Sensitive Information - (319)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 319 (Cleartext Transmission of Sensitive Information)
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
*Weakness BaseWeakness BaseDirect Use of Unsafe JNI - (111)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - 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.
*Weakness BaseWeakness BaseDownload of Code Without Integrity Check - (494)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 494 (Download of Code Without Integrity Check)
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.
*Weakness BaseWeakness BaseImproper Verification of Cryptographic Signature - (347)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 347 (Improper Verification of Cryptographic Signature)
The software does not verify, or incorrectly verifies, the cryptographic signature for data.
*Weakness BaseWeakness BaseIncorrect Privilege Assignment - (266)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 266 (Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
*Weakness BaseWeakness BaseLeast Privilege Violation - (272)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
*Weakness BaseWeakness BaseReliance on Untrusted Inputs in a Security Decision - (807)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 807 (Reliance on Untrusted Inputs in a Security Decision)
The application 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.
*Weakness BaseWeakness BaseUse of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))
The application 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
*Weakness ClassWeakness ClassIncorrect Permission Assignment for Critical Resource - (732)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategoryCERT Java Secure Coding Section 15 - Runtime Environment (ENV) - (860)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 860 (CERT Java Secure Coding Section 15 - Runtime Environment (ENV))
Weaknesses in this category are related to rules in the Runtime Environment (ENV) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseAcceptance of Extraneous Untrusted Data With Trusted Data - (349)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 860 (CERT Java Secure Coding Section 15 - Runtime Environment (ENV)) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The software, 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.
*Weakness ClassWeakness ClassIncorrect Permission Assignment for Critical Resource - (732)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 860 (CERT Java Secure Coding Section 15 - Runtime Environment (ENV)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategoryCERT Java Secure Coding Section 49 - Miscellaneous (MSC) - (861)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC))
Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*Weakness BaseWeakness BaseAllocation of Resources Without Limits or Throttling - (770)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
*Weakness VariantWeakness VariantImproper Handling of Insufficient Entropy in TRNG - (333)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 333 (Improper Handling of Insufficient Entropy in TRNG)
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
*Weakness BaseWeakness BaseImproper Release of Memory Before Removing Last Reference ('Memory Leak') - (401)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 401 (Improper Release of Memory Before Removing Last Reference ('Memory Leak'))
The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak
*Weakness VariantWeakness VariantInsufficient Entropy in PRNG - (332)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
*Weakness BaseWeakness BaseMissing Encryption of Sensitive Data - (311)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 311 (Missing Encryption of Sensitive Data)
The software does not encrypt sensitive or critical information before storage or transmission.
*Weakness BaseWeakness BasePredictable Seed in PRNG - (337)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 337 (Predictable Seed in PRNG)
A PRNG is initialized from a predictable seed, e.g. using process ID or system time.
*Weakness BaseWeakness BaseSame Seed in PRNG - (336)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 336 (Same Seed in PRNG)
A PRNG uses the same seed each time the product is initialized. If an attacker can guess (or knows) the seed, then he/she may be able to determine the "random" number produced from the PRNG.
*Weakness BaseWeakness BaseUse of Hard-coded Credentials - (798)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 798 (Use of Hard-coded Credentials)
The software 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.
*Weakness BaseWeakness BaseUse of Hard-coded Password - (259)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 259 (Use of Hard-coded Password)
The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
*Weakness ClassWeakness ClassUse of Insufficiently Random Values - (330)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 330 (Use of Insufficiently Random Values)
The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
*Weakness VariantWeakness VariantUse of Singleton Pattern Without Synchronization in a Multithreaded Context - (543)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 543 (Use of Singleton Pattern Without Synchronization in a Multithreaded Context)
The software uses the singleton pattern when creating a resource within a multithreaded environment.
*Weakness BaseWeakness BaseUncontrolled Resource Consumption ('Resource Exhaustion') - (400)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion'))
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
+ Relationship Notes

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
+ View Metrics
CWEs in this viewTotal CWEs
Total124out of1005
Views0out of33
Categories18out of244
Weaknesses105out of720
Compound_Elements1out of8
View Components
View Components
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

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

Weakness ID: 349
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software, 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.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control
Integrity

Technical Impact: Bypass protection mechanism; Modify application data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.

+ Observed Examples
ReferenceDescription
Does not verify that trusted entity is authoritative for all entities in its response.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class345Insufficient Verification of Data Authenticity
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory860CERT Java Secure Coding Section 15 - Runtime Environment (ENV)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUntrusted Data Appended with Trusted Data
CERT Java Secure CodingENV01-JPlace all security-sensitive code in a single JAR and sign and seal it
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Untrusted Data Appended with Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
  • System Configuration
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
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

Medium to High

+ 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 software 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 software 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.

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Languages: C and 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 Languages: C and 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 Languages: C and 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 Languages: C and 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:

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>.
+ Observed Examples
ReferenceDescription
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
+ 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 whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

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, he 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: Limit Resource Consumption

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Development Concepts (primary)699
Research Concepts1000
ChildOfWeakness ClassWeakness Class665Improper Initialization
Research Concepts (primary)1000
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory840Business Logic Errors
Development Concepts699
ChildOfCategoryCategory857CERT Java Secure Coding Section 12 - Input Output (FIO)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory861CERT Java Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory877CERT C++ Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory985SFP Secondary Cluster: Unrestricted Consumption
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant774Allocation of File Descriptors or Handles Without Limits or Throttling
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant789Uncontrolled Memory Allocation
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Theoretical Notes

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 NameNode IDFitMapped Node Name
CERT Java Secure CodingFIO04-JClose resources when they are no longer needed
CERT Java Secure CodingSER12-JAvoid memory and resource leaks during serialization
CERT Java Secure CodingMSC05-JDo not exhaust heap space
CERT C++ Secure CodingMEM12-CPPDo not assume infinite heap space
CERT C++ Secure CodingFIO42-CPPEnsure files are properly closed when they are no longer needed
+ References
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). November 2008. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.
Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft. 2002.
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-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574.. 1st Edition. Addison Wesley. 2006.
+ Maintenance Notes

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-05-13Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-07-27CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2009-10-29CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2010-02-16CWE Content TeamMITREInternal
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Detection_Factors, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Related_Attack_Patterns

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

Weakness ID: 582
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

+ Demonstrative Examples

Example 1

The following Java Applet code mistakenly declares an array public, final and static.

(Bad Code)
Example Language: Java 
public final class urlTool extends Applet {
public final static URL[] urls;
...
}
+ Potential Mitigations

Phase: Implementation

In most situations the array should be made private.

+ Background Details

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory490Mobile Code Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts (primary)1000
ChildOfCategoryCategory849CERT Java Secure Coding Section 04 - Object Orientation (OBJ)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory1002SFP Secondary Cluster: Unexpected Entry Points
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingOBJ10-JDo not use public static nonfinal variables
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Background_Details, Demonstrative_Examples, Description, Other_Notes
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Unsafe Array Declaration

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Abstraction: Class
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.

Extended Description

This situation is amplified if the software allows malicious users or attackers to consume more resources than their access level permits. Exploiting such a weakness can lead to asymmetric resource consumption, aiding in amplification attacks against the system or the network.

+ Time of Introduction
  • Operation
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: amplification; DoS: resource consumption (other)

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory855CERT Java Secure Coding Section 10 - Thread Pools (TPS)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory857CERT Java Secure Coding Section 12 - Input Output (FIO)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base406Insufficient Control of Network Message Volume (Network Amplification)
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base407Algorithmic Complexity
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base408Incorrect Behavior Order: Early Amplification
Development Concepts (primary)699
Research Concepts1000
ParentOfWeakness BaseWeakness Base409Improper Handling of Highly Compressed Data (Data Amplification)
Development Concepts (primary)699
Research Concepts (primary)1000
PeerOfWeakness BaseWeakness Base404Improper Resource Shutdown or Release
Research Concepts1000
+ Functional Areas
  • Non-specific
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAsymmetric resource consumption (amplification)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
WASC41XML Attribute Blowup
CERT Java Secure CodingTPS00-JUse thread pools to enable graceful degradation of service during traffic bursts
CERT Java Secure CodingFIO04-JRelease resources when they are no longer needed
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-07-27CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software 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.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Observed Examples
ReferenceDescription
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class592Authentication Bypass Issues
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory947SFP Secondary Cluster: Authentication Bypass
Software Fault Pattern (SFP) Clusters (primary)888
CanFollowWeakness VariantWeakness Variant46Path Equivalence: 'filename ' (Trailing Space)
Research Concepts1000
CanFollowWeakness VariantWeakness Variant52Path Equivalence: '/multiple/trailing/slash//'
Research Concepts1000
CanFollowCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Research Concepts1000
CanFollowWeakness VariantWeakness Variant173Improper Handling of Alternate Encoding
Research Concepts1000
CanFollowWeakness BaseWeakness Base178Improper Handling of Case Sensitivity
Research Concepts1000
+ Relationship Notes

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

+ Theoretical Notes

Alternate names are useful in data driven manipulation attacks, not just for authentication.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by alternate name
CERT Java Secure CodingIDS01-JNormalize strings before validating them
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Observed_Examples
2009-07-27CWE Content TeamMITREInternal
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Demonstrative Examples

Example 1

In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.

(Bad Code)
Example Language: Java 
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) {
...
}

Of course, modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.

+ Observed Examples
ReferenceDescription
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class592Authentication Bypass Issues
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base807Reliance on Untrusted Inputs in a Security Decision
Research Concepts1000
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory949SFP Secondary Cluster: Faulty Endpoint Authentication
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
CERT Java Secure CodingSEC02-JDo not base security checks on untrusted sources
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships

CWE-589: Call to Non-ubiquitous API

Weakness ID: 589
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Some functions that offer security features supported by the OS are not available on all versions of the OS in common use. Likewise, functions are often deprecated or made obsolete for security reasons and should not be used.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Common Consequences
ScopeEffect
Other

Technical Impact: Quality degradation

+ Potential Mitigations

Phase: Implementation

Always test your code on any platform on which it is targeted to run on.

Phase: Testing

Test your code on the newest and oldest platform on which it is targeted to run on.

Phase: Testing

Develop a system to test for API functions that are not portable.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class227Improper Fulfillment of API Contract ('API Abuse')
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base474Use of Function with Inconsistent Implementations
Research Concepts (primary)1000
ChildOfCategoryCategory850CERT Java Secure Coding Section 05 - Methods (MET)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory1001SFP Secondary Cluster: Use of an Improper API
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingMET02-JDo not use deprecated or obsolete classes or methods
CERT Java Secure CodingSER00-JMaintain serialization compatibility during class evolution
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-07-27CWE Content TeamMITREInternal
updated Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Limited API

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

Weakness ID: 572
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

+ Common Consequences
ScopeEffect
Other

Technical Impact: Quality degradation; Varies by context

+ Demonstrative Examples

Example 1

The following excerpt from a Java program mistakenly calls run() instead of start().

(Bad Code)
Example Language: Java 
Thread thr = new Thread() {
public void run() {
...
}
};

thr.run();
+ Potential Mitigations

Phase: Implementation

Use the start() method instead of the run() method.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory557Concurrency Issues
Development Concepts699
ChildOfCategoryCategory634Weaknesses that Affect System Processes
Resource-specific Weaknesses (primary)631
ChildOfWeakness BaseWeakness Base821Incorrect Synchronization
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory854CERT Java Secure Coding Section 09 - Thread APIs (THI)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory1001SFP Secondary Cluster: Use of an Improper API
Software Fault Pattern (SFP) Clusters (primary)888
+ Affected Resources
  • System Process
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingTHI00-JDo not invoke Thread.run()
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Description, Other_Notes
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Thread.run()

CWE CATEGORY: CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)

Category ID: 845
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Input Validation and Data Sanitization section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class116Improper Encoding or Escaping of Output
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base134Use of Externally-Controlled Format String
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant144Improper Neutralization of Line Delimiters
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant150Improper Neutralization of Escape, Meta, or Control Sequences
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base180Incorrect Behavior Order: Validate Before Canonicalize
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base182Collapse of Data into Unsafe Value
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant289Authentication Bypass by Alternate Name
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base409Improper Handling of Highly Compressed Data (Data Amplification)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base625Permissive Regular Expression
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant647Use of Non-Canonical URL Paths for Authorization Decisions
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base838Inappropriate Encoding for Output Context
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 01 - Declarations and Initialization (DCL)

Category ID: 846
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness ClassWeakness Class665Improper Initialization
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 02 - Expressions (EXP)

Category ID: 847
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base252Unchecked Return Value
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant479Signal Handler Use of a Non-reentrant Function
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base595Comparison of Object References Instead of Object Contents
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant597Use of Wrong Operator in String Comparison
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)

Category ID: 848
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base197Numeric Truncation Error
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base369Divide By Zero
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base681Incorrect Conversion between Numeric Types
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 04 - Object Orientation (OBJ)

Category ID: 849
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Object Orientation (OBJ) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base374Passing Mutable Objects to an Untrusted Method
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base375Returning a Mutable Object to an Untrusted Caller
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant486Comparison of Classes by Name
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant491Public cloneable() Method Without Final ('Object Hijack')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant492Use of Inner Class Containing Sensitive Data
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant493Critical Public Variable Without Final Modifier
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant498Cloneable Class Containing Sensitive Information
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant500Public Static Field Not Marked Final
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant582Array Declared Public, Final, and Static
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant766Critical Variable Declared Public
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 05 - Methods (MET)

Category ID: 850
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Methods (MET) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness VariantWeakness Variant487Reliance on Package-level Scope
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant568finalize() Method Without super.finalize()
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class573Improper Following of Specification by Caller
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base581Object Model Violation: Just One of Equals and Hashcode Defined
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant583finalize() Method Declared Public
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant586Explicit Call to Finalize()
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant589Call to Non-ubiquitous API
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant617Reachable Assertion
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)

Category ID: 851
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base209Information Exposure Through an Error Message
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant230Improper Handling of Missing Values
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant232Improper Handling of Undefined Values
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base248Uncaught Exception
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant382J2EE Bad Practices: Use of System.exit()
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class390Detection of Error Condition Without Action
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base395Use of NullPointerException Catch to Detect NULL Pointer Dereference
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base397Declaration of Throws for Generic Exception
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant460Improper Cleanup on Thrown Exception
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant497Exposure of System Data to an Unauthorized Control Sphere
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base584Return Inside Finally Block
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base600Uncaught Exception in Servlet
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfCompound Element: ChainCompound Element: Chain690Unchecked Return Value to NULL Pointer Dereference
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class703Improper Check or Handling of Exceptional Conditions
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class705Incorrect Control Flow Scoping
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)

Category ID: 852
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness ClassWeakness Class362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base366Race Condition within a Thread
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base413Improper Resource Locking
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base567Unsynchronized Access to Shared Data in a Multithreaded Context
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base662Improper Synchronization
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base667Improper Locking
Weaknesses Addressed by the CERT Java Secure Coding Standard844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 08 - Locking (LCK)

Category ID: 853
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Locking (LCK) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base412Unrestricted Externally Accessible Lock
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base413Improper Resource Locking
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base609Double-Checked Locking
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base667Improper Locking
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base820Missing Synchronization
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base833Deadlock
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 09 - Thread APIs (THI)

Category ID: 854
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Thread APIs (THI) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness VariantWeakness Variant572Call to Thread run() instead of start()
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class705Incorrect Control Flow Scoping
Weaknesses Addressed by the CERT Java Secure Coding Standard844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 10 - Thread Pools (TPS)

Category ID: 855
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Thread Pools (TPS) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base392Missing Report of Error Condition
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class405Asymmetric Resource Consumption (Amplification)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base410Insufficient Resource Pool
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 11 - Thread-Safety Miscellaneous (TSM)

Category ID: 856
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 12 - Input Output (FIO)

Category ID: 857
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness VariantWeakness Variant67Improper Handling of Windows Device Names
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base135Incorrect Calculation of Multi-Byte String Length
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base198Use of Incorrect Byte Ordering
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant276Incorrect Default Permissions
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant279Incorrect Execution-Assigned Permissions
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class359Exposure of Private Information ('Privacy Violation')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base377Insecure Temporary File
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base404Improper Resource Shutdown or Release
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class405Asymmetric Resource Consumption (Amplification)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base459Incomplete Cleanup
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant532Information Exposure Through Log Files
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant533Information Exposure Through Server Log Files
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant542Information Exposure Through Cleanup Log Files
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base770Allocation of Resources Without Limits or Throttling
Weaknesses Addressed by the CERT Java Secure Coding Standard844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 13 - Serialization (SER)

Category ID: 858
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Serialization (SER) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness ClassWeakness Class250Execution with Unnecessary Privileges
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base319Cleartext Transmission of Sensitive Information
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant499Serializable Class Containing Sensitive Data
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant502Deserialization of Untrusted Data
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant589Call to Non-ubiquitous API
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base770Allocation of Resources Without Limits or Throttling
Weaknesses Addressed by the CERT Java Secure Coding Standard844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team

CWE CATEGORY: CERT Java Secure Coding Section 14 - Platform Security (SEC)

Category ID: 859
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Platform Security (SEC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base111Direct Use of Unsafe JNI
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base266Incorrect Privilege Assignment
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base272Least Privilege Violation
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class300Channel Accessible by Non-Endpoint ('Man-in-the-Middle')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant302Authentication Bypass by Assumed-Immutable Data
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base319Cleartext Transmission of Sensitive Information
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base347Improper Verification of Cryptographic Signature
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base494Download of Code Without Integrity Check
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base807Reliance on Untrusted Inputs in a Security Decision
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2011-09-13CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 15 - Runtime Environment (ENV)

Category ID: 860
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Runtime Environment (ENV) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base349Acceptance of Extraneous Untrusted Data With Trusted Data
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2011-09-13CWE Content TeamMITREInternal
updated Relationships
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 49 - Miscellaneous (MSC)

Category ID: 861
Status: Incomplete
+ Description

Description Summary

Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfWeakness BaseWeakness Base259Use of Hard-coded Password
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base311Missing Encryption of Sensitive Data
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness ClassWeakness Class330Use of Insufficiently Random Values
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant332Insufficient Entropy in PRNG
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant333Improper Handling of Insufficient Entropy in TRNG
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base336Same Seed in PRNG
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base337Predictable Seed in PRNG
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ParentOfWeakness BaseWeakness Base401Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness VariantWeakness Variant543Use of Singleton Pattern Without Synchronization in a Multithreaded Context
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base770Allocation of Resources Without Limits or Throttling
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ParentOfWeakness BaseWeakness Base798Use of Hard-coded Credentials
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
MemberOfViewView844Weaknesses Addressed by the CERT Java Secure Coding Standard
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated Relationships

CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')

Weakness ID: 300
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

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.

Extended Description

In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Inadequate or inconsistent verification may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Access Control

Technical Impact: Read application data; Modify application data; Gain privileges / assume identity

An attacker could pose as one of the entities and read or possibly modify the communication.

+ Demonstrative Examples

Example 1

In the Java snippet below, data is sent over an unencrypted channel to a remote server.

(Bad Code)
Example Language: Java 
Socket sock;
PrintWriter out;

try {
sock = new Socket(REMOTE_HOST, REMOTE_PORT);
out = new PrintWriter(echoSocket.getOutputStream(), true);

// Write data to remote host via socket output stream.
...
}

By eavesdropping on the communication channel or posing as the endpoint, an attacker would be able to read all of the transmitted data.

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing man-in-the-middle attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle')).
+ Potential Mitigations

Phase: Implementation

Always fully authenticate both ends of any communications channel.

Phase: Architecture and Design

Adhere to the principle of complete mediation.

Phase: Implementation

A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory956SFP Secondary Cluster: Channel Attack
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base602Client-Side Enforcement of Server-Side Security
Research Concepts1000
PeerOfWeakness BaseWeakness Base603Use of Client-Side Authentication
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMan-in-the-middle (MITM)
WASC32Routing Detour
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
+ References
M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Maintenance Notes

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Name
2010-02-16CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Relationships
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Man-in-the-middle (MITM)
2009-05-27Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')

CWE CATEGORY: Cleansing, Canonicalization, and Comparison Errors

Category ID: 171
Status: Draft
+ Description

Description Summary

Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
+ Applicable Platforms

Languages

Language-independent

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory137Representation Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
CanPrecedeWeakness VariantWeakness Variant289Authentication Bypass by Alternate Name
Research Concepts1000
ParentOfWeakness ClassWeakness Class172Encoding Error
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base178Improper Handling of Case Sensitivity
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base179Incorrect Behavior Order: Early Validation
Development Concepts699
ParentOfWeakness BaseWeakness Base180Incorrect Behavior Order: Validate Before Canonicalize
Development Concepts699
ParentOfWeakness BaseWeakness Base181Incorrect Behavior Order: Validate Before Filter
Development Concepts699
ParentOfWeakness BaseWeakness Base182Collapse of Data into Unsafe Value
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base183Permissive Whitelist
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base184Incomplete Blacklist
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class185Incorrect Regular Expression
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base187Partial Comparison
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant478Missing Default Case in Switch Statement
Development Concepts699
ParentOfWeakness VariantWeakness Variant486Comparison of Classes by Name
Development Concepts699
ParentOfWeakness BaseWeakness Base595Comparison of Object References Instead of Object Contents
Development Concepts699
ParentOfWeakness BaseWeakness Base596Incorrect Semantic Object Comparison
Development Concepts699
ParentOfWeakness ClassWeakness Class697Insufficient Comparison
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class707Improper Enforcement of Message or Data Structure
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant768Incorrect Short Circuit Evaluation
Development Concepts (primary)699
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCleansing, Canonicalization, and Comparison Errors
CERT Java Secure CodingIDS02-JCanonicalize path names before validating them
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms
2011-06-01CWE Content TeamMITREInternal
updated Description, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software 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" by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.

+ Time of Introduction
  • Architecture and Design
  • Operation
  • System Configuration
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
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

Medium to High

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

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

+ Observed Examples
ReferenceDescription
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Potential Mitigations

Phase: Architecture and Design

Encrypt the data with a reliable encryption scheme before transmitting.

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base311Missing Encryption of Sensitive Data
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory818OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2013)928
ChildOfCategoryCategory934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant5J2EE Misconfiguration: Data Transmission Without Encryption
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
CERT Java Secure CodingSER02-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
+ References
OWASP. "Top 10 2007-Insecure Communications". <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft. 2002.
[REF-17] 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-33] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITREInternal
updated References
2010-04-05CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITREInternal
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

CWE-498: Cloneable Class Containing Sensitive Information

Weakness ID: 498
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Cloneable classes are effectively open classes, since data cannot be hidden in them. Classes that do not explicitly deny cloning can be cloned by any other class without running the constructor.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C++

Java

.NET

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

A class that can be cloned can be produced without executing the constructor. This is dangerous since the constructor may perform security-related checks. By allowing the object to be cloned, those checks may be bypassed.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

(Bad Code)
Example Language: Java 
public class CloneClient {
public CloneClient() //throws
java.lang.CloneNotSupportedException {

Teacher t1 = new Teacher("guddu","22,nagar road");
//...
// Do some stuff to remove the teacher.
Teacher t2 = (Teacher)t1.clone();
System.out.println(t2.name);
}
public static void main(String args[]) {

new CloneClient();
}
}
class Teacher implements Cloneable {

public Object clone() {

try {
return super.clone();
}
catch (java.lang.CloneNotSupportedException e) {

throw new RuntimeException(e.toString());
}
}
public String name;
public String clas;
public Teacher(String name,String clas) {

this.name = name;
this.clas = clas;
}
}
+ Potential Mitigations

Phase: Implementation

Make classes uncloneable by defining a clone function like:

(Mitigation Code)
Example Language: Java 
public final void clone() throws java.lang.CloneNotSupportedException {
throw new java.lang.CloneNotSupportedException();
}

Phase: Implementation

If you do make your classes clonable, ensure that your clone method is final and throw super.clone().

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory849CERT Java Secure Coding Section 04 - Object Orientation (OBJ)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness ClassWeakness Class200Information Exposure
Development Concepts699
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInformation leak through class cloning
CERT Java Secure CodingOBJ07-JSensitive classes must not let themselves be copied
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Other_Notes
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak through Class Cloning

CWE-182: Collapse of Data into Unsafe Value

Weakness ID: 182
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Observed Examples
ReferenceDescription
"/.////" in pathname collapses to absolute path.
"/.//..//////././" is collapsed into "/.././" after ".." and "//" sequences are removed.
".../...//" collapsed to "..." due to removal of "./" in web server.
chain: HTTP server protects against ".." but allows "." variants such as "////./../.../". If the server removes "/.." sequences, the result would collapse into an unsafe value "////../" (CWE-182).
MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../".
XSS protection mechanism strips a <script> sequence that is nested in another <script> sequence.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.

Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory992SFP Secondary Cluster: Faulty Input Transformation
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness VariantWeakness Variant33Path Traversal: '....' (Multiple Dot)
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant34Path Traversal: '....//'
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant35Path Traversal: '.../...//'
Research Concepts1000
CanFollowWeakness ClassWeakness Class185Incorrect Regular Expression
Research Concepts1000
+ Relationship Notes

Overlaps regular expressions, although an implementation might not necessarily use regexp's.

+ Relevant Properties
  • Trustability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCollapse of Data into Unsafe Value
CERT Java Secure CodingIDS11-JEliminate noncharacter code points before validation
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Stripping Vulnerabilities", Page 437.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Observed_Examples
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Description, Observed_Examples
2010-12-13CWE Content TeamMITREInternal
updated Relationships
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-486: Comparison of Classes by Name

Weakness ID: 486
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

If a program relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names.

(Bad Code)
Example Language: Java 
if (inputClass.getClass().getName().equals("TrustedClassName")) {
// Do something assuming you trust inputClass
// ...
}

However, multiple classes can have the same name therefore comparing an object's class by name can allow untrusted classes of the same name as the trusted class to be use to execute unintended or incorrect code. To compare the class of an object to the intended class the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.

(Good Code)
Example Language: Java 
if (inputClass.getClass() == TrustedClass.class) {
// Do something assuming you trust inputClass
// ...
}

Example 2

In this example, the Java class, TrustedClass, overrides the equals method of the parent class Object to determine equivalence of objects of the class. The overridden equals method first determines if the object, obj, is the same class as the TrustedClass object and then compares the object's fields to determine if the objects are equivalent.

(Bad Code)
Example Language: Java 
public class TrustedClass {
...

@Override
public boolean equals(Object obj) {
boolean isEquals = false;

// first check to see if the object is of the same class
if (obj.getClass().getName().equals(this.getClass().getName())) {

// then compare object fields
...
if (...) {
isEquals = true;
}
}

return isEquals;
}

...
}

However, the equals method compares the class names of the object, obj, and the TrustedClass object to determine if they are the same class. As with the previous example using the name of the class to compare the class of objects can lead to the execution of unintended or incorrect code if the object passed to the equals method is of another class with the same name. To compare the class of an object to the intended class, the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.

(Good Code)
Example Language: Java 
public boolean equals(Object obj) {
...

// first check to see if the object is of the same class
if (obj.getClass() == this.getClass()) {
...
}

...
}
+ Potential Mitigations

Phase: Implementation

Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts699
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
Research Concepts1000
ChildOfWeakness ClassWeakness Class697Insufficient Comparison
Research Concepts (primary)1000
ChildOfCategoryCategory849CERT Java Secure Coding Section 04 - Object Orientation (OBJ)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base386Symbolic Name not Mapping to Correct Object
Research Concepts1000
+ Relevant Properties
  • Equivalence
  • Uniqueness
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsComparing Classes by Name
CLASPComparing classes by name
CERT Java Secure CodingOBJ09-JCompare classes and not class names
Software Fault PatternsSFP1Glitch in computation
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Other_Notes
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Comparing Classes by Name

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

Weakness ID: 595
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

Language-independent

+ Common Consequences
ScopeEffect
Other

Technical Impact: Other; Varies by context

This weakness can lead to erroneous results that can cause unexpected application behaviors.

+ Demonstrative Examples

Example 1

In the example below, two Java String objects are declared and initialized with the same string values and an if statement is used to determine if the strings are equivalent.

(Bad Code)
Example Language: Java 
String str1 = new String("Hello");
String str2 = new String("Hello");
if (str1 == str2) {
System.out.println("str1 == str2");
}

However, the if statement will not be executed as the strings are compared using the "==" operator. For Java objects, such as String objects, the "==" operator compares object references, not object values. While the two String objects above contain the same string values, they refer to different object references, so the System.out.println statement will not be executed. To compare object values, the previous code could be modified to use the equals method:

(Good Code)
 
if (str1.equals(str2)) {
System.out.println("str1 equals str2");
}

Example 2

In the following Java example, two BankAccount objects are compared in the isSameAccount method using the == operator.

(Bad Code)
Example Language: Java 
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA == accountB;
}

Using the == operator to compare objects may produce incorrect or deceptive results by comparing object references rather than values. The equals() method should be used to ensure correct results or objects should contain a member variable that uniquely identifies the object.

The following example shows the use of the equals() method to compare the BankAccount objects and the next example uses a class get method to retrieve the bank account number that uniquely identifies the BankAccount object to compare the objects.

(Good Code)
Example Language: Java 
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA.equals(accountB);
}
+ Potential Mitigations

Phase: Implementation

Use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor.

+ Other Notes

This problem can cause unexpected application behavior. Comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values. To use == on a string, the programmer has to make sure that these objects are unique in the program, that is, that they don't have the equals method defined or have a static factory that produces unique objects.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts699
ChildOfCategoryCategory569Expression Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class697Insufficient Comparison
Research Concepts (primary)1000
ChildOfCategoryCategory847CERT Java Secure Coding Section 02 - Expressions (EXP)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant597Use of Wrong Operator in String Comparison
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingEXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
CERT Java Secure CodingEXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
CERT Java Secure CodingEXP03-JDo not use the equality operators when comparing values of boxed primitives
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Other_Notes
2009-05-27CWE Content TeamMITREInternal
updated Name
2010-12-13CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Incorrect Object Comparison: Syntactic
2009-05-27Incorrect Syntactic Object Comparison

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

Weakness ID: 362
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

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 program; 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 program.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

Java: (Sometimes)

Language-independent

Architectural Paradigms

Concurrent Systems Operating on Shared Resources: (Often)

+ Common Consequences
ScopeEffect
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 / restart; DoS: instability

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the program(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

+ 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 / 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: SOAR 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: SOAR 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: SOAR 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: SOAR High

Architecture / 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: SOAR High

+ 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)
Example Language: 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:
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 it to higher levels.

(Good Code)
 
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);
}
+ Observed Examples
ReferenceDescription
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
+ 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 [R.362.11]. 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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class691Insufficient Control Flow Management
Research Concepts (primary)1000
ChildOfCategoryCategory743CERT C Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory852CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory877CERT C++ Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory882CERT C++ Secure Coding Section 14 - Concurrency (CON)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory988SFP Secondary Cluster: Race Condition Window
Software Fault Pattern (SFP) Clusters (primary)888
RequiredByCompound Element: CompositeCompound Element: Composite61UNIX Symbolic Link (Symlink) Following
Research Concepts1000
RequiredByCompound Element: CompositeCompound Element: Composite689Permission Race Condition During Resource Copy
Research Concepts1000
ParentOfWeakness BaseWeakness Base364Signal Handler Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base366Race Condition within a Thread
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base367Time-of-check Time-of-use (TOCTOU) Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base368Context Switching Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base421Race Condition During Access to Alternate Channel
Development Concepts699
Research Concepts1000
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
CanFollowWeakness BaseWeakness Base662Improper Synchronization
Development Concepts699
Research Concepts1000
CanAlsoBeCategoryCategory557Concurrency Issues
Research Concepts1000
+ Research Gaps

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

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.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
CERT C Secure CodingFIO31-CDo not simultaneously open the same file multiple times
CERT Java Secure CodingVNA03-JDo not assume that a group of calls to independently atomic methods is atomic
CERT C++ Secure CodingFIO31-CPPDo not simultaneously open the same file multiple times
CERT C++ Secure CodingCON02-CPPUse lock classes for mutex management
+ References
[R.362.1] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[R.362.2] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <http://www.ddj.com/cpp/184403766>.
[R.362.3] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.
[R.362.4] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.
[R.362.5] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". September 1995. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.
[R.362.6] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.
[R.362.7] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". April 2002. <http://www.blakewatts.com/namedpipepaper.html>.
[R.362.8] 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>.
[R.362.9] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.
[R.362.10] 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/>.
[R.362.11] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
+ Maintenance Notes

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Contributions
Contribution DateContributorOrganizationSource
2010-04-30Martin SeborCisco Systems, Inc. Content
Provided Demonstrative Example
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

CWE-493: Critical Public Variable Without Final Modifier

Weakness ID: 493
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

If a field is non-final and public, it can be changed once the value is set by any function that has access to the class which contains the field. This could lead to a vulnerability if other parts of the program make assumptions about the contents of that field.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

C++

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

The object could potentially be tampered with.

Confidentiality

Technical Impact: Read application data

The object could potentially allow the object to be read.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

Suppose this WidgetData class is used for an e-commerce web site. The programmer attempts to prevent price-tampering attacks by setting the price of the widget using the constructor.

(Bad Code)
Example Language: Java 
public final class WidgetData extends Applet {
public float price;
...
public WidgetData(...) {
this.price = LookupPrice("MyWidgetType");
}
}

The price field is not final. Even though the value is set by the constructor, it could be modified by anybody that has access to an instance of WidgetData.

Example 2

Assume the following code is intended to provide the location of a configuration file that controls execution of the application.

(Bad Code)
Example Language: C++ 
public string configPath = "/etc/application/config.dat";
(Bad Code)
Example Language: Java 
public String configPath = new String("/etc/application/config.dat");

While this field is readable from any function, and thus might allow an information leak of a pathname, a more serious problem is that it can be changed by any function.

+ Potential Mitigations

Phase: Implementation

Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.

+ Background Details

Mobile code, such as a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class216Containment Errors (Container Errors)
Research Concepts1000
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory490Mobile Code Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts (primary)1000
ChildOfCategoryCategory849CERT Java Secure Coding Section 04 - Object Orientation (OBJ)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory1002SFP Secondary Cluster: Unexpected Entry Points
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant500Public Static Field Not Marked Final
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsMobile Code: Non-Final Public Field
CLASPFailure to provide confidentiality for stored data
CERT Java Secure CodingOBJ10-JDo not use public static nonfinal variables
Software Fault PatternsSFP28Unexpected access points
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Likelihood_of_Exploit, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Background_Details, Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Background_Details, Demonstrative_Examples, Description, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Non-final Public Field

CWE-766: Critical Variable Declared Public

Weakness ID: 766
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software declares a critical variable or field to be public when intended security policy requires it to be private.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C++

C#

Java

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Technical Impact: Read application data; Modify application data

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

+ Likelihood of Exploit

Low to Medium

+ Demonstrative Examples

Example 1

The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.

(Bad Code)
Example Language: C++ 
public: char* password;

Instead, the critical data should be declared private.

(Good Code)
Example Language: C++ 
private: char* password;

Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (CWE-257).

Example 2

The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.

(Bad Code)
Example Language: C++ 
#define MAX_PASSWORD_LENGTH 15
#define MAX_USERNAME_LENGTH 15

class UserAccount
{
public:
UserAccount(char *username, char *password)
{
if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {
ExitError("Invalid username or password");
}
strcpy(this->username, username);
strcpy(this->password, password);
}

int authorizeAccess(char *username, char *password)
{
if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {
ExitError("Invalid username or password");
}
// if the username and password in the input parameters are equal to
// the username and password of this account class then authorize access
if (strcmp(this->username, username) ||
strcmp(this->password, password))
return 0;
// otherwise do not authorize access
else
return 1;
}

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];
};

However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.

(Good Code)
Example Language: C++ 
class UserAccount
{
public:
...

private:
char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];
};
+ Observed Examples
ReferenceDescription
variables declared public allows remote read of system properties such as user name and home directory.
+ Potential Mitigations

Phase: Implementation

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Research Concepts1000
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts (primary)1000
ChildOfCategoryCategory849CERT Java Secure Coding Section 04 - Object Orientation (OBJ)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory1002SFP Secondary Cluster: Unexpected Entry Points
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
CERT Java Secure CodingOBJ01-JDeclare data members as private and provide accessible wrapper methods
Software Fault PatternsSFP28Unexpected access points
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-03-03Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-12-28CWE Content TeamMITREInternal
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITREInternal
updated Observed_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-833: Deadlock

Weakness ID: 833
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (CPU); DoS: resource consumption (other); DoS: crash / exit / restart

Each thread of execution will "hang" and prevent tasks from completing. In some cases, CPU consumption may occur if a lock check occurs in a tight loop.

+ Observed Examples
ReferenceDescription
OS deadlock
OS deadlock involving 3 separate functions
deadlock in library
deadlock triggered by packets that force collisions in a routing table
read/write deadlock between web server and script
web server deadlock involving multiple listening connections
multiple simultaneous calls to the same function trigger deadlock.
chain: other weakness leads to NULL pointer dereference (CWE-476) or deadlock (CWE-833).
deadlock when an operation is performed on a resource while it is being removed.
Deadlock in device driver triggered by using file handle of a related device.
Deadlock when large number of small messages cannot be processed quickly enough.
OS kernel has deadlock triggered by a signal during a core dump.
Race condition leads to deadlock.
Chain: array index error (CWE-129) leads to deadlock (CWE-833)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base667Improper Locking
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory853CERT Java Secure Coding Section 08 - Locking (LCK)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingLCK08-JEnsure actively held locks are released on exceptional conditions
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Synchronization Problems" / "Starvation and Deadlocks", Page 760. 1st Edition. Addison Wesley. 2006.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Starvation and Deadlocks", Page 760.. 1st Edition. Addison Wesley. 2006.
[REF-19] Robert C. Seacord. "Secure Coding in C and C++". Chapter 7, "Concurrency", section "Mutual Exclusion and Deadlock", Page 248.. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2010-12-12MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References

CWE-397: Declaration of Throws for Generic Exception

Weakness ID: 397
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Declaring a method to throw Exception or Throwable makes it difficult for callers to perform proper error handling and error recovery. Java's exception mechanism, for example, is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C++

Java

.NET

+ Common Consequences
ScopeEffect
Non-Repudiation
Other

Technical Impact: Hide activities; Alter execution logic

+ Demonstrative Examples

Example 1

The following method throws three types of exceptions.

(Good Code)
Example Language: Java 
public void doExchange() throws IOException, InvocationTargetException, SQLException {
...
}

While it might seem tidier to write

(Bad Code)
 
public void doExchange() throws Exception {
...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class221Information Loss or Omission
Research Concepts1000
ChildOfCategoryCategory388Error Handling
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory389Error Conditions, Return Values, Status Codes
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class703Improper Check or Handling of Exceptional Conditions
Research Concepts1000
ChildOfWeakness ClassWeakness Class705Incorrect Control Flow Scoping
Research Concepts (primary)1000
ChildOfCategoryCategory851CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory960SFP Secondary Cluster: Ambiguous Exception Type
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Throws Declaration
CERT Java Secure CodingERR07-JDo not throw RuntimeException, Exception, or Throwable
Software Fault PatternsSFP5Ambiguous Exception Type
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITREInternal
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITREInternal
updated Applicable_Platforms
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Throws Declaration

CWE-502: Deserialization of Untrusted Data

Weakness ID: 502
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

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

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Java

Ruby

PHP

Python

Language-independent

+ Common Consequences
ScopeEffect

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.

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.

Authorization
Other

Technical Impact: Other

Code could potentially make the assumption that information in the deserialized object is valid. Functions that make this dangerous assumption could be exploited.

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

+ Observed Examples
ReferenceDescription
Deserialization issue in commonly-used Java library allows remote execution.
Deserialization issue in commonly-used Java library allows remote execution.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Python script allows local users to execute code via pickled data.
Unsafe deserialization using pickle in a Python script.
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 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"); }

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.

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfWeakness ClassWeakness Class913Improper Control of Dynamically-Managed Code Resources
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory994SFP Secondary Cluster: Tainted Input to Variable
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base915Improperly Controlled Modification of Dynamically-Determined Object Attributes
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeserialization of untrusted data
CERT Java Secure CodingSER01-JDo not deviate from the proper signatures of serialization methods
CERT Java Secure CodingSER03-JDo not serialize unencrypted, sensitive data
CERT Java Secure CodingSER06-JMake defensive copies of private mutable components during deserialization
CERT Java Secure CodingSER08-JDo not use the default serialized form for implementation defined invariants
Software Fault PatternsSFP25Tainted input to variable
+ References
Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <http://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>.
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>.
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>.
Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <http://heine.familiedeelstra.com/security/unserialize>.
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>.
Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://nadiana.com/python-pickle-insecure>.
+ Maintenance Notes

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Observed_Examples, References, Relationships

CWE-390: Detection of Error Condition Without Action

Weakness ID: 390
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software detects a specific error, but takes no actions to handle the error.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity
Other

Technical Impact: Varies by context; Unexpected state; Alter execution logic

An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.

(Bad Code)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
//We do nothing so we just ignore the error.
}

The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.

Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code.

(Good Code)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
printf("Malloc failed to allocate memory resources");
return -1;
}

Example 2

In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed.

(Bad Code)
Example Language: C++ 
char* readfile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {
throw "Unable to open file " + filename;
}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {
throw "Unable to read from file " + filename;
}

infile.close();

return buffer;
}
catch (...) {
/* bug: insert code to handle this later */
}
}

The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following C++ example contains two catch statements. The first of these will catch a specific error thrown within the try block, and the second catch statement will catch all other errors from within the catch block. Both catch statements will notify the user that an error has occurred, close the file, and rethrow to the block that called the readFile() method for further handling or possible termination of the program.

(Good Code)
Example Language: C++ 
char* readFile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {
throw "Unable to open file " + filename;
}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {
throw "Unable to read from file " + filename;
}
infile.close();

return buffer;
}
catch (char *str) {
printf("Error: %s \n", str);
infile.close();
throw str;
}
catch (...) {
printf("Error occurred trying to read from file \n");
infile.close();
throw;
}
}

Example 3

In the following Java example the method readFile will read the file whose name is provided in the input parameter and will return the contents of the file in a String object. The constructor of the FileReader object and the read method call may throw exceptions and therefore must be within a try/catch block. While the catch statement in this example will catch thrown exceptions in order for the method to compile, no processing is performed to handle the thrown exceptions. Catch statements that do not perform any processing will have unexpected results. In this case, this will result in the return of a null String.

(Bad Code)
Example Language: Java 
public String readFile(String filename) {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char[] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (Exception ex) {
/* do nothing, but catch so it'll compile... */
}
return retString;
}

The catch statement should contain statements that either attempt to fix the problem, notify the user that an exception has been raised and continue processing, or perform some cleanup and gracefully terminate the program. The following Java example contains three catch statements. The first of these will catch the FileNotFoundException that may be thrown by the FileReader constructor called within the try/catch block. The second catch statement will catch the IOException that may be thrown by the read method called within the try/catch block. The third catch statement will catch all other exceptions thrown within the try block. For all catch statements the user is notified that the exception has been thrown and the exception is rethrown to the block that called the readFile() method for further processing or possible termination of the program. Note that with Java it is usually good practice to use the getMessage() method of the exception class to provide more information to the user about the exception raised.

(Good Code)
Example Language: Java 
public String readFile(String filename) throws FileNotFoundException, IOException, Exception {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char [] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (FileNotFoundException ex) {
System.err.println ("Error: FileNotFoundException opening the input file: " + filename );
System.err.println ("" + ex.getMessage() );
throw new FileNotFoundException(ex.getMessage());
} catch (IOException ex) {
System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() );
throw new IOException(ex);
} catch (Exception ex) {
System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() );
throw new Exception(ex);
}
return retString;
}
+ Potential Mitigations

Phase: Implementation

Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Phase: Implementation

If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.

Phase: Testing

Subject the software to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory389Error Conditions, Return Values, Status Codes
Development Concepts (primary)699
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts (primary)1000
ChildOfCategoryCategory851CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory962SFP Secondary Cluster: Unchecked Status Condition
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base401Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base600Uncaught Exception in Servlet
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant81Improper Neutralization of Script in an Error Message Web Page
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPImproper error handling
CERT Java Secure CodingERR00-JDo not suppress or ignore checked exceptions
CERT C++ Secure CodingERR39-CPPGuarantee exception safety
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Error Handling

CWE-111: Direct Use of Unsafe JNI

Weakness ID: 111
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

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.

Extended Description

Many safety features that programmers may take for granted simply do not apply for native code, so you must carefully review all such code for potential problems. The languages used to implement native code may be more susceptible to buffer overflows and other attacks. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Demonstrative Examples

Example 1

The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. The following C code defines the native method implemented in the Echo class:

(Bad Code)
Example Language: Java 
class Echo {

public native void runEcho();
static {

System.loadLibrary("echo");
}
public static void main(String[] args) {

new Echo().runEcho();
}
}
(Bad Code)
Example Language:
#include <jni.h>
#include "Echo.h"//the java class above compiled with javah
#include <stdio.h>

JNIEXPORT void JNICALL
Java_Echo_runEcho(JNIEnv *env, jobject obj)
{
char buf[64];
gets(buf);
printf(buf);
}

Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not check the length of its input.

The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.

The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information exposure in the Java application that reveals its use of JNI [See Reference].

+ Potential Mitigations

Phase: Implementation

Implement error handling around the JNI call.

Phases: Architecture and Design; Implementation

Strategy: Refactoring

Do not use JNI calls if you don't trust the native library.

Phases: Architecture and Design; Implementation

Strategy: Refactoring

Be reluctant to use JNI calls. A Java API equivalent may exist.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness BaseWeakness Base695Use of Low-Level Functionality
Research Concepts (primary)1000
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory1001SFP Secondary Cluster: Use of an Improper API
Software Fault Pattern (SFP) Clusters (primary)888
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnsafe JNI
CERT Java Secure CodingSEC08-JDefine wrappers around native methods
Software Fault PatternsSFP3Use of an improper API
+ References
Fortify Software. "Fortify Descriptions". <http://vulncat.fortifysoftware.com>.
B. Stearns. "The Java(TM) Tutorial: The Java Native Interface". Sun Microsystems. 2005. <http://java.sun.com/docs/books/tutorial/native1.1/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Description, Other_Notes
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe JNI

CWE-369: Divide By Zero

Weakness ID: 369
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product divides a value by zero.

Extended Description

This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.

+ Time of Introduction
  • Implementation
+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: crash / exit / restart

A Divide by Zero results in a crash.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.

(Bad Code)
Example Language: Java 
public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.

(Good Code)
 
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) {
System.out.println("Division by zero attempted!");
throw ArithmeticException;
}
return totalTime / numRequests;
}

Example 2

The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(Bad Code)
Example Languages: C and C++ 
double divide(double x, double y){
return x/y;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.

(Good Code)
 
const int DivideByZero = 10;
double divide(double x, double y){
if ( 0 == y ){
throw DivideByZero;
}
return x/y;
}
...
try{
divide(10, 0);
}
catch( int i ){
if(i==DivideByZero) {
cerr<<"Divide by zero error";
}
}

Example 3

The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(Bad Code)
Example Language: C# 
int Division(int x, int y){
return (x / y);
}

The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero.

(Good Code)
 
int SafeDivision(int x, int y){
try{
return (x / y);
}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero attempted!");
return 0;
}
}

Example 3 References:

+ Observed Examples
ReferenceDescription
Invalid size value leads to divide by zero.
"Empty" content triggers divide by zero.
Height value of 0 triggers divide by zero.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class682Incorrect Calculation
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory738CERT C Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory739CERT C Secure Coding Section 05 - Floating Point (FLP)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory848CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory872CERT C++ Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFLP03-CDetect and handle floating point errors
CERT C Secure CodingINT33-CEnsure that division and modulo operations do not result in divide-by-zero errors
CERT Java Secure CodingNUM02-JEnsure that division and modulo operations do not result in divide-by-zero errors
CERT C++ Secure CodingINT33-CPPEnsure that division and modulo operations do not result in divide-by-zero errors
CERT C++ Secure CodingFLP03-CPPDetect and handle floating point errors
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-609: Double-Checked Locking

Weakness ID: 609
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

+ Common Consequences
ScopeEffect
Integrity
Other

Technical Impact: Modify application data; Alter execution logic

+ Demonstrative Examples

Example 1

It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization...

(Bad Code)
Example Language: Java 
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;

The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.

Suppose that helper is not initialized. Then, thread A sees that helper==null and enters the synchronized block and begins to execute:

(Bad Code)
 
helper = new Helper();

If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values.

+ Potential Mitigations

Phase: Implementation

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base667Improper Locking
Research Concepts (primary)1000
ChildOfCategoryCategory853CERT Java Secure Coding Section 08 - Locking (LCK)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory986SFP Secondary Cluster: Missing Lock
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base367Time-of-check Time-of-use (TOCTOU) Race Condition
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingLCK10-JDo not use incorrect forms of the double-checked locking idiom
Software Fault PatternsSFP19Missing Lock
+ References
David Bacon et al. "The "Double-Checked Locking is Broken" Declaration". <http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html>.
Jeremy Manson and Brian Goetz. "JSR 133 (Java Memory Model) FAQ". <http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl>.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Threading Vulnerabilities", Page 815.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Context_Notes
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-01-12CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Double Checked Locking

CWE-494: Download of Code Without Integrity Check

Weakness ID: 494
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

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.

Extended Description

An attacker can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
Integrity
Availability
Confidentiality
Other

Technical Impact: Execute unauthorized code or commands; Alter execution logic; Other

Executing untrusted code could compromise the control flow of the program. The untrusted code could execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users.

+ Likelihood of Exploit

Medium

+ Detection Methods

Manual Analysis

This weakness can be detected using 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.

Specifically, manual static analysis is typically required to find the behavior that triggers the download of code, and to determine whether integrity-checking methods are in use.

These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

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 and also sniff the network connection. Trigger features related to product updates or plugin installation, which is likely to force a code download. Monitor when files are downloaded and separately executed, or if they are otherwise read back into the process. Look for evidence of cryptographic library calls that use integrity checking.

+ Demonstrative Examples

Example 1

This example loads an external class from a local subdirectory.

(Bad Code)
Example Language: Java 
URL[] classURLs= new URL[]{
new URL("file:subdir/")
};
URLClassLoader loader = new URLClassLoader(classURLs);
Class loadedClass = Class.forName("loadMe", true, loader);

This code does not ensure that the class loaded is the intended one, for example by verifying the class's checksum. An attacker may be able to modify the class file to execute malicious code.

Example 2

This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application.

(Bad Code)
Example Language: PHP 
//assume the password is already encrypted, avoiding CWE-312
function authenticate($username,$password){
include("http://external.example.com/dbInfo.php");
//dbInfo.php makes $dbhost, $dbuser, $dbpass, $dbname available
mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql');
mysql_select_db($dbname);
$query = 'Select * from users where username='.$username.' And password='.$password;
$result = mysql_query($query);
if(mysql_numrows($result) == 1){
mysql_close();
return true;
}
else{
mysql_close();
return false;
}
}

This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow himself to access the application without a real user account.

This example is also vulnerable to a Man in the Middle (CWE-300) attack.

+ Observed Examples
ReferenceDescription
OS does not verify authenticity of its own updates.
online poker client does not verify authenticity of its own updates.
anti-virus product does not verify automatic updates for itself.
VOIP phone downloads applications from web sites without verifying integrity.
+ Potential Mitigations

Phase: Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.

This is only a partial solution since it will not prevent your code from being modified on the hosting site or in transit.

Phases: Architecture and Design; Operation

Encrypt the code with a reliable encryption scheme before transmitting.

This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code.

  • When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses.

  • Use code signing technologies such as Authenticode. See references [R.494.1] [R.494.2] [R.494.3].

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.494.7]. 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.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory490Mobile Code Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class669Incorrect Resource Transfer Between Spheres
Research Concepts (primary)1000
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8652011 Top 25 - Risky Resource Management
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory991SFP Secondary Cluster: Tainted Input to Environment
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Research Concepts1000
+ Research Gaps

This is critical for mobile code, but it is likely to become more and more common as developers continue to adopt automated, network-based product distributions and upgrades. Software-as-a-Service (SaaS) might introduce additional subtleties. Common exploitation scenarios may include ad server compromises and bad upgrades.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInvoking untrusted mobile code
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
Software Fault PatternsSFP27Tainted input to environment
+ References
[R.494.1] Microsoft. "Introduction to Code Signing". <http://msdn.microsoft.com/en-us/library/ms537361(VS.85).aspx>.
[R.494.3] Apple. "Code Signing Guide". Apple Developer Connection. 2008-11-19. <http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Introduction/chapter_1_section_1.html>.
[R.494.4] Anthony Bellissimo, John Burgess and Kevin Fu. "Secure Software Updates: Disappointments and New Challenges". <http://prisms.cs.umass.edu/~kevinfu/papers/secureupdates-hotsec06.pdf>.
[R.494.5] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 18: The Sins of Mobile Code." Page 267. McGraw-Hill. 2010.
[R.494.6] Johannes Ullrich. "Top 25 Series - Rank 20 - Download of Code Without Integrity Check". SANS Software Security Institute. 2010-04-05. <http://blogs.sans.org/appsecstreetfighter/2010/04/05/top-25-series-rank-20-download-code-integrity-check/>.
[R.494.7] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Name, Other_Notes, Potential_Mitigations, References, Relationships, Research_Gaps, Type
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-07-27CWE Content TeamMITREInternal
updated Description, Observed_Examples, Related_Attack_Patterns
2010-02-16CWE Content TeamMITREInternal
updated Detection_Factors, References, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Applicable_Platforms
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Invoking Untrusted Mobile Code
2009-01-12Download of Untrusted Mobile Code Without Integrity Check

CWE-250: Execution with Unnecessary Privileges

Weakness ID: 250
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges.

Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges.

+ Time of Introduction
  • Installation
  • Architecture and Design
  • Operation
+ Applicable Platforms

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Modes of Introduction

If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe.

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Gain privileges / assume identity; Execute unauthorized code or commands; Read application data; DoS: crash / exit / restart

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.

+ Likelihood of Exploit

Medium

+ Detection Methods

Manual Analysis

This weakness can be detected using 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.

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 and perform a login. Look for library functions and system calls that indicate when privileges are being raised or dropped. Look for accesses of resources that are restricted to normal users.

Note that this technique is only useful for privilege issues related to system resources. It is not likely to detect application-level business rules that are related to privileges, such as if a blog system allows a user to delete a blog entry without first checking that the user has administrator privileges.

Automated Static Analysis - Binary / Bytecode

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

Highly cost effective:

  • Compare binary / bytecode to application permission manifest

Cost effective for partial coverage:

  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis

  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR High

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Host-based Vulnerability Scanners – Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Cost effective for partial coverage:

  • Host Application Interface Scanner

Effectiveness: SOAR Partial

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: SOAR High

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:

  • Configuration Checker

  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Architecture / Design Review

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

Highly cost effective:

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

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

  • Attack Modeling

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

This code temporarily raises the program's privileges to allow creation of a new user folder.

(Bad Code)
Example Language: Python 
def makeNewUserDir(username):
if invalidUsername(username):
#avoid CWE-22 and CWE-78
print('Usernames cannot contain invalid characters')
return False
try:
raisePrivileges()
os.mkdir('/home/' + username)
lowerPrivileges()
except OSError:
print('Unable to create new user directory for user:' + username)
return False
return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.

Example 2

The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.

(Bad Code)
Example Language:
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...

Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.

Example 3

This application intends to use a user's location to determine the timezone the user is in:

(Bad Code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
setTimeZone(userCurrLocation);

This is unnecessary use of the location API, as this information is already available using the Android Time API. Always be sure there is not another way to obtain needed information before resorting to using the location API.

Example 4

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(Bad Code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(Bad Code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information,