CWE - VIEW SLICE: CWE-1340: CISQ Data Protection Measures (4.13)

CWE VIEW: CISQ Data Protection Measures

View ID: 1340

Type: Graph

Downloads: Booklet | CSV | XML

Objective

This view outlines the SMM representation of the Automated Source Code Data Protection Measurement specifications, as identified by the Consortium for Information & Software Quality (CISQ) Working Group.

Audience

Stakeholder	Description
Software Developers	This view provides a good starting point for anyone involved in software development (including architects, designers, coders, and testers) to ensure that code quality issues are considered during the development process.
Product Vendors	This view can help product vendors understand code quality issues and convey an overall status of their software.
Assessment Tool Vendors	This view provides a good starting point for assessment tool vendors (e.g., vendors selling static analysis tools) who wish to understand what constitutes software with good code quality, and which quality issues may be of concern.

Relationships

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

Show Details:

Expand All | Collapse All

1340 - CISQ Data Protection Measures

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

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.Buffer Overflowbuffer overrunmemory safety

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))

The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.Classic Buffer OverflowUnbounded Transfer

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 123 (Write-what-where Condition)

Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 125 (Out-of-bounds Read)

The product reads data past the end, or before the beginning, of the intended buffer.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Handling of Length Parameter Inconsistency - (130)

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 130 (Improper Handling of Length Parameter Inconsistency)

The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.length manipulationlength tampering

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Access of Memory Location Before Start of Buffer - (786)

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 786 (Access of Memory Location Before Start of Buffer)

The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 787 (Out-of-bounds Write)

The product writes data past the end, or before the beginning, of the intended buffer.Memory Corruption

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Access of Memory Location After End of Buffer - (788)

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 788 (Access of Memory Location After End of Buffer)

The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 805 (Buffer Access with Incorrect Length Value)

The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 822 (Untrusted Pointer Dereference)

The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 823 (Use of Out-of-range Pointer Offset)

The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer.Untrusted pointer offset

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 824 (Access of Uninitialized Pointer)

The product accesses or uses a pointer that has not been initialized.

1340 (CISQ Data Protection Measures) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 825 (Expired Pointer Dereference)

The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.Dangling pointer

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Operation on a Resource after Expiration or Release - (672)

1340 (CISQ Data Protection Measures) > 672 (Operation on a Resource after Expiration or Release)

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

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

1340 (CISQ Data Protection Measures) > 672 (Operation on a Resource after Expiration or Release) > 415 (Double Free)

The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free

1340 (CISQ Data Protection Measures) > 672 (Operation on a Resource after Expiration or Release) > 416 (Use After Free)

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Dangling pointerUse-After-Free

1340 (CISQ Data Protection Measures) > 665 (Improper Initialization)

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

1340 (CISQ Data Protection Measures) > 665 (Improper Initialization) > 456 (Missing Initialization of a Variable)

The product does not initialize critical variables, which causes the execution environment to use unexpected values.

1340 (CISQ Data Protection Measures) > 665 (Improper Initialization) > 457 (Use of Uninitialized Variable)

The code uses a variable that has not been initialized, leading to unpredictable or unintended results.

1340 (CISQ Data Protection Measures) > 404 (Improper Resource Shutdown or Release)

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

1340 (CISQ Data Protection Measures) > 404 (Improper Resource Shutdown or Release) > 761 (Free of Pointer not at Start of Buffer)

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

1340 (CISQ Data Protection Measures) > 404 (Improper Resource Shutdown or Release) > 762 (Mismatched Memory Management Routines)

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

1340 (CISQ Data Protection Measures) > 404 (Improper Resource Shutdown or Release) > 763 (Release of Invalid Pointer or Reference)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Release of Resource after Effective Lifetime - (772)

1340 (CISQ Data Protection Measures) > 404 (Improper Resource Shutdown or Release) > 772 (Missing Release of Resource after Effective Lifetime)

The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.

1340 (CISQ Data Protection Measures) > 404 (Improper Resource Shutdown or Release) > 775 (Missing Release of File Descriptor or Handle after Effective Lifetime)

The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of XML External Entity Reference - (611)

1340 (CISQ Data Protection Measures) > 611 (Improper Restriction of XML External Entity Reference)

The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.XXE

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

1340 (CISQ Data Protection Measures) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))

The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.Insecure Direct Object Reference

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Data within XQuery Expressions ('XQuery Injection') - (652)

1340 (CISQ Data Protection Measures) > 652 (Improper Neutralization of Data within XQuery Expressions ('XQuery Injection'))

The product uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Data within XPath Expressions ('XPath Injection') - (643)

1340 (CISQ Data Protection Measures) > 643 (Improper Neutralization of Data within XPath Expressions ('XPath Injection'))

The product uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)

1340 (CISQ Data Protection Measures) > 90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)

1340 (CISQ Data Protection Measures) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))

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

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Neutralization of Special Elements used in a Command ('Command Injection') - (77)

1340 (CISQ Data Protection Measures) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection'))

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

1340 (CISQ Data Protection Measures) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')) > 624 (Executable Regular Expression Error)

The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)

1340 (CISQ Data Protection Measures) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)

1340 (CISQ Data Protection Measures) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))

The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - (917)

1340 (CISQ Data Protection Measures) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')) > 917 (Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'))

The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.EL Injection

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)

1340 (CISQ Data Protection Measures) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))

The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSHTML InjectionCSS

1340 (CISQ Data Protection Measures) > 91 (XML Injection (aka Blind XPath Injection))

The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Initialization with Hard-Coded Network Resource Configuration Data - (1051)

1340 (CISQ Data Protection Measures) > 1051 (Initialization with Hard-Coded Network Resource Configuration Data)

The product initializes data using hard-coded values that act as network resource identifiers.

1340 (CISQ Data Protection Measures) > 424 (Improper Protection of Alternate Path)

The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources.

1340 (CISQ Data Protection Measures) > 798 (Use of Hard-coded Credentials)

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

1340 (CISQ Data Protection Measures) > 798 (Use of Hard-coded Credentials) > 259 (Use of Hard-coded Password)

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

1340 (CISQ Data Protection Measures) > 798 (Use of Hard-coded Credentials) > 321 (Use of Hard-coded Cryptographic Key)

The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.

1340 (CISQ Data Protection Measures) > 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.

1340 (CISQ Data Protection Measures) > 681 (Incorrect Conversion between Numeric Types) > 194 (Unexpected Sign Extension)

The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.

1340 (CISQ Data Protection Measures) > 681 (Incorrect Conversion between Numeric Types) > 195 (Signed to Unsigned Conversion Error)

The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.

1340 (CISQ Data Protection Measures) > 681 (Incorrect Conversion between Numeric Types) > 196 (Unsigned to Signed Conversion Error)

The product uses an unsigned primitive and performs a cast to a signed primitive, which can produce an unexpected value if the value of the unsigned primitive can not be represented using a signed primitive.

1340 (CISQ Data Protection Measures) > 681 (Incorrect Conversion between Numeric Types) > 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.

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element - (1058)

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 1058 (Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element)

The code contains a function or method that operates in a multi-threaded environment but owns an unsafe non-final static storable or member data element.

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 1096 (Singleton Class Instance Creation without Proper Locking or Synchronization)

The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once.

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 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.

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 543 (Use of Singleton Pattern Without Synchronization in a Multithreaded Context)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unsynchronized Access to Shared Data in a Multithreaded Context - (567)

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 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.

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 667 (Improper Locking)

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

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 764 (Multiple Locks of a Critical Resource)

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

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 820 (Missing Synchronization)

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

1340 (CISQ Data Protection Measures) > 662 (Improper Synchronization) > 821 (Incorrect Synchronization)

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

1340 (CISQ Data Protection Measures) > 704 (Incorrect Type Conversion or Cast)

The product does not correctly convert an object, resource, or structure from one type to a different type.

1340 (CISQ Data Protection Measures) > 562 (Return of Stack Variable Address)

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

1340 (CISQ Data Protection Measures) > 170 (Improper Null Termination)

The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

1340 (CISQ Data Protection Measures) > 129 (Improper Validation of Array Index)

The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow

1340 (CISQ Data Protection Measures) > 134 (Use of Externally-Controlled Format String)

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

1340 (CISQ Data Protection Measures) > 606 (Unchecked Input for Loop Condition)

The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)

1340 (CISQ Data Protection Measures) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal

1340 (CISQ Data Protection Measures) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) > 23 (Relative Path Traversal)

The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.Zip Slip

1340 (CISQ Data Protection Measures) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) > 36 (Absolute Path Traversal)

The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unrestricted Upload of File with Dangerous Type - (434)

1340 (CISQ Data Protection Measures) > 434 (Unrestricted Upload of File with Dangerous Type)

The product allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment.Unrestricted File Upload

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

1340 (CISQ Data Protection Measures) > 703 (Improper Check or Handling of Exceptional Conditions)

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

1340 (CISQ Data Protection Measures) > 703 (Improper Check or Handling of Exceptional Conditions) > 248 (Uncaught Exception)

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

1340 (CISQ Data Protection Measures) > 703 (Improper Check or Handling of Exceptional Conditions) > 391 (Unchecked Error Condition)

[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

1340 (CISQ Data Protection Measures) > 703 (Improper Check or Handling of Exceptional Conditions) > 392 (Missing Report of Error Condition)

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

1340 (CISQ Data Protection Measures) > 908 (Use of Uninitialized Resource)

The product uses or accesses a resource that has not been initialized.

1340 (CISQ Data Protection Measures) > 682 (Incorrect Calculation)

The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

1340 (CISQ Data Protection Measures) > 682 (Incorrect Calculation) > 131 (Incorrect Calculation of Buffer Size)

The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.

1340 (CISQ Data Protection Measures) > 682 (Incorrect Calculation) > 369 (Divide By Zero)

The product divides a value by zero.

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Incorrect Permission Assignment for Critical Resource - (732)

1340 (CISQ Data Protection Measures) > 732 (Incorrect Permission Assignment for Critical Resource)

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

1340 (CISQ Data Protection Measures) > 502 (Deserialization of Untrusted Data)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Exposure of Sensitive Information Due to Incompatible Policies - (213)

1340 (CISQ Data Protection Measures) > 213 (Exposure of Sensitive Information Due to Incompatible Policies)

The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improperly Controlled Modification of Dynamically-Determined Object Attributes - (915)

1340 (CISQ Data Protection Measures) > 915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes)

The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.Mass AssignmentAutoBindingPHP Object Injection

1340 (CISQ Data Protection Measures) > 311 (Missing Encryption of Sensitive Data)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Exposure of Private Personal Information to an Unauthorized Actor - (359)

1340 (CISQ Data Protection Measures) > 359 (Exposure of Private Personal Information to an Unauthorized Actor)

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

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control)

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.Authorization

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control) > 285 (Improper Authorization)

The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.AuthZ

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control) > 287 (Improper Authentication)

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.authentificationAuthNAuthC

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Authentication Bypass Using an Alternate Path or Channel - (288)

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control) > 288 (Authentication Bypass Using an Alternate Path or Channel)

A product requires authentication, but the product has an alternate path or channel that does not require authentication.

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

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control) > 639 (Authorization Bypass Through User-Controlled Key)

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.Insecure Direct Object Reference / IDORBroken Object Level Authorization / BOLAHorizontal Authorization

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control) > 862 (Missing Authorization)

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.AuthZ

1340 (CISQ Data Protection Measures) > 284 (Improper Access Control) > 863 (Incorrect Authorization)

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.AuthZ

Vulnerability Mapping Notes

Usage: Prohibited

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.

References

[REF-1157] Consortium for Information & Software Quality (CISQ). "AUTOMATED SOURCE CODE MEASURE FOR DATA PROTECTION". 2020. <https://www.it-cisq.org/automated-source-code-measure-data-protection/index.htm>.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	89	out of	934
Categories	0	out of	374
Views	0	out of	49
Total	89	out of	1357

Content History

Submissions
Submission Date	Submitter	Organization
2020-12-10 (CWE 4.3, 2020-12-10)	CWE Content Team	MITRE
2020-12-10 (CWE 4.3, 2020-12-10)
Modifications
Modification Date	Modifier	Organization
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

View Components

Weakness ID: 36

Abstraction: Base
Structure: Simple

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

Relationships

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

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

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	37	Path Traversal: '/absolute/pathname/here'
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	38	Path Traversal: '\absolute\pathname\here'
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	39	Path Traversal: 'C:dirname'
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	40	Path Traversal: '\\UNC\share\name\' (Windows UNC Share)

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Modes Of Introduction

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

Phase	Note
Implementation

Applicable Platforms

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

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Common Consequences

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

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Execute Unauthorized Code or Commands The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.
Integrity	Technical Impact: Modify Files or Directories The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.
Confidentiality	Technical Impact: Read Files or Directories The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.
Availability	Technical Impact: DoS: Crash, Exit, or Restart The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.

Demonstrative Examples

Example 1

In the example below, the path to a dictionary file is read from a system property and used to initialize a File object.

(bad code)

Example Language: Java

String filename = System.getProperty("com.domain.application.dictionaryFile");
File dictionaryFile = new File(filename);

However, the path is not validated or modified to prevent it from containing relative or absolute path sequences before creating the File object. This allows anyone who can control the system property to determine what file is used. Ideally, the path should be resolved relative to some kind of application or user home directory.

Example 2

This script intends to read a user-supplied file from the current directory. The user inputs the relative path to the file and the script uses Python's os.path.join() function to combine the path to the current working directory with the provided path to the specified file. This results in an absolute path to the desired file. If the file does not exist when the script attempts to read it, an error is printed to the user.

(bad code)

Example Language: Python

import os
import sys
def main():

filename = sys.argv[1]
path = os.path.join(os.getcwd(), filename)
try:

with open(path, 'r') as f:

file_data = f.read()

except FileNotFoundError as e:

print("Error - file not found")

main()

However, if the user supplies an absolute path, the os.path.join() function will discard the path to the current working directory and use only the absolute path provided. For example, if the current working directory is /home/user/documents, but the user inputs /etc/passwd, os.path.join() will use only /etc/passwd, as it is considered an absolute path. In the above scenario, this would cause the script to access and read the /etc/passwd file.

(good code)

Example Language: Python

import os
import sys
def main():

filename = sys.argv[1]
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}")
try:

with open(path, 'r') as f:

file_data = f.read()

except FileNotFoundError as e:

print("Error - file not found")

main()

The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/user/documents, and the user inputs /etc/passwd, the resulting path will be /home/user/documents/etc/passwd. The user is therefore contained within the current working directory as intended.

Observed Examples

Reference	Description
CVE-2022-31503	Python package constructs filenames using an unsafe os.path.join call on untrusted input, allowing absolute path traversal because os.path.join resets the pathname to an absolute path that is specified as part of the input.
CVE-2002-1345	Multiple FTP clients write arbitrary files via absolute paths in server responses
CVE-2001-1269	ZIP file extractor allows full path
CVE-2002-1818	Path traversal using absolute pathname
CVE-2002-1913	Path traversal using absolute pathname
CVE-2005-2147	Path traversal using absolute pathname
CVE-2000-0614	Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.
CVE-1999-1263	Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.
CVE-2003-0753	Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.
CVE-2002-1525	Remote attackers can read arbitrary files via an absolute pathname.
CVE-2001-0038	Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.
CVE-2001-0255	FTP server allows remote attackers to list arbitrary directories by using the "ls" command and including the drive letter name (e.g. C:) in the requested pathname.
CVE-2001-0933	FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.
CVE-2002-0466	Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.
CVE-2002-1483	Remote attackers can read arbitrary files via an HTTP request whose argument is a filename of the form "C:" (Drive letter), "//absolute/path", or ".." .
CVE-2004-2488	FTP server read/access arbitrary files using "C:\" filenames
CVE-2001-0687	FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (\\computername\sharename).

Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

Memberships

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

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	981	SFP Secondary Cluster: Path Traversal
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1404	Comprehensive Categorization: File Handling

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Absolute Path Traversal
Software Fault Patterns	SFP16		Path Traversal

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-597	Absolute Path Traversal

References

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Filenames and Paths", Page 503. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Sean Eidemiller	Cigital
2008-07-01	added/updated demonstrative examples
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Description
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Demonstrative_Examples
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Demonstrative_Examples, Description
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Common_Consequences, Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Demonstrative_Examples, Detection_Factors, Relationships, Time_of_Introduction
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 788

Abstraction: Base
Structure: Simple

View customized information:

Description

The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.

Extended Description

This typically occurs when a pointer or its index is incremented to a position after the buffer; or when pointer arithmetic results in a position after the buffer.

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	121	Stack-based Buffer Overflow
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	122	Heap-based Buffer Overflow
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	126	Buffer Over-read

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Memory For an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.
Integrity Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Integrity	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.

Demonstrative Examples

Example 1

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);

}

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

Example 2

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)

Example Language: C

int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...

}
int main() {

...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...

}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

Example 3

This example applies an encoding procedure to an input string and stores it into a buffer.

(bad code)

Example Language: C

char * copy_input(char *user_supplied_string){

int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){

die("user string too long, die evil hacker!");

}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){

if( '&' == user_supplied_string[i] ){

dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';

}
else if ('<' == user_supplied_string[i] ){

/* encode to < */

}
else dst_buf[dst_index++] = user_supplied_string[i];

}
return dst_buf;

}

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

Example 4

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

(bad code)

Example Language: C

int processMessageFromSocket(int socket) {

int success;

char buffer[BUFFER_SIZE];
char message[MESSAGE_SIZE];

// get message from socket and store into buffer

//Ignoring possibliity that buffer > BUFFER_SIZE
if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {

// place contents of the buffer into message structure
ExMessage *msg = recastBuffer(buffer);

// copy message body into string for processing
int index;
for (index = 0; index < msg->msgLength; index++) {

message[index] = msg->msgBody[index];

}
message[index] = '\0';

// process message
success = processMessage(message);

}
return success;

}

However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).

Observed Examples

Reference	Description
CVE-2009-2550	Classic stack-based buffer overflow in media player using a long entry in a playlist
CVE-2009-2403	Heap-based buffer overflow in media player using a long entry in a playlist
CVE-2009-0689	large precision value in a format string triggers overflow
CVE-2009-0558	attacker-controlled array index leads to code execution
CVE-2008-4113	OS kernel trusts userland-supplied length value, allowing reading of sensitive information
CVE-2007-4268	Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)

Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1129	CISQ Quality Measures (2016) - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Discouraged

(this CWE ID should not be used to map to real-world vulnerabilities)

Reasons: Potential Deprecation, Frequent Misuse

Rationale:

The CWE entry might be misused when lower-level CWE entries might be available. It also overlaps existing CWE entries and might be deprecated in the future.

Comments:

If the "Access" operation is known to be a read or a write, then investigate children of entries such as CWE-787: Out-of-bounds Write and CWE-125: Out-of-bounds Read.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
OMG ASCRM	ASCRM-CWE-788

References

[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-788. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.

Content History

Submissions
Submission Date	Submitter	Organization
2009-10-21 (CWE 1.6, 2009-10-29)	CWE Content Team	MITRE
2009-10-21 (CWE 1.6, 2009-10-29)
Contributions
Contribution Date	Contributor	Organization
2022-02-23	Eric Constantin Brinz	GENIA-SEC IT-Sicherheitsmanagement GmbH
2022-02-23	Suggested corrections to extended description.
Modifications
Modification Date	Modifier	Organization
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Demonstrative_Examples
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Demonstrative_Examples
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Description
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Description
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Common_Consequences, Demonstrative_Examples, Observed_Examples
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated References, Relationships, Taxonomy_Mappings
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Demonstrative_Examples
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Demonstrative_Examples
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Description
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 786

Abstraction: Base
Structure: Simple

View customized information:

Description

The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.

Extended Description

This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	124	Buffer Underwrite ('Buffer Underflow')
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	127	Buffer Under-read

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Memory For an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.
Integrity Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.
Integrity	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy.

Demonstrative Examples

Example 1

In the following C/C++ example, a utility function is used to trim trailing whitespace from a character string. The function copies the input string to a local character string and uses a while statement to remove the trailing whitespace by moving backward through the string and overwriting whitespace with a NUL character.

(bad code)

Example Language: C

char* trimTrailingWhitespace(char *strMessage, int length) {

char *retMessage;
char *message = malloc(sizeof(char)*(length+1));

// copy input string to a temporary string
char message[length+1];
int index;
for (index = 0; index < length; index++) {

message[index] = strMessage[index];

}
message[index] = '\0';

// trim trailing whitespace
int len = index-1;
while (isspace(message[len])) {

message[len] = '\0';
len--;

}

// return string without trailing whitespace
retMessage = message;
return retMessage;

}

However, this function can cause a buffer underwrite if the input character string contains all whitespace. On some systems the while statement will move backwards past the beginning of a character string and will call the isspace() function on an address outside of the bounds of the local buffer.

Example 2

The following example asks a user for an offset into an array to select an item.

(bad code)

Example Language: C

int main (int argc, char **argv) {

char *items[] = {"boat", "car", "truck", "train"};
int index = GetUntrustedOffset();
printf("You selected %s\n", items[index-1]);

}

The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126).

Example 3

The following is an example of code that may result in a buffer underwrite, if find() returns a negative value to indicate that ch is not found in srcBuf:

(bad code)

Example Language: C

int main() {

...
strncpy(destBuf, &srcBuf[find(srcBuf, ch)], 1024);
...

}

If the index to srcBuf is somehow under user control, this is an arbitrary write-what-where condition.

Observed Examples

Reference	Description
CVE-2002-2227	Unchecked length of SSLv2 challenge value leads to buffer underflow.
CVE-2007-4580	Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130)
CVE-2007-1584	Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character.
CVE-2007-0886	Buffer underflow resultant from encoded data that triggers an integer overflow.
CVE-2006-6171	Product sets an incorrect buffer size limit, leading to "off-by-two" buffer underflow.
CVE-2006-4024	Negative value is used in a memcpy() operation, leading to buffer underflow.
CVE-2004-2620	Buffer underflow due to mishandled special characters

Detection Methods

Fuzzing

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1160	SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Discouraged

(this CWE ID should not be used to map to real-world vulnerabilities)

Reasons: Potential Deprecation, Frequent Misuse

Rationale:

The CWE entry might be misused when lower-level CWE entries might be available. It also overlaps existing CWE entries and might be deprecated in the future.

Comments:

If the "Access" operation is known to be a read or a write, then investigate children of entries such as CWE-787: Out-of-bounds Write and CWE-125: Out-of-bounds Read.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	ARR30-C	CWE More Specific	Do not form or use out-of-bounds pointers or array subscripts

Content History

Submissions
Submission Date	Submitter	Organization
2009-10-21 (CWE 1.6, 2009-10-29)	CWE Content Team	MITRE
2009-10-21 (CWE 1.6, 2009-10-29)
Modifications
Modification Date	Modifier	Organization
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Common_Consequences, Demonstrative_Examples, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 824

Abstraction: Base
Structure: Simple

View customized information:

Description

The product accesses or uses a pointer that has not been initialized.

Extended Description

If the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the product to read from or write to unexpected memory locations, leading to a denial of service. If the uninitialized pointer is used as a function call, then arbitrary functions could be invoked. If an attacker can influence the portion of uninitialized memory that is contained in the pointer, this weakness could be leveraged to execute code or perform other attacks.

Depending on memory layout, associated memory management behaviors, and product operation, the attacker might be able to influence the contents of the uninitialized pointer, thus gaining more fine-grained control of the memory location to be accessed.

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	125	Out-of-bounds Read
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	787	Out-of-bounds Write

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	465	Pointer Issues

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

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

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Memory If the uninitialized pointer is used in a read operation, an attacker might be able to read sensitive portions of memory.
Availability	Technical Impact: DoS: Crash, Exit, or Restart If the uninitialized pointer references a memory location that is not accessible to the product, or points to a location that is "malformed" (such as NULL) or larger than expected by a read or write operation, then a crash may occur.
Integrity Confidentiality Availability	Technical Impact: Execute Unauthorized Code or Commands If the uninitialized pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.

Observed Examples

Reference	Description
CVE-2010-0211	chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
CVE-2009-2768	Pointer in structure is not initialized, leading to NULL pointer dereference (CWE-476) and system crash.
CVE-2009-1721	Free of an uninitialized pointer.
CVE-2009-1415	Improper handling of invalid signatures leads to free of invalid pointer.
CVE-2009-0846	Invalid encoding triggers free of uninitialized pointer.
CVE-2009-0040	Crafted PNG image leads to free of uninitialized pointer.
CVE-2008-2934	Crafted GIF image leads to free of uninitialized pointer.
CVE-2007-4682	Access of uninitialized pointer might lead to code execution.
CVE-2007-4639	Step-based manipulation: invocation of debugging function before the primary initialization function leads to access of an uninitialized pointer and code execution.
CVE-2007-4000	Unchecked return values can lead to a write to an uninitialized pointer.
CVE-2007-2442	zero-length input leads to free of uninitialized pointer.
CVE-2007-1213	Crafted font leads to uninitialized function pointer.
CVE-2006-6143	Uninitialized function pointer in freed memory is invoked
CVE-2006-4175	LDAP server mishandles malformed BER queries, leading to free of uninitialized memory
CVE-2006-0054	Firewall can crash with certain ICMP packets that trigger access of an uninitialized pointer.
CVE-2003-1201	LDAP server does not initialize members of structs, which leads to free of uninitialized pointer if an LDAP request fails.

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Terminology

Many weaknesses related to pointer dereferences fall under the general term of "memory corruption" or "memory safety." As of September 2010, there is no commonly-used terminology that covers the lower-level variants.

Maintenance

There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.

References

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2010-09-22 (CWE 1.10, 2010-09-27)	CWE Content Team	MITRE
2010-09-22 (CWE 1.10, 2010-09-27)
Modifications
Modification Date	Modifier	Organization
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Research_Gaps
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Common_Consequences, Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 288

Abstraction: Base
Structure: Simple

View customized information:

Description

A product requires authentication, but the product has an alternate path or channel that does not require authentication.

Relationships

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

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	306	Missing Authentication for Critical Function
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	425	Direct Request ('Forced Browsing')
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1299	Missing Protection Mechanism for Alternate Hardware Interface
PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	420	Unprotected Alternate Channel

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

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control

Modes Of Introduction

Phase	Note
Architecture and Design	COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and Design	This is often seen in web applications that assume that access to a particular CGI program can only be obtained through a "front" screen, when the supporting programs are directly accessible. But this problem is not just in web apps.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Access Control	Technical Impact: Bypass Protection Mechanism

Demonstrative Examples

Example 1

Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not.

Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset).

Though this example is shown in Verilog, it will apply to VHDL as well.

(informative)

Example Language: Verilog

module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out;
input [31:0] data_in, incoming_id, address;
input clk, rst_n;
wire write_auth, addr_auth;
reg [31:0] data_out, acl_oh_allowlist, q;
assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0;
always @*

acl_oh_allowlist <= 32'h8312;

assign addr_auth = (address == 32'hF00) ? 1: 0;
always @ (posedge clk or negedge rst_n)

if (!rst_n)

begin

q <= 32'h0;
data_out <= 32'h0;

end

else

begin

q <= (addr_auth & write_auth) ? data_in: q;
data_out <= q;

end

endmodule

(bad code)

Example Language: Verilog

assign addr_auth = (address == 32'hF00) ? 1: 0;

The bugged line of code is repeated in the Bad example above. Weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME, the address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below.

(good code)

Example Language: Verilog

assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;

Observed Examples

Reference	Description
CVE-2000-1179	Router allows remote attackers to read system logs without authentication by directly connecting to the login screen and typing certain control characters.
CVE-1999-1454	Attackers with physical access to the machine may bypass the password prompt by pressing the ESC (Escape) key.
CVE-1999-1077	OS allows local attackers to bypass the password protection of idled sessions via the programmer's switch or CMD-PWR keyboard sequence, which brings up a debugger that the attacker can use to disable the lock.
CVE-2003-0304	Direct request of installation file allows attacker to create administrator accounts.
CVE-2002-0870	Attackers may gain additional privileges by directly requesting the web management URL.
CVE-2002-0066	Bypass authentication via direct request to named pipe.
CVE-2003-1035	User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing.

Potential Mitigations

Phase: Architecture and Design

Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	721	OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	947	SFP Secondary Cluster: Authentication Bypass
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1353	OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Relationship

overlaps Unprotected Alternate Channel

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Authentication Bypass by Alternate Path/Channel
OWASP Top Ten 2007	A10	CWE More Specific	Failure to Restrict URL Access

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-127	Directory Indexing
CAPEC-665	Exploitation of Thunderbolt Protection Flaws

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Modes_of_Introduction, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Type
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Observed_Examples
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns, Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Related_Attack_Patterns
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Demonstrative_Examples
Previous Entry Names
Change Date	Previous Entry Name
2008-09-09	Authentication Bypass by Alternate Path/Channel

Weakness ID: 639

Abstraction: Base
Structure: Simple

View customized information:

Description

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

Extended Description

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.

For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.

One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.

Alternate Terms

Insecure Direct Object Reference / IDOR:	The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.
Broken Object Level Authorization / BOLA:	BOLA is used in the 2019 OWASP API Security Top 10 and is said to be the same as IDOR.
Horizontal Authorization:	"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	863	Incorrect Authorization
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	566	Authorization Bypass Through User-Controlled SQL Primary Key

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

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

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

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

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

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control

Modes Of Introduction

Phase	Note
Architecture and Design	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Access Control	Technical Impact: Bypass Protection Mechanism Access control checks for specific user data or functionality can be bypassed.
Access Control	Technical Impact: Gain Privileges or Assume Identity Horizontal escalation of privilege is possible (one user can view/modify information of another user).
Access Control	Technical Impact: Gain Privileges or Assume Identity Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.

Likelihood Of Exploit

High

Observed Examples

Reference	Description
CVE-2021-36539	An educational application does not appropriately restrict file IDs to a particular user. The attacker can brute-force guess IDs, indicating IDOR.

Potential Mitigations

Phase: Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Phases: Architecture and Design; Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Phase: Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	715	OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	723	OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	813	OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	932	OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	945	SFP Secondary Cluster: Insecure Resource Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1031	OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1345	OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Content History

Submissions
Submission Date	Submitter	Organization
2008-01-30 (CWE Draft 8, 2008-01-30)	Evgeny Lebanidze	Cigital
2008-01-30 (CWE Draft 8, 2008-01-30)
Modifications
Modification Date	Modifier	Organization
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Relationships, Type
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Description
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Relationships
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Alternate_Terms, Common_Consequences
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Alternate_Terms
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Alternate_Terms
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
Previous Entry Names
Change Date	Previous Entry Name
2011-03-29	Access Control Bypass Through User-Controlled Key

Weakness ID: 805

Abstraction: Base
Structure: Simple

View customized information:

Description

The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.

Extended Description

When the length value exceeds the size of the destination, a buffer overflow could occur.

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	806	Buffer Access Using Size of Source Buffer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	130	Improper Handling of Length Parameter Inconsistency

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Read Memory; Modify Memory; Execute Unauthorized Code or Commands Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.
Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU) Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

}

This function allocates a buffer of 64 bytes to store the hostname under the assumption that the maximum length value of hostname is 64 bytes, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

Example 2

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)

Example Language: C

int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...

}
int main() {

...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...

}

Example 3

In the following example, the source character string is copied to the dest character string using the method strncpy.

(bad code)

Example Language: C

...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(source)-1);
...

However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below.

(good code)

Example Language: C

...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(dest)-1);
...

Example 4

In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file.

(bad code)

Example Language: C

#define LOG_INPUT_SIZE 40

// saves the file name to a log file
int outputFilenameToLog(char *filename, int length) {

int success;

// buffer with size set to maximum size for input to log file
char buf[LOG_INPUT_SIZE];

// copy filename to buffer
strncpy(buf, filename, length);

// save to log file
success = saveToLogFile(buf);

return success;

}

However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below.

(good code)

Example Language: C

...
// copy filename to buffer
strncpy(buf, filename, sizeof(buf)-1);
...

Observed Examples

Reference	Description
CVE-2011-1959	Chain: large length value causes buffer over-read (CWE-126)
CVE-2011-1848	Use of packet length field to make a calculation, then copy into a fixed-size buffer
CVE-2011-0105	Chain: retrieval of length value from an uninitialized memory location
CVE-2011-0606	Crafted length value in document reader leads to buffer overflow
CVE-2011-0651	SSL server overflow when the sum of multiple length fields exceeds a given value
CVE-2010-4156	Language interpreter API function doesn't validate length argument, leading to information exposure

Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

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.

Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

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

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

Double check that the buffer is as large as specified.

When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.

If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

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.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the product 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

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

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses)
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

Automated Dynamic Analysis

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

Effectiveness: Moderate

Note: Without visibility into the code, black box methods may not be able to sufficiently distinguish this weakness from others, requiring manual methods to diagnose the underlying problem.

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	740	CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	874	CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1160	SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	ARR38-C	Imprecise	Guarantee that library functions do not form invalid pointers

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-100	Overflow Buffers
CAPEC-256	SOAP Array Overflow

References

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Why ACLs Are Important" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.

[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. URL validated: 2023-04-07.

[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.

[REF-741] Jason Lam. "Top 25 Series - Rank 12 - Buffer Access with Incorrect Length Value". SANS Software Security Institute. 2010-03-11. <https://web.archive.org/web/20100316043717/http://blogs.sans.org:80/appsecstreetfighter/2010/03/11/top-25-series-rank-12-buffer-access-with-incorrect-length-value/>. URL validated: 2023-04-07.

[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. URL validated: 2023-04-07.

[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.

[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.

[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.

[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.

[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.

[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.

[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.

[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.

[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.

Content History

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

Weakness ID: 120

Abstraction: Base
Structure: Simple

View customized information:

Description

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

Extended Description

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

Alternate Terms

Classic Buffer Overflow:	This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.
Unbounded Transfer

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	785	Use of Path Manipulation Function without Maximum-sized Buffer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	170	Improper Null Termination
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	231	Improper Handling of Extra Values
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	456	Missing Initialization of a Variable
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	123	Write-what-where Condition

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

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

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

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)

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

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.
Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU) Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array.

(bad code)

Example Language: C

char last_name[20];
printf ("Enter your last name: ");
scanf ("%s", last_name);

The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total.

Example 2

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

(bad code)

Example Language: C

void manipulate_string(char * string){

char buf[24];
strcpy(buf, string);
...

}

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.

Example 3

The code below calls the gets() function to read in data from the command line.

(bad code)

Example Language: C

char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...

}

However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

Example 4

In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file.

(bad code)

Example Language: C

...

struct hostent *clienthp;
char hostname[MAX_LEN];

// create server socket, bind to server address and listen on socket
...

// accept client connections and process requests
int count = 0;
for (count = 0; count < MAX_CONNECTIONS; count++) {

int clientlen = sizeof(struct sockaddr_in);
int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen);

if (clientsocket >= 0) {

clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name);
logOutput("Accepted client connection from host ", hostname);

// process client request
...
close(clientsocket);

}

}
close(serversocket);

...

However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.

Observed Examples

Reference	Description
CVE-2000-1094	buffer overflow using command with long argument
CVE-1999-0046	buffer overflow in local program using long environment variable
CVE-2002-1337	buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
CVE-2003-0595	By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
CVE-2001-0191	By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.

Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

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.

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

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

Phase: Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

Double check that your buffer is as large as you specify.

When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.

If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Architecture and Design

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Phase: Operation

Strategy: Environment Hardening

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Phases: Build and Compilation; Operation

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

Phase: Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses)
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

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.

Manual Analysis

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or 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:

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:

Cost effective for partial coverage:

Fuzz Tester

Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Highly cost effective:

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

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

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

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

Effectiveness: High

Functional Areas

Memory Management

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	722	OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	726	OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	741	CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	865	2011 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	875	CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	970	SFP Secondary Cluster: Faulty Buffer Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1129	CISQ Quality Measures (2016) - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1131	CISQ Quality Measures (2016) - Security
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1161	SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Allowed-with-Review

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Frequent Misuse

Rationale:

There are some indications that this CWE ID might be misused and selected simply because it mentions "buffer overflow" - an increasingly vague term. This CWE entry is only appropriate for "Buffer Copy" operations (not buffer reads), in which where there is no "Checking [the] Size of Input", and (by implication of the copy) writing past the end of the buffer.

Comments:

If the vulnerability being analyzed involves out-of-bounds reads, then consider CWE-125 or descendants. For root cause analysis: if there is any input validation, consider children of CWE-20 such as CWE-1284. If there is a calculation error for buffer sizes, consider CWE-131 or similar.

Notes

Relationship

At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Unbounded Transfer ('classic overflow')
7 Pernicious Kingdoms			Buffer Overflow
CLASP			Buffer overflow
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input
OWASP Top Ten 2004	A5	CWE More Specific	Buffer Overflows
CERT C Secure Coding	STR31-C	Exact	Guarantee that storage for strings has sufficient space for character data and the null terminator
WASC	7		Buffer Overflow
Software Fault Patterns	SFP8		Faulty Buffer Access
OMG ASCSM	ASCSM-CWE-120
OMG ASCRM	ASCRM-CWE-120

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-10	Buffer Overflow via Environment Variables
CAPEC-100	Overflow Buffers
CAPEC-14	Client-side Injection-induced Buffer Overflow
CAPEC-24	Filter Failure through Buffer Overflow
CAPEC-42	MIME Conversion
CAPEC-44	Overflow Binary Resource File
CAPEC-45	Buffer Overflow via Symbolic Links
CAPEC-46	Overflow Variables and Tags
CAPEC-47	Buffer Overflow via Parameter Expansion
CAPEC-67	String Format Overflow in syslog()
CAPEC-8	Buffer Overflow in an API Call
CAPEC-9	Buffer Overflow in Local Command-Line Utilities
CAPEC-92	Forced Integer Overflow

References

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.

[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.

[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. URL validated: 2023-04-07.

[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.

[REF-74] Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.

[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.

[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.

[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.

[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.

[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.

[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.

[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.

[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10	CWE Content Team	MITRE
2008-10-10	Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Description
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations, References
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated References, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences, Potential_Mitigations
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Alternate_Terms, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Demonstrative_Examples, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Potential_Mitigations
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Common_Consequences, Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Potential_Mitigations, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2008-10-14	Unbounded Transfer ('Classic Buffer Overflow')

Weakness ID: 502

Abstraction: Base
Structure: Simple

View customized information:

Description

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

Extended Description

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

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

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

Alternate Terms

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

Relationships

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

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

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

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

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

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

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

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

Background Details

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

Modes Of Introduction

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

Applicable Platforms

Languages

Java (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

Common Consequences

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

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

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

(bad code)

Example Language: Java

try {

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

}

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

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

(good code)

Example Language: Java

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

Example 2

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

(bad code)

Example Language: Python

try {

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

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

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

}

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

Observed Examples

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

Potential Mitigations

Phases: Architecture and Design; Implementation

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

Phase: Implementation

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

Phase: Implementation

Explicitly define a final object() to prevent deserialization.

Phases: Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

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

Phase: Implementation

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

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

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Maintenance

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

Taxonomy Mappings

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

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-586	Object Injection

References

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

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

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

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

[REF-464] Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <https://drupalsun.com/heine/2010/08/25/unserializing-user-supplied-data-bad-idea>. URL validated: 2023-04-07.

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

[REF-466] Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://michael-rushanan.blogspot.com/2012/10/why-python-pickle-is-insecure.html>. URL validated: 2023-04-07.

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

[REF-468] Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21. <https://speakerdeck.com/frohoff/owasp-sd-deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>. URL validated: 2023-04-07.

Content History

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

Weakness ID: 369

Abstraction: Base
Structure: Simple

View customized information:

Description

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.

Relationships

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

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	682	Incorrect Calculation

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

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

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

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	682	Incorrect Calculation

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	682	Incorrect Calculation

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	682	Incorrect Calculation

Modes Of Introduction

Phase	Note
Implementation

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Crash, Exit, or 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 Language: 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 2 References:

[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <https://www.cprogramming.com/tutorial/exceptions.html>. URL validated: 2023-04-07.

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:

[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.

Observed Examples

Reference	Description
CVE-2007-3268	Invalid size value leads to divide by zero.
CVE-2007-2723	"Empty" content triggers divide by zero.
CVE-2007-2237	Height value of 0 triggers divide by zero.

Detection Methods

Automated Static Analysis

Effectiveness: High

Fuzzing

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	730	OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	738	CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	739	CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	848	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	872	CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	873	CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1137	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1158	SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1408	Comprehensive Categorization: Incorrect Calculation

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
OWASP Top Ten 2004	A9	CWE More Specific	Denial of Service
CERT C Secure Coding	FLP03-C		Detect and handle floating point errors
CERT C Secure Coding	INT33-C	Exact	Ensure that division and remainder operations do not result in divide-by-zero errors
The CERT Oracle Secure Coding Standard for Java (2011)	NUM02-J		Ensure that division and modulo operations do not result in divide-by-zero errors
Software Fault Patterns	SFP1		Glitch in computation

References

[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <https://www.cprogramming.com/tutorial/exceptions.html>. URL validated: 2023-04-07.

[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.

Content History

Submissions
Submission Date	Submitter	Organization
2008-04-11 (CWE Draft 9, 2008-04-11)	CWE Community
2008-04-11 (CWE Draft 9, 2008-04-11)	Submitted by members of the CWE community to extend early CWE versions
Modifications
Modification Date	Modifier	Organization
2008-07-01	Sean Eidemiller	Cigital
2008-07-01	added/updated demonstrative examples
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships, Taxonomy_Mappings
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Demonstrative_Examples, Detection_Factors, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 415

Abstraction: Variant
Structure: Simple

View customized information:

Description

The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.

Extended Description

When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

Alternate Terms

Double-free

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	666	Operation on Resource in Wrong Phase of Lifetime
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1341	Multiple Releases of Same Resource or Handle
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	825	Expired Pointer Dereference
PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	123	Write-what-where Condition
PeerOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	364	Signal Handler Race Condition

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

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

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code shows a simple example of a double free vulnerability.

(bad code)

Example Language: C

char* ptr = (char*)malloc (SIZE);
...
if (abrt) {

free(ptr);

}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

Error conditions and other exceptional circumstances
Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than this example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 2

While contrived, this code should be exploitable on Linux distributions that do not ship with heap-chunk check summing turned on.

(bad code)

Example Language: C

#include <stdio.h>
#include <unistd.h>
#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)

int main(int argc, char **argv) {

char *buf1R1;
char *buf2R1;
char *buf1R2;
buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);
free(buf1R1);
free(buf2R1);
buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);
free(buf2R1);
free(buf1R2);

}

Observed Examples

Reference	Description
CVE-2006-5051	Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
CVE-2004-0642	Double free resultant from certain error conditions.
CVE-2004-0772	Double free resultant from certain error conditions.
CVE-2005-1689	Double free resultant from certain error conditions.
CVE-2003-0545	Double free from invalid ASN.1 encoding.
CVE-2003-1048	Double free from malformed GIF.
CVE-2005-0891	Double free from malformed GIF.
CVE-2002-0059	Double free from malformed compressed data.

Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Phase: Implementation

Use a static analysis tool to find double free instances.

Detection Methods

Fuzzing

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	398	7PK - Code Quality
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	969	SFP Secondary Cluster: Faulty Memory Release
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1162	SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1237	SFP Primary Cluster: Faulty Resource Release
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Relationship

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.

Theoretical

It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			DFREE - Double-Free Vulnerability
7 Pernicious Kingdoms			Double Free
CLASP			Doubly freeing memory
CERT C Secure Coding	MEM00-C		Allocate and free memory in the same module, at the same level of abstraction
CERT C Secure Coding	MEM01-C		Store a new value in pointers immediately after free()
CERT C Secure Coding	MEM30-C	CWE More Specific	Do not access freed memory
CERT C Secure Coding	MEM31-C		Free dynamically allocated memory exactly once
Software Fault Patterns	SFP12		Faulty Memory Release

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Double Frees", Page 379. 1st Edition. Addison Wesley. 2006.

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

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Other_Notes
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Observed_Examples, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Maintenance_Notes, Theoretical_Notes
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Demonstrative_Examples, Observed_Examples
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 825

Abstraction: Base
Structure: Simple

View customized information:

Description

The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.

Extended Description

When a product releases memory, but it maintains a pointer to that memory, then the memory might be re-allocated at a later time. If the original pointer is accessed to read or write data, then this could cause the product to read or modify data that is in use by a different function or process. Depending on how the newly-allocated memory is used, this could lead to a denial of service, information exposure, or code execution.

Alternate Terms

Dangling pointer

Relationships

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

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	672	Operation on a Resource after Expiration or Release
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	415	Double Free
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	562	Return of Stack Variable Address
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	125	Out-of-bounds Read
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	787	Out-of-bounds Write

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	465	Pointer Issues

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

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

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Memory If the expired pointer is used in a read operation, an attacker might be able to control data read in by the application.
Availability	Technical Impact: DoS: Crash, Exit, or Restart If the expired pointer references a memory location that is not accessible to the product, or points to a location that is "malformed" (such as NULL) or larger than expected by a read or write operation, then a crash may occur.
Integrity Confidentiality Availability	Technical Impact: Execute Unauthorized Code or Commands If the expired pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.

Demonstrative Examples

Example 1

The following code shows a simple example of a use after free error:

(bad code)

Example Language: C

char* ptr = (char*)malloc (SIZE);
if (err) {

abrt = 1;
free(ptr);

}
...
if (abrt) {

logError("operation aborted before commit", ptr);

}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

Example 2

The following code shows a simple example of a double free error:

(bad code)

Example Language: C

char* ptr = (char*)malloc (SIZE);
...
if (abrt) {

free(ptr);

}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

Error conditions and other exceptional circumstances
Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Observed Examples

Reference	Description
CVE-2008-5013	access of expired memory address leads to arbitrary code execution
CVE-2010-3257	stale pointer issue leads to denial of service and possibly other consequences
CVE-2008-0062	Chain: a message having an unknown message type may cause a reference to uninitialized memory resulting in a null pointer dereference (CWE-476) or dangling pointer (CWE-825), possibly crashing the system or causing heap corruption.
CVE-2007-1211	read of value at an offset into a structure after the offset is no longer valid

Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Terminology

Maintenance

Content History

Submissions
Submission Date	Submitter	Organization
2010-09-22 (CWE 1.10, 2010-09-27)	CWE Content Team	MITRE
2010-09-22 (CWE 1.10, 2010-09-27)
Modifications
Modification Date	Modifier	Organization
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Demonstrative_Examples, Potential_Mitigations, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, Relationships
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Alternate_Terms
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Observed_Examples
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Research_Gaps
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Common_Consequences, Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 359

Abstraction: Base
Structure: Simple

View customized information:

Description

Extended Description

There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation.

Some types of private information include:

Government identifiers, such as Social Security Numbers
Contact information, such as home addresses and telephone numbers
Geographic location - where the user is (or was)
Employment history
Financial data - such as credit card numbers, salary, bank accounts, and debts
Pictures, video, or audio
Behavioral patterns - such as web surfing history, when certain activities are performed, etc.
Relationships (and types of relationships) with others - family, friends, contacts, etc.
Communications - e-mail addresses, private messages, text messages, chat logs, etc.
Health - medical conditions, insurance status, prescription records
Account passwords and other credentials

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Alternate Terms

Privacy violation
Privacy leak
Privacy leakage

Relationships

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

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

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

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

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

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

Modes Of Introduction

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

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Application Data

Demonstrative Examples

Example 1

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

(bad code)

Example Language: C#

pass = GetPassword();
...
dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Example 2

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, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

Example 3

In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.

Potential Mitigations

Phase: Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.

Phase: Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

Detection Methods

Architecture or Design Review

Private personal data can enter a program in a variety of ways:

Directly from the user in the form of a password or personal information

Accessed from a database or other data store by the application

Indirectly from a partner or other third party

If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	254	7PK - Security Features
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	857	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	975	SFP Secondary Cluster: Architecture
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1147	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1340	CISQ Data Protection Measures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1345	OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1417	Comprehensive Categorization: Sensitive Information Exposure

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Maintenance

This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed. However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Privacy Violation
The CERT Oracle Secure Coding Standard for Java (2011)	FIO13-J		Do not log sensitive information outside a trust boundary

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-464	Evercookie
CAPEC-467	Cross Site Identification
CAPEC-498	Probe iOS Screenshots
CAPEC-508	Shoulder Surfing

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

[REF-338] J. Oates. "AOL man pleads guilty to selling 92m email addies". The Register. 2005. <https://www.theregister.com/2005/02/07/aol_email_theft/>. URL validated: 2023-04-07.

[REF-339] NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)". 2010-04. <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf>. URL validated: 2023-04-07.

[REF-340] U.S. Department of Commerce. "Safe Harbor Privacy Framework". <https://web.archive.org/web/20010223203241/http://www.export.gov/safeharbor/>. URL validated: 2023-04-07.

[REF-341] Federal Trade Commission. "Financial Privacy: The Gramm-Leach Bliley Act (GLBA)". <https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act>. URL validated: 2023-04-07.

[REF-342] U.S. Department of Human Services. "Health Insurance Portability and Accountability Act (HIPAA)". <https://www.hhs.gov/hipaa/index.html>. URL validated: 2023-04-07.

[REF-343] Government of the State of California. "California SB-1386". 2002. <http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html>.

[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.

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

[REF-1047] Wikipedia. "General Data Protection Regulation". <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation>.

[REF-1048] State of California Department of Justice, Office of the Attorney General. "California Consumer Privacy Act (CCPA)". <https://oag.ca.gov/privacy/ccpa>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	7 Pernicious Kingdoms
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Other_Notes
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Other_Notes, References
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Other_Notes, References
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Other_Notes, References
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Applicable_Platforms, References
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Alternate_Terms, Demonstrative_Examples, Description, Name, Other_Notes, References
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Potential_Mitigations, References, Relationships, Type
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Related_Attack_Patterns
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated References
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Related_Attack_Patterns
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2014-02-18	Privacy Violation

2020-02-24	Exposure of Private Information ('Privacy Violation')

Weakness ID: 761

Abstraction: Variant
Structure: Simple

View customized information:

Description

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

Extended Description

This can cause the product to crash, or in some cases, modify critical program variables or execute code.

This weakness often occurs when the memory is allocated explicitly on the heap with one of the malloc() family functions and free() is called, but pointer arithmetic has caused the pointer to be in the interior or end of the buffer.

Relationships

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

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	763	Release of Invalid Pointer or Reference

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

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

Modes Of Introduction

Phase	Note
Implementation

Common Consequences

Scope	Impact	Likelihood
Integrity Availability Confidentiality	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands

Demonstrative Examples

Example 1

In this example, the programmer dynamically allocates a buffer to hold a string and then searches for a specific character. After completing the search, the programmer attempts to release the allocated memory and return SUCCESS or FAILURE to the caller. Note: for simplification, this example uses a hard-coded "Search Me!" string and a constant string length of 20.

(bad code)

Example Language: C

#define SUCCESS (1)
#define FAILURE (0)

int contains_char(char c){

char *str;
str = (char*)malloc(20*sizeof(char));
strcpy(str, "Search Me!");
while( *str != NULL){

if( *str == c ){

/* matched char, free string and return success */
free(str);
return SUCCESS;

}
/* didn't match yet, increment pointer and try next char */

str = str + 1;

}
/* we did not match the char in the string, free mem and return failure */

free(str);
return FAILURE;

}

However, if the character is not at the beginning of the string, or if it is not in the string at all, then the pointer will not be at the start of the buffer when the programmer frees it.

Instead of freeing the pointer in the middle of the buffer, the programmer can use an indexing pointer to step through the memory or abstract the memory calculations by using array indexing.

(good code)

Example Language: C

#define SUCCESS (1)
#define FAILURE (0)

int cointains_char(char c){

char *str;
int i = 0;
str = (char*)malloc(20*sizeof(char));
strcpy(str, "Search Me!");
while( i < strlen(str) ){

if( str[i] == c ){

/* matched char, free string and return success */
free(str);
return SUCCESS;

}
/* didn't match yet, increment pointer and try next char */

i = i + 1;

}
/* we did not match the char in the string, free mem and return failure */

free(str);
return FAILURE;

}

Example 2

This code attempts to tokenize a string and place it into an array using the strsep function, which inserts a \0 byte in place of whitespace or a tab character. After finishing the loop, each string in the AP array points to a location within the input string.

(bad code)

Example Language: C

char **ap, *argv[10], *inputstring;
for (ap = argv; (*ap = strsep(&inputstring, " \t")) != NULL;)

if (**ap != '\0')

if (++ap >= &argv[10])

break;

/.../
free(ap[4]);

Since strsep is not allocating any new memory, freeing an element in the middle of the array is equivalent to free a pointer in the middle of inputstring.

Example 3

Consider the following code in the context of a parsing application to extract commands out of user data. The intent is to parse each command and add it to a queue of commands to be executed, discarding each malformed entry.

(bad code)

Example Language: C

//hardcode input length for simplicity
char* input = (char*) malloc(40*sizeof(char));
char *tok;
char* sep = " \t";

get_user_input( input );

/* The following loop will parse and process each token in the input string */

tok = strtok( input, sep);
while( NULL != tok ){

if( isMalformed( tok ) ){

/* ignore and discard bad data */
free( tok );

}
else{

add_to_command_queue( tok );

}
tok = strtok( NULL, sep));

}

While the above code attempts to free memory associated with bad commands, since the memory was all allocated in one chunk, it must all be freed together.

One way to fix this problem would be to copy the commands into a new memory location before placing them in the queue. Then, after all commands have been processed, the memory can safely be freed.

(good code)

Example Language: C

//hardcode input length for simplicity
char* input = (char*) malloc(40*sizeof(char));
char *tok, *command;
char* sep = " \t";

get_user_input( input );

/* The following loop will parse and process each token in the input string */

tok = strtok( input, sep);
while( NULL != tok ){

if( !isMalformed( command ) ){

/* copy and enqueue good data */
command = (char*) malloc( (strlen(tok) + 1) * sizeof(char) );
strcpy( command, tok );
add_to_command_queue( command );

}
tok = strtok( NULL, sep));

}

free( input )

Observed Examples

Reference	Description
CVE-2019-11930	function "internally calls 'calloc' and returns a pointer at an index... inside the allocated buffer. This led to freeing invalid memory."

Potential Mitigations

Phase: Implementation

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

Phase: Implementation

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

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.

For example, glibc in Linux provides protection against free of invalid pointers.

Phase: Architecture and Design

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

Phase: Testing

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

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	969	SFP Secondary Cluster: Faulty Memory Release
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: Allowed

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Maintenance

Currently, CWE-763 is the parent, however it may be desirable to have an intermediate parent which is not function-specific, similar to how CWE-762 is an intermediate parent between CWE-763 and CWE-590.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
Software Fault Patterns	SFP12		Faulty Memory Release

References

[REF-657] "boost C++ Library Smart Pointers". <https://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/smart_ptr.htm>. URL validated: 2023-04-07.

[REF-480] "Valgrind". <http://valgrind.org/>.

Content History

Submissions
Submission Date	Submitter	Organization
2009-05-08 (CWE 1.4, 2009-05-27)	CWE Content Team	MITRE
2009-05-08 (CWE 1.4, 2009-05-27)
Modifications
Modification Date	Modifier	Organization
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Observed_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 284

Abstraction: Pillar
Structure: Simple

View customized information:

Description

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

Extended Description

Access control involves the use of several protection mechanisms such as:

Authentication (proving the identity of an actor)
Authorization (ensuring that a given actor can access a resource), and
Accountability (tracking of activities that were performed)

When any mechanism is not applied or otherwise fails, attackers can compromise the security of the product by gaining privileges, reading sensitive information, executing commands, evading detection, etc.

There are two distinct behaviors that can introduce access control weaknesses:

Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.
Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.

Alternate Terms

Authorization:	The terms "access control" and "authorization" are often used interchangeably, although many people have distinct definitions. The CWE usage of "access control" is intended as a general term for the various mechanisms that restrict which users can access which resources, and "authorization" is more narrowly defined. It is unlikely that there will be community consensus on the use of these terms.

Relationships

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

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1000	Research Concepts
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	269	Improper Privilege Management
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	282	Improper Ownership Management
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	285	Improper Authorization
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	286	Incorrect User Management
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	346	Origin Validation Error
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	749	Exposed Dangerous Method or Function
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	923	Improper Restriction of Communication Channel to Intended Endpoints
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1191	On-Chip Debug and Test Interface With Improper Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1220	Insufficient Granularity of Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1224	Improper Restriction of Write-Once Bit Fields
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1231	Improper Prevention of Lock Bit Modification
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1233	Security-Sensitive Hardware Controls with Missing Lock Bit Protection
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1242	Inclusion of Undocumented Features or Chicken Bits
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1252	CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1257	Improper Access Control Applied to Mirrored or Aliased Memory Regions
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1259	Improper Restriction of Security Token Assignment
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1260	Improper Handling of Overlap Between Protected Memory Ranges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1262	Improper Access Control for Register Interface
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1263	Improper Physical Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1267	Policy Uses Obsolete Encoding
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1268	Policy Privileges are not Assigned Consistently Between Control and Data Agents
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1270	Generation of Incorrect Security Tokens
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1274	Improper Access Control for Volatile Memory Containing Boot Code
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1276	Hardware Child Block Incorrectly Connected to Parent System
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1280	Access Control Check Implemented After Asset is Accessed
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1283	Mutable Attestation or Measurement Reporting Data
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1290	Incorrect Decoding of Security Identifiers
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1292	Incorrect Conversion of Security Identifiers
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1294	Insecure Security Identifier Mechanism
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1296	Incorrect Chaining or Granularity of Debug Components
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1304	Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1311	Improper Translation of Security Attributes by Fabric Bridge
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1312	Missing Protection for Mirrored Regions in On-Chip Fabric Firewall
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1313	Hardware Allows Activation of Test or Debug Logic at Runtime
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1315	Improper Setting of Bus Controlling Capability in Fabric End-point
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1316	Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1317	Improper Access Control in Fabric Bridge
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1320	Improper Protection for Outbound Error Messages and Alert Signals
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1323	Improper Management of Sensitive Trace Data
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1334	Unauthorized Error Injection Can Degrade Hardware Redundancy

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

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

Common Weakness Enumeration

CWE VIEW: CISQ Data Protection Measures

View Components

CWE-36: Absolute Path Traversal

CWE-788: Access of Memory Location After End of Buffer

CWE-786: Access of Memory Location Before Start of Buffer

CWE-824: Access of Uninitialized Pointer

CWE-288: Authentication Bypass Using an Alternate Path or Channel

CWE-639: Authorization Bypass Through User-Controlled Key

CWE-805: Buffer Access with Incorrect Length Value

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

CWE-502: Deserialization of Untrusted Data

CWE-369: Divide By Zero

CWE-415: Double Free

CWE-624: Executable Regular Expression Error

CWE-825: Expired Pointer Dereference

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

CWE-213: Exposure of Sensitive Information Due to Incompatible Policies

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

CWE-284: Improper Access Control

Common Weakness Enumeration

CWE VIEW: CISQ Data Protection Measures

View Components

CWE-36: Absolute Path Traversal

Edit Custom Filter

CWE-788: Access of Memory Location After End of Buffer

Edit Custom Filter

CWE-786: Access of Memory Location Before Start of Buffer

Edit Custom Filter

CWE-824: Access of Uninitialized Pointer

Edit Custom Filter

CWE-288: Authentication Bypass Using an Alternate Path or Channel

Edit Custom Filter

CWE-639: Authorization Bypass Through User-Controlled Key

Edit Custom Filter

CWE-805: Buffer Access with Incorrect Length Value

Edit Custom Filter

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Edit Custom Filter

CWE-502: Deserialization of Untrusted Data

Edit Custom Filter

CWE-369: Divide By Zero

Edit Custom Filter

CWE-415: Double Free

Edit Custom Filter

CWE-624: Executable Regular Expression Error

Edit Custom Filter

CWE-825: Expired Pointer Dereference

Edit Custom Filter

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Edit Custom Filter

CWE-213: Exposure of Sensitive Information Due to Incompatible Policies

Edit Custom Filter

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

Edit Custom Filter

CWE-284: Improper Access Control

Edit Custom Filter