CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-659: Weaknesses in Software Written in C++ (2.10)  
ID

CWE VIEW: Weaknesses in Software Written in C++

View ID: 659
Structure: Implicit Slice
Status: Draft
Presentation Filter:
+ View Data

View Objective

This view (slice) covers issues that are found in C++ programs that are not common to all languages.

View Filter: .//Applicable_Platforms//@Language_Name='C++'

+ Relationships
Weakness BaseWeakness Base Access of Resource Using Incompatible Type ('Type Confusion') - (843)
Weakness VariantWeakness Variant Access to Critical Private Variable via Public Method - (767)
Weakness BaseWeakness Base Addition of Data Structure Sentinel - (464)
Weakness VariantWeakness Variant Assigning instead of Comparing - (481)
Weakness BaseWeakness Base Assignment of a Fixed Address to a Pointer - (587)
Weakness VariantWeakness Variant Buffer Access Using Size of Source Buffer - (806)
Weakness BaseWeakness Base Buffer Access with Incorrect Length Value - (805)
Weakness BaseWeakness Base Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
Weakness VariantWeakness Variant Buffer Over-read - (126)
Weakness VariantWeakness Variant Buffer Under-read - (127)
Weakness BaseWeakness Base Buffer Underwrite ('Buffer Underflow') - (124)
Weakness VariantWeakness Variant Cloneable Class Containing Sensitive Information - (498)
Weakness VariantWeakness Variant Comparing instead of Assigning - (482)
Weakness BaseWeakness Base Compiler Optimization Removal or Modification of Security-critical Code - (733)
Weakness BaseWeakness Base Compiler Removal of Code to Clear Buffers - (14)
Weakness ClassWeakness Class Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
Weakness VariantWeakness Variant Creation of chroot Jail Without Changing Working Directory - (243)
Weakness VariantWeakness Variant Critical Public Variable Without Final Modifier - (493)
Weakness VariantWeakness Variant Critical Variable Declared Public - (766)
Weakness BaseWeakness Base Declaration of Catch for Generic Exception - (396)
Weakness BaseWeakness Base Declaration of Throws for Generic Exception - (397)
Weakness BaseWeakness Base Deletion of Data Structure Sentinel - (463)
Weakness VariantWeakness Variant Double Free - (415)
Weakness BaseWeakness Base Duplicate Key in Associative List (Alist) - (462)
Weakness VariantWeakness Variant Exposed IOCTL with Insufficient Access Control - (782)
Weakness VariantWeakness Variant Heap-based Buffer Overflow - (122)
Weakness VariantWeakness Variant Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code - (781)
Weakness VariantWeakness Variant Improper Cleanup on Thrown Exception - (460)
Weakness VariantWeakness Variant Improper Clearing of Heap Memory Before Release ('Heap Inspection') - (244)
Weakness BaseWeakness Base Improper Handling of Length Parameter Inconsistency - (130)
Weakness BaseWeakness Base Improper Null Termination - (170)
Weakness BaseWeakness Base Improper Release of Memory Before Removing Last Reference ('Memory Leak') - (401)
Weakness ClassWeakness Class Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
Weakness BaseWeakness Base Improper Update of Reference Count - (911)
Weakness BaseWeakness Base Improper Validation of Array Index - (129)
Weakness VariantWeakness Variant Incorrect Block Delimitation - (483)
Weakness BaseWeakness Base Incorrect Calculation of Buffer Size - (131)
Weakness BaseWeakness Base Incorrect Calculation of Multi-Byte String Length - (135)
Weakness BaseWeakness Base Incorrect Pointer Scaling - (468)
Weakness ClassWeakness Class Incorrect Type Conversion or Cast - (704)
CategoryCategory Integer Coercion Error - (192)
Weakness BaseWeakness Base Integer Underflow (Wrap or Wraparound) - (191)
Weakness VariantWeakness Variant Mismatched Memory Management Routines - (762)
Weakness VariantWeakness Variant Missing Default Case in Switch Statement - (478)
Weakness BaseWeakness Base NULL Pointer Dereference - (476)
Weakness BaseWeakness Base Numeric Range Comparison Without Minimum Check - (839)
Weakness BaseWeakness Base Numeric Truncation Error - (197)
CategoryCategory Often Misused: String Management - (251)
Weakness BaseWeakness Base Omitted Break Statement in Switch - (484)
Weakness VariantWeakness Variant Operator Precedence Logic Error - (783)
Weakness BaseWeakness Base Out-of-bounds Read - (125)
Weakness BaseWeakness Base Passing Mutable Objects to an Untrusted Method - (374)
Weakness VariantWeakness Variant Private Array-Typed Field Returned From A Public Method - (495)
Weakness VariantWeakness Variant Public Data Assigned to Private Array-Typed Field - (496)
Weakness VariantWeakness Variant Public Static Field Not Marked Final - (500)
Weakness BaseWeakness Base Race Condition in Switch - (365)
Weakness BaseWeakness Base Race Condition within a Thread - (366)
Weakness BaseWeakness Base Reliance on Data/Memory Layout - (188)
Weakness BaseWeakness Base Return of Pointer Value Outside of Expected Range - (466)
Weakness BaseWeakness Base Return of Stack Variable Address - (562)
Weakness BaseWeakness Base Returning a Mutable Object to an Untrusted Caller - (375)
CategoryCategory Signal Errors - (387)
Weakness BaseWeakness Base Signal Handler Race Condition - (364)
Weakness VariantWeakness Variant Signal Handler Use of a Non-reentrant Function - (479)
Weakness VariantWeakness Variant Signed to Unsigned Conversion Error - (195)
Weakness VariantWeakness Variant Stack-based Buffer Overflow - (121)
Weakness BaseWeakness Base Uncaught Exception - (248)
Compound Element: ChainCompound Element: Chain Unchecked Return Value to NULL Pointer Dereference - (690)
Weakness VariantWeakness Variant Uncontrolled Memory Allocation - (789)
Weakness BaseWeakness Base Unexpected Sign Extension - (194)
Weakness VariantWeakness Variant Unsigned to Signed Conversion Error - (196)
Weakness BaseWeakness Base Use After Free - (416)
Weakness BaseWeakness Base Use of Expired File Descriptor - (910)
Weakness BaseWeakness Base Use of Externally-Controlled Format String - (134)
Weakness VariantWeakness Variant Use of getlogin() in Multithreaded Application - (558)
Weakness BaseWeakness Base Use of Incorrect Operator - (480)
Weakness BaseWeakness Base Use of Inherently Dangerous Function - (242)
Weakness VariantWeakness Variant Use of Path Manipulation Function without Maximum-sized Buffer - (785)
Weakness BaseWeakness Base Use of Pointer Subtraction to Determine Size - (469)
Weakness BaseWeakness Base Use of Potentially Dangerous Function - (676)
Weakness VariantWeakness Variant Use of Singleton Pattern Without Synchronization in a Multithreaded Context - (543)
Weakness VariantWeakness Variant Use of sizeof() on a Pointer Type - (467)
Weakness VariantWeakness Variant Use of Uninitialized Variable - (457)
Weakness BaseWeakness Base Wrap-around Error - (128)
Weakness BaseWeakness Base Write-what-where Condition - (123)
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Description, Name, View_Filter, View_Structure
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Weaknesses found in the C++ Language
+ View Metrics
CWEs in this viewTotal CWEs
Total85out of1005
Views0out of33
Categories3out of244
Weaknesses81out of720
Compound_Elements1out of8
View Components
View Components
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')

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

Description Summary

The program allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.

Extended Description

When the program accesses the resource using an incompatible type, this could trigger logical errors because the resource does not have expected properties. In languages without memory safety, such as C and C++, type confusion can lead to out-of-bounds memory access.

While this weakness is frequently associated with unions when parsing data with many different embedded object types in C, it can be present in any application that can interpret the same variable or memory location in multiple ways.

This weakness is not unique to C and C++. For example, errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues.

+ Alternate Terms
Object Type Confusion
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Language-independent

Type-unsafe Languages

+ Demonstrative Examples

Example 1

The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type.

(Bad Code)
Example Language:
#define NAME_TYPE 1
#define ID_TYPE 2

struct MessageBuffer
{
int msgType;
union {
char *name;
int nameID;
};
};


int main (int argc, char **argv) {
struct MessageBuffer buf;
char *defaultMessage = "Hello World";

buf.msgType = NAME_TYPE;
buf.name = defaultMessage;
printf("Pointer of buf.name is %p\n", buf.name);
/* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */
buf.nameID = (int)(defaultMessage + 1);
printf("Pointer of buf.name is now %p\n", buf.name);
if (buf.msgType == NAME_TYPE) {
printf("Message: %s\n", buf.name);
}
else {
printf("Message: Use ID %d\n", buf.nameID);
}
}

The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation.

As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string.

Execution of the program might generate output such as:

Pointer of name is 10830

Pointer of name is now 10831

Message: ello World

Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified.

In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes.

Example 2

The following PHP code accepts a value, adds 5, and prints the sum.

(Bad Code)
Example Language: PHP 
$value = $_GET['value'];
$sum = $value + 5;
echo "value parameter is '$value'<p>";
echo "SUM is $sum";

When called with the following query string:

value=123

the program calculates the sum and prints out:

SUM is 128

However, the attacker could supply a query string such as:

value[]=123

The "[]" array syntax causes $value to be treated as an array type, which then generates a fatal error when calculating $sum:

Fatal error: Unsupported operand types in program.php on line 2

Example 3

The following Perl code is intended to look up the privileges for user ID's between 0 and 3, by performing an access of the $UserPrivilegeArray reference. It is expected that only userID 3 is an admin (since this is listed in the third element of the array).

(Bad Code)
Example Language: Perl 
my $UserPrivilegeArray = ["user", "user", "admin", "user"];

my $userID = get_current_user_ID();

if ($UserPrivilegeArray eq "user") {
print "Regular user!\n";
}
else {
print "Admin!\n";
}

print "\$UserPrivilegeArray = $UserPrivilegeArray\n";

In this case, the programmer intended to use "$UserPrivilegeArray->{$userID}" to access the proper position in the array. But because the subscript was omitted, the "user" string was compared to the scalar representation of the $UserPrivilegeArray reference, which might be of the form "ARRAY(0x229e8)" or similar.

Since the logic also "fails open" (CWE-636), the result of this bug is that all users are assigned administrator privileges.

While this is a forced example, it demonstrates how type confusion can have security consequences, even in memory-safe languages.

+ Observed Examples
ReferenceDescription
Type confusion in CSS sequence leads to out-of-bounds read.
Size inconsistency allows code execution, first discovered when it was actively exploited in-the-wild.
Improperly-parsed file containing records of different types leads to code execution when a memory location is interpreted as a different object than intended.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class704Incorrect Type Conversion or Cast
Development Concepts (primary)699
Research Concepts (primary)1000
CanPrecedeWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Research Concepts1000
+ Research Gaps

Type confusion weaknesses have received some attention by applied researchers and major software vendors for C and C++ code. Some publicly-reported vulnerabilities probably have type confusion as a root-cause weakness, but these may be described as "memory corruption" instead. This weakness seems likely to gain prominence in upcoming years.

For other languages, there are very few public reports of type confusion weaknesses. These are probably under-studied. Since many programs rely directly or indirectly on loose typing, a potential "type confusion" behavior might be intentional, possibly requiring more manual analysis.

+ References
Mark Dowd, Ryan Smith and David Dewey. "Attacking Interoperability". "Type Confusion Vulnerabilities," page 59. 2009. <http://www.azimuthsecurity.com/resources/bh2009_dowd_smith_dewey.pdf>.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Type Confusion", Page 319.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-15MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated References

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

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

Description Summary

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

Extended Description

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

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

Languages

C++

C#

Java

+ Common Consequences
ScopeEffect
Integrity
Other

Technical Impact: Modify application data; Other

+ Likelihood of Exploit

Low to Medium

+ Demonstrative Examples

Example 1

The following example declares a critical variable to be private, and then allows the variable to be modified by public methods.

(Bad Code)
Example Language: C++ 
private: float price;
public: void changePrice(float newPrice) {
price = newPrice;
}

Example 2

The following example could be used to implement a user forum where a single user (UID) can switch between multiple profiles (PID).

(Bad Code)
Example Language: Java 
public class Client {
private int UID;
public int PID;
private String userName;
public Client(String userName){
PID = getDefaultProfileID();
UID = mapUserNametoUID( userName );
this.userName = userName;
}
public void setPID(int ID) {
UID = ID;
}
}

The programmer implemented setPID with the intention of modifying the PID variable, but due to a typo. accidentally specified the critical variable UID instead. If the program allows profile IDs to be between 1 and 10, but a UID of 1 means the user is treated as an admin, then a user could gain administrative privileges as a result of this typo.

+ Potential Mitigations

Phase: Implementation

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Research Concepts1000
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts (primary)1000
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
Software Fault PatternsSFP23Exposed Data
+ Maintenance Notes

This entry is closely associated with access control for public methods. If the public methods are restricted with proper access controls, then the information in the private variable will not be exposed to unexpected parties. There may be chaining or composite relationships between improper access controls and this weakness.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-03-03Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-464: Addition of Data Structure Sentinel

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

Description Summary

The accidental addition of a data-structure sentinel can cause serious programming logic problems.

Extended Description

Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels.

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

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

Generally this error will cause the data structure to not work properly by truncating the data.

+ Likelihood of Exploit

High to Very High

+ Demonstrative Examples

Example 1

The following example assigns some character values to a list of characters and prints them each individually, and then as a string. The third character value is intended to be an integer taken from user input and converted to an int.

(Bad Code)
Example Languages: C and C++ 
char *foo;
foo=malloc(sizeof(char)*5);
foo[0]='a';
foo[1]='a';
foo[2]=atoi(getc(stdin));
foo[3]='c';
foo[4]='\0'
printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3],foo[4]);
printf("%s\n",foo);

The first print statement will print each character separated by a space. However, if a non-integer is read from stdin by getc, then atoi will not make a conversion and return 0. When foo is printed as a string, the 0 at character foo[2] will act as a NULL terminator and foo[3] will never be printed.

+ Potential Mitigations

Phases: Implementation; Architecture and Design

Encapsulate the user from interacting with data sentinels. Validate user input to verify that sentinels are not present.

Phase: Implementation

Proper error checking can reduce the risk of inadvertently introducing sentinel values into data. For example, if a parsing function fails or encounters an error, it might return a value that is the same as the sentinel.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. This is not a complete solution.

Phase: Operation

Use OS-level preventative functionality. This is not a complete solution.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class138Improper Neutralization of Special Elements
Research Concepts (primary)1000
ChildOfCategoryCategory461Data Structure Issues
Development Concepts (primary)699
ChildOfCategoryCategory741CERT C Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
PeerOfWeakness BaseWeakness Base463Deletion of Data Structure Sentinel
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAddition of data-structure sentinel
CERT C Secure CodingSTR03-CDo not inadvertently truncate a null-terminated byte string
CERT C Secure CodingSTR06-CDo not assume that strtok() leaves the parse string unchanged
CERT C++ Secure CodingSTR03-CPPDo not inadvertently truncate a null-terminated character array
CERT C++ Secure CodingSTR06-CPPDo not assume that strtok() leaves the parse string unchanged
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Addition of Data-structure Sentinel

CWE-481: Assigning instead of Comparing

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

Description Summary

The code uses an operator for assignment when the intention was to perform a comparison.

Extended Description

In many languages the compare statement is very close in appearance to the assignment statement and are often confused. This bug is generally the result of a typo and usually causes obvious problems with program execution. If the comparison is in an if statement, the if statement will usually evaluate the value of the right-hand side of the predicate.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Java

.NET

+ Common Consequences
ScopeEffect
Other

Technical Impact: Alter execution logic

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100.

(Bad Code)
Example Languages: C and C# 
int isValid(int value) {
if (value=100) {
printf("Value is valid\n");
return(1);
}
printf("Value is not valid\n");
return(0);
}
(Bad Code)
Example Language: C# 
bool isValid(int value) {
if (value=100) {
Console.WriteLine("Value is valid.");
return true;
}
Console.WriteLine("Value is not valid.");
return false;
}

However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results.

Example 2

In this example, we show how assigning instead of comparing can impact code when values are being passed by reference instead of by value. Consider a scenario in which a string is being processed from user input. Assume the string has already been formatted such that different user inputs are concatenated with the colon character. When the processString function is called, the test for the colon character will result in an insertion of the colon character instead, adding new input separators. Since the string was passed by reference, the data sentinels will be inserted in the original string (CWE-464), and further processing of the inputs will be altered, possibly malformed..

(Bad Code)
Example Language:
void processString (char *str) {
int i;

for(i=0; i<strlen(str); i++) {
if (isalnum(str[i])){
processChar(str[i]);
}
else if (str[i] = ':') {
movingToNewInput();}
}
}
}

Example 3

The following Java example attempts to perform some processing based on the boolean value of the input parameter. However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". As with the previous examples, the variable will be reassigned locally and the expression in the if statement will evaluate to true and unintended processing may occur.

(Bad Code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (isValid = true) {
System.out.println("Performing processing");
doSomethingImportant();
}
else {
System.out.println("Not Valid, do not perform processing");
return;
}
}

While most Java compilers will catch the use of an assignment operator when a comparison operator is required, for boolean variables in Java the use of the assignment operator within an expression is allowed. If possible, try to avoid using comparison operators on boolean variables in java. Instead, let the values of the variables stand for themselves, as in the following code.

(Good Code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (isValid) {
System.out.println("Performing processing");
doSomethingImportant();
}
else {
System.out.println("Not Valid, do not perform processing");
return;
}
}

Alternatively, to test for false, just use the boolean NOT operator.

(Good Code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (!isValid) {
System.out.println("Not Valid, do not perform processing");
return;
}
System.out.println("Performing processing");
doSomethingImportant();
}

Example 4

(Bad Code)
Example Language:
void called(int foo){
if (foo=1) printf("foo\n");
}
int main() {

called(2);
return 0;
}
+ Potential Mitigations

Phase: Testing

Many IDEs and static analysis products will detect this problem.

Phase: Implementation

Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base480Use of Incorrect Operator
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness ClassWeakness Class697Insufficient Comparison
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAssigning instead of comparing
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-587: Assignment of a Fixed Address to a Pointer

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

Description Summary

The software sets a pointer to a specific address other than NULL or 0.

Extended Description

Using a fixed address is not portable because that address will probably not be valid in all environments or platforms.

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

Languages

C

C++

C#

Assembly

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

If one executes code at a known location, an attacker might be able to inject code there beforehand.

Availability

Technical Impact: DoS: crash / exit / restart

If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.

Confidentiality
Integrity

Technical Impact: Read memory; Modify memory

The data at a known pointer location can be easily read or influenced by an attacker.

+ Demonstrative Examples

Example 1

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(Bad Code)
Example Language:
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.

+ Potential Mitigations

Phase: Implementation

Never set a pointer to a fixed address.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base344Use of Invariant Value in Dynamically Changing Context
Research Concepts (primary)1000
ChildOfCategoryCategory465Pointer Issues
Development Concepts (primary)699
ChildOfCategoryCategory738CERT C Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfWeakness ClassWeakness Class758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Research Concepts1000
ChildOfCategoryCategory872CERT C++ Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingINT11-CTake care when converting from pointer to integer or integer to pointer
CERT C++ Secure CodingINT11-CPPTake care when converting from pointer to integer or integer to pointer
Software Fault PatternsSFP1Glitch in computation
+ White Box Definitions

A weakness where code path has:

1. end statement that assigns an address to a pointer

2. start statement that defines the address and the address is a literal value

+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Common_Consequences, Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-806: Buffer Access Using Size of Source Buffer

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

Description Summary

The software uses the size of a source buffer when reading from or writing to a destination buffer, which may cause it to access memory that is outside of the bounds of the buffer.

Extended Description

When the size of the destination is smaller than the size of the source, a buffer overflow could occur.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: crash / exit / 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.

Integrity
Confidentiality
Availability

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

Access Control

Technical Impact: Bypass protection mechanism

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

+ Likelihood of Exploit

Medium to High

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Languages: C and 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 Languages: C and C++ 
...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(dest)-1);
...

Example 2

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 Languages: C and 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 Languages: C and C++ 
...
// copy filename to buffer
strncpy(buf, filename, sizeof(buf)-1);
...
+ Potential Mitigations

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Examples include the Safe C String Library (SafeStr) by Viega, and the Strsafe.h library from Microsoft. This is not a complete solution, since many buffer overflows are not related to strings.

Phase: Build and Compilation

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. This is not necessarily a complete solution, since these canary-based 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

Programmers should adhere to the following rules when allocating and managing their applications 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 calling this function in a loop and make sure you are not in danger of writing past the allocated space. Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions

Phase: Operation

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) [R.806.3] [R.806.5] and Position-Independent Executables (PIE) [R.806.7].

Effectiveness: Defense in Depth

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.806.5] [R.806.6].

Effectiveness: Defense in Depth

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

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base805Buffer Access with Incorrect Length Value
Development Concepts (primary)699
Research Concepts (primary)1000
+ Affected Resources
  • Memory
+ Causal Nature

Explicit

+ References
[R.806.1] [REF-27] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.
[R.806.2] [REF-26] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.
[R.806.3] [REF-22] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.
[R.806.4] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.
[R.806.5] [REF-29] "PaX". <http://en.wikipedia.org/wiki/PaX>.
[R.806.6] [REF-25] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.
[R.806.7] [REF-37] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2010-01-15MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References

CWE-805: Buffer Access with Incorrect Length Value

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

Description Summary

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

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C: (Often)

C++: (Often)

Assembly

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: 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: DoS: crash / exit / 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

Medium to High

+ 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

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.

Effectiveness: Moderate

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.

+ 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:
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 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 we 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:
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

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

(Bad Code)
Example Languages: C and 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 Languages: C and 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 Languages: C and 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 Languages: C and C++ 
...
// copy filename to buffer
strncpy(buf, filename, sizeof(buf)-1);
...
+ Observed Examples
ReferenceDescription
Chain: large length value causes buffer over-read (CWE-126)
Use of packet length field to make a calculation, then copy into a fixed-size buffer
Chain: retrieval of length value from an uninitialized memory location
Crafted length value in document reader leads to buffer overflow
SSL server overflow when the sum of multiple length fields exceeds a given value
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 [R.805.6], and the Strsafe.h library from Microsoft [R.805.7]. These libraries provide safer versions of overflow-prone string-handling functions.

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

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause 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 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 you are not in 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.

Phase: Operation

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) [R.805.2] [R.805.4] and Position-Independent Executables (PIE) [R.805.10].

Effectiveness: Defense in Depth

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.805.3] [R.805.6].

Effectiveness: Defense in Depth

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 [R.805.9]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

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

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory740CERT C Secure Coding Section 06 - Arrays (ARR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ParentOfWeakness VariantWeakness Variant806Buffer Access Using Size of Source Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base130Improper Handling of Length Parameter Inconsistency
Research Concepts1000
+ Affected Resources
  • Memory
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C++ Secure CodingARR33-CPPGuarantee that copies are made into storage of sufficient size
CERT C Secure CodingARR33-CGuarantee that copies are made into storage of sufficient size
+ References
[R.805.1] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 6, "Why ACLs Are Important" Page 171. 2nd Edition. Microsoft. 2002.
[R.805.2] [REF-22] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.
[R.805.3] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.
[R.805.4] [REF-29] "PaX". <http://en.wikipedia.org/wiki/PaX>.
[R.805.5] Jason Lam. "Top 25 Series - Rank 12 - Buffer Access with Incorrect Length Value". SANS Software Security Institute. 2010-03-11. <http://blogs.sans.org/appsecstreetfighter/2010/03/11/top-25-series-rank-12-buffer-access-with-incorrect-length-value/>.
[R.805.6] [REF-26] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.
[R.805.7] [REF-27] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.
[R.805.8] [REF-25] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.
[R.805.9] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[R.805.10] [REF-37] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2010-01-15MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2014-06-23CWE Content TeamMITREInternal
updated Demonstrative_Examples

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

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

Description Summary

The program 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 program attempts to put more data in a buffer than it can hold, or when a program 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 program 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
buffer overrun:

Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow."

Unbounded Transfer
+ Terminology Notes

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.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Assembly

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: 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: DoS: crash / exit / 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 to Very High

+ 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

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

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.

Automated Static Analysis - Binary / Bytecode

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

Highly cost effective:

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

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

Effectiveness: SOAR High

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

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

Architecture / Design Review

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

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

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

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

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:
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:
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 blindly 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 excerpt below calls the gets() function in C, which is inherently unsafe.

(Bad Code)
Example Language:
char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without restricting how much is copied. 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 Languages: C and 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
ReferenceDescription
buffer overflow using command with long argument
buffer overflow in local program using long environment variable
buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
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.

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 [R.120.4], and the Strsafe.h library from Microsoft [R.120.3]. These libraries provide safer versions of overflow-prone string-handling functions.

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

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause 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 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 you are not in 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 whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

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

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

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Operation

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) [R.120.5] [R.120.7] and Position-Independent Executables (PIE) [R.120.14].

Effectiveness: Defense in Depth

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.120.7] [R.120.9].

Effectiveness: Defense in Depth

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

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 [R.120.10]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

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

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004)711
ChildOfCategoryCategory726OWASP Top Ten 2004 Category A5 - Buffer Overflows
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory741CERT C Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory8652011 Top 25 - Risky Resource Management
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
ParentOfWeakness VariantWeakness Variant785Use of Path Manipulation Function without Maximum-sized Buffer
Development Concepts (primary)699
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
CanFollowWeakness VariantWeakness Variant231Improper Handling of Extra Values
Research Concepts1000
CanFollowWeakness BaseWeakness Base242Use of Inherently Dangerous Function
Research Concepts1000
CanFollowWeakness BaseWeakness Base416Use After Free
Research Concepts1000
CanFollowWeakness BaseWeakness Base456Missing Initialization of a Variable
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant196Unsigned to Signed Conversion Error
Research Concepts1000
+ Relationship Notes

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.

+ Affected Resources
  • Memory
+ Functional Areas
  • Memory Management
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnbounded Transfer ('classic overflow')
7 Pernicious KingdomsBuffer Overflow
CLASPBuffer overflow
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A5CWE More SpecificBuffer Overflows
CERT C Secure CodingSTR35-CDo not copy data from an unbounded source to a fixed-length array
WASC7Buffer Overflow
CERT C++ Secure CodingSTR35-CPPDo not copy data from an unbounded source to a fixed-length array
Software Fault PatternsSFP8Faulty Buffer Access
+ White Box Definitions

A weakness where the code path includes a Buffer Write Operation such that:

1. the expected size of the buffer is greater than the actual size of the buffer where expected size is equal to the sum of the size of the data item and the position in the buffer

Where Buffer Write Operation is a statement that writes a data item of a certain size into a buffer at a certain position and at a certain index

+ References
[R.120.1] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft. 2002.
[R.120.2] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[R.120.3] [REF-27] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.
[R.120.4] [REF-26] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.
[R.120.5] [REF-22] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.
[R.120.6] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.
[R.120.7] [REF-29] "PaX". <http://en.wikipedia.org/wiki/PaX>.
[R.120.8] 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/>.
[R.120.9] [REF-25] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.
[R.120.10] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[R.120.11] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76.. 1st Edition. Addison Wesley. 2006.
[R.120.12] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189.. 1st Edition. Addison Wesley. 2006.
[R.120.13] [REF-7] 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.
[R.120.14] [REF-37] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10CWE Content TeamMITREInternal
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14CWE Content TeamMITREInternal
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24CWE Content TeamMITREInternal
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27CWE Content TeamMITREInternal
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2010-02-16CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unbounded Transfer ('Classic Buffer Overflow')

CWE-126: Buffer Over-read

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

Description Summary

The software reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.

Extended Description

This typically occurs when the pointer or its index is incremented to a position beyond the bounds of the buffer or when pointer arithmetic results in a position outside of the valid memory location to name a few. This may result in exposure of sensitive information or possibly a crash.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read memory

+ Demonstrative Examples

Example 1

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 Languages: C and 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 message body. This can result in a buffer over read 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
ReferenceDescription
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
Chain: product does not handle when an input string is not NULL terminated, leading to buffer over-read or heap-based buffer overflow.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base125Out-of-bounds Read
Development Concepts699
Research Concepts1000
ChildOfWeakness BaseWeakness Base788Access of Memory Location After End of Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
CanFollowWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
+ Relationship Notes

These problems may be resultant from missing sentinel values (CWE-463) or trusting a user-influenced input length variable.

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERBuffer over-read
Software Fault PatternsSFP8Faulty Buffer Access
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITREInternal
updated Description, Relationship_Notes, Relationships
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-127: Buffer Under-read

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

Description Summary

The software reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.

Extended Description

This typically occurs when the 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. This may result in exposure of sensitive information or possibly a crash.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read memory

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base125Out-of-bounds Read
Development Concepts699
Research Concepts1000
ChildOfWeakness BaseWeakness Base786Access of Memory Location Before Start of Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
+ Research Gaps

Under-studied.

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERBuffer under-read
Software Fault PatternsSFP8Faulty Buffer Access
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITREInternal
updated Description, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-124: Buffer Underwrite ('Buffer Underflow')

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

Description Summary

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

+ Alternate Terms
buffer underrun:

Some prominent vendors and researchers use the term "buffer underrun". "Buffer underflow" is more commonly used, although both terms are also sometimes used to describe a buffer under-read (CWE-127).

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

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity
Availability

Technical Impact: Modify memory; DoS: crash / exit / 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
Confidentiality
Availability
Access Control
Other

Technical Impact: Execute unauthorized code or commands; Modify memory; Bypass protection mechanism; Other

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. The consequences would only be limited by how the affected data is used, such as an adjacent memory location that is used to specify whether the user has special privileges.

Access Control
Other

Technical Impact: Bypass protection mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

+ Likelihood of Exploit

Medium

+ 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 Languages: C and 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 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:
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
ReferenceDescription
Unchecked length of SSLv2 challenge value leads to buffer underflow.
Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130)
Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character.
Buffer underflow resultant from encoded data that triggers an integer overflow.
Product sets an incorrect buffer size limit, leading to "off-by-two" buffer underflow.
Negative value is used in a memcpy() operation, leading to buffer underflow.
Buffer underflow due to mishandled special characters
+ Potential Mitigations

Requirements specification: The choice could be made to use a language that is not susceptible to these issues.

Phase: Implementation

Sanity checks should be performed on all calculated values used as index or for pointer arithmetic.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base786Access of Memory Location Before Start of Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base787Out-of-bounds Write
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
CanFollowWeakness BaseWeakness Base839Numeric Range Comparison Without Minimum Check
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant196Unsigned to Signed Conversion Error
Research Concepts1000
+ Relationship Notes

This could be resultant from several errors, including a bad offset or an array index that decrements before the beginning of the buffer (see CWE-129).

+ Research Gaps

Much attention has been paid to buffer overflows, but "underflows" sometimes exist in products that are relatively free of overflows, so it is likely that this variant has been under-studied.

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUNDER - Boundary beginning violation ('buffer underflow'?)
CLASPBuffer underwrite
Software Fault PatternsSFP8Faulty Buffer Access
+ References
"Buffer UNDERFLOWS: What do you know about it?". Vuln-Dev Mailing List. 2004-01-10. <http://seclists.org/vuln-dev/2004/Jan/0022.html>.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Description, Relationships, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences
2009-10-29CWE Content TeamMITREInternal
updated Description, Name, Relationships
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2009-10-29Boundary Beginning Violation ('Buffer Underwrite')

CWE-498: Cloneable Class Containing Sensitive Information

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

Description Summary

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

Extended Description

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

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C++

Java

.NET

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

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

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

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

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

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

public Object clone() {

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

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

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

Phase: Implementation

Make classes uncloneable by defining a clone function like:

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

Phase: Implementation

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

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

CWE-482: Comparing instead of Assigning

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

Description Summary

The code uses an operator for comparison when the intention was to perform an assignment.

Extended Description

In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Modes of Introduction

This bug primarily originates from a typo.

+ Common Consequences
ScopeEffect
Availability
Integrity

Technical Impact: Unexpected state

The assignment will not take place, which should cause obvious program execution problems.

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

(Bad Code)
Example Languages: C and C++ and Java 
void called(int foo) {
foo==1;
if (foo==1) printf("foo\n");
}
int main() {

called(2);
return 0;
}

Example 2

The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable.

(Bad Code)
Example Languages: C and C++ 
#define SIZE 50
int *tos, *p1, stack[SIZE];

void push(int i) {
p1++;
if(p1==(tos+SIZE)) {
// Print stack overflow error message and exit
}
*p1 == i;
}

int pop(void) {
if(p1==tos) {
// Print stack underflow error message and exit
}
p1--;
return *(p1+1);
}

int main(int argc, char *argv[]) {
// initialize tos and p1 to point to the top of stack
tos = stack;
p1 = stack;
// code to add and remove items from stack
...
return 0;
}

The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable.

However, this expression uses the comparison operator "==" rather than the assignment operator "=". The result of using the comparison operator instead of the assignment operator causes erroneous values to be entered into the stack and can cause unexpected results.

+ Potential Mitigations

Phase: Testing

Many IDEs and static analysis products will detect this problem.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base480Use of Incorrect Operator
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory747CERT C Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory886SFP Primary Cluster: Unused entities
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPComparing instead of assigning
CERT C Secure CodingMSC02-CAvoid errors of omission
CERT C++ Secure CodingMSC02-CPPAvoid errors of omission
Software Fault PatternsSFP2Unused Entities
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Common_Consequences, Modes_of_Introduction
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-733: Compiler Optimization Removal or Modification of Security-critical Code

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

Description Summary

The developer builds a security-critical protection mechanism into the software but the compiler optimizes the program such that the mechanism is removed or modified.
+ Applicable Platforms

Languages

C: (Often)

C++: (Often)

All Compiled Languages

+ Common Consequences
ScopeEffect
Access Control
Other

Technical Impact: Bypass protection mechanism; Other

+ Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

+ Observed Examples
ReferenceDescription
C compiler optimization, as allowed by specifications, removes code that is used to perform checks to detect integer overflows.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class435Interaction Error
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Research Concepts1000
ChildOfCategoryCategory976SFP Secondary Cluster: Compiler
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base14Compiler Removal of Code to Clear Buffers
Development Concepts (primary)699
Research Concepts (primary)1000
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-10-01Internal CWE Team
new weakness-focused entry for Research view closes the gap between 14 and 435.
Modifications
Modification DateModifierOrganizationSource
2008-11-24CWE Content TeamMITREInternal
updated Detection_Factors
2009-03-10CWE Content TeamMITREInternal
updated Applicable_Platforms, Observed_Examples, Related_Attack_Patterns, Relationships
2010-02-16CWE Content TeamMITREInternal
updated References
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-14: Compiler Removal of Code to Clear Buffers

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

Description Summary

Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."

Extended Description

This compiler optimization error occurs when:

1. Secret data are stored in memory.

2. The secret data are scrubbed from memory by overwriting its contents.

3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.

+ Time of Introduction
  • Implementation
  • Build and Compilation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Confidentiality
Access Control

Technical Impact: Read memory; Bypass protection mechanism

This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.

+ Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

+ Demonstrative Examples

Example 1

The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset().

(Bad Code)
Example Language:
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {

if (ConnectToMainframe(MFAddr, pwd)) {

// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}

The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system.

It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency.

Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.

+ Potential Mitigations

Phase: Implementation

Store the sensitive data in a "volatile" memory location if available.

Phase: Build and Compilation

If possible, configure your compiler so that it does not remove dead stores.

Phase: Architecture and Design

Where possible, encrypt sensitive data that are used by a software system.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory2Environment
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory729OWASP Top Ten 2004 Category A8 - Insecure Storage
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base733Compiler Optimization Removal or Modification of Security-critical Code
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory747CERT C Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInsecure Compiler Optimization
PLOVERSensitive memory uncleared by compiler optimization
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMSC06-CBe aware of compiler optimization when dealing with sensitive data
CERT C++ Secure CodingMSC06-CPPBe aware of compiler optimization when dealing with sensitive data
Software Fault PatternsSFP23Exposed Data
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft. 2002.
Michael Howard. "When scrubbing secrets in memory doesn't work". BugTraq. 2002-11-05. <http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html>.
Michael Howard. "Some Bad News and Some Good News". Microsoft. 2002-10-21. <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure10102002.asp>.
Joseph Wagner. "GNU GCC: Optimizer Removes Code Necessary for Security". Bugtraq. 2002-11-16. <http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-11/0257.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2008-11-24CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes, Potential_Mitigations, Relationships, Taxonomy_Mappings, Time_of_Introduction
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITREInternal
updated References
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insecure Compiler Optimization

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

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

Description Summary

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

Extended Description

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

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

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

  • Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.

  • Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

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

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

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

Languages

C: (Sometimes)

C++: (Sometimes)

Java: (Sometimes)

Language-independent

Architectural Paradigms

Concurrent Systems Operating on Shared Resources: (Often)

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (CPU); DoS: resource consumption (memory); DoS: resource consumption (other)

When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion (CWE-400).

Availability

Technical Impact: DoS: crash / exit / restart; DoS: instability

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the program(s) into unexpected states, possibly resulting in a crash.

Confidentiality
Integrity

Technical Impact: Read files or directories; Read application data

When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).

+ Likelihood of Exploit

Medium

+ Detection Methods

Black Box

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

White Box

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

Automated Dynamic Analysis

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

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

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

Effectiveness: Moderate

Automated Static Analysis - Binary / Bytecode

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

Highly cost effective:

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

Cost effective for partial coverage:

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

Effectiveness: SOAR High

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Highly cost effective:

  • Framework-based Fuzzer

Cost effective for partial coverage:

  • Fuzz Tester

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

Effectiveness: SOAR High

Manual Static Analysis - Source Code

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

Highly cost effective:

  • Manual Source Code Review (not inspections)

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: SOAR High

Automated Static Analysis - Source Code

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

Highly cost effective:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR High

Architecture / Design Review

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

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

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

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Language: Perl 
$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

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

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

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

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

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

Example 2

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

(Bad Code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);
}

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

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

(Good Code)
 
int f(pthread_mutex_t *mutex) {
int result;

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

/* access shared resource */

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

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

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

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

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

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

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

CWE-243: Creation of chroot Jail Without Changing Working Directory

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

Description Summary

The program uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.

Extended Description

Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Operating Systems

UNIX

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read files or directories

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

Consider the following source code from a (hypothetical) FTP server:

(Bad Code)
Example Language:
chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);

This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server does not change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.

+ Background Details

The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class227Improper Fulfillment of API Contract ('API Abuse')
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class573Improper Following of Specification by Caller
Research Concepts1000
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class669Incorrect Resource Transfer Between Spheres
Research Concepts (primary)1000
ChildOfCategoryCategory979SFP Secondary Cluster: Failed Chroot Jail
Software Fault Pattern (SFP) Clusters (primary)888
+ Affected Resources
  • File/Directory
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsDirectory Restriction
Software Fault PatternsSFP17Failed chroot jail
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Background_Details, Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITREInternal
updated Demonstrative_Examples, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Directory Restriction
2010-12-13Failure to Change Working Directory in chroot Jail

CWE-493: Critical Public Variable Without Final Modifier

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

Description Summary

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

Extended Description

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

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Java

C++

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

The object could potentially be tampered with.

Confidentiality

Technical Impact: Read application data

The object could potentially allow the object to be read.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

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

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

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

Example 2

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

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

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

+ Potential Mitigations

Phase: Implementation

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

+ Background Details

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

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

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

CWE-766: Critical Variable Declared Public

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

Description Summary

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

Languages

C++

C#

Java

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Technical Impact: Read application data; Modify application data

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

+ Likelihood of Exploit

Low to Medium

+ Demonstrative Examples

Example 1

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

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

Instead, the critical data should be declared private.

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

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

Example 2

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

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

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

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

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

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

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

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

Phase: Implementation

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

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

CWE-396: Declaration of Catch for Generic Exception

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

Description Summary

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

Extended Description

Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

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

Languages

C++

Java

.NET

+ Common Consequences
ScopeEffect
Non-Repudiation
Other

Technical Impact: Hide activities; Alter execution logic

+ Demonstrative Examples

Example 1

The following code excerpt handles three types of exceptions in an identical fashion.

(Good Code)
Example Language: Java 
try {
doExchange();
}
catch (IOException e) {
logger.error("doExchange failed", e);
}
catch (InvocationTargetException e) {

logger.error("doExchange failed", e);
}
catch (SQLException e) {

logger.error("doExchange failed", e);
}

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

(Bad Code)
 
try {
doExchange();
}
catch (Exception e) {
logger.error("doExchange failed", e);
}

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class221Information Loss or Omission
Research Concepts1000
ChildOfCategoryCategory388Error Handling
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory389Error Conditions, Return Values, Status Codes
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class705Incorrect Control Flow Scoping
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts1000
ChildOfCategoryCategory960SFP Secondary Cluster: Ambiguous Exception Type
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Catch Block
Software Fault PatternsSFP5Ambiguous Exception Type
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 9: Catching Exceptions." Page 157. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITREInternal
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITREInternal
updated Applicable_Platforms
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Catch Block

CWE-397: Declaration of Throws for Generic Exception

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

Description Summary

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

Extended Description

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

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

Languages

C++

Java

.NET

+ Common Consequences
ScopeEffect
Non-Repudiation
Other

Technical Impact: Hide activities; Alter execution logic

+ Demonstrative Examples

Example 1

The following method throws three types of exceptions.

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

While it might seem tidier to write

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

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

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

CWE-463: Deletion of Data Structure Sentinel

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

Description Summary

The accidental deletion of a data-structure sentinel can cause serious programming logic problems.

Extended Description

Often times data-structure sentinels are used to mark structure of the data structure. A common example of this is the null character at the end of strings. Another common example is linked lists which may contain a sentinel to mark the end of the list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the deletion or modification outside of some wrapper interface which provides safety.

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

Languages

C

C++

+ Common Consequences
ScopeEffect
Availability
Other

Technical Impact: Other

Generally this error will cause the data structure to not work properly.

Authorization
Other

Technical Impact: Other

If a control character, such as NULL is removed, one may cause resource access control problems.

+ Demonstrative Examples

Example 1

This example creates a null terminated string and prints it contents.

(Bad Code)
Example Languages: C and C++ 
char *foo;
int counter;
foo=calloc(sizeof(char)*10);

for (counter=0;counter!=10;counter++) {
foo[counter]='a';
printf("%s\n",foo);
}

The string foo has space for 9 characters and a null terminator, but 10 characters are written to it. As a result, the string foo is not null terminated and calling printf() on it will have unpredictable and possibly dangerous results.

+ Potential Mitigations

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

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

Phase: Operation

Use OS-level preventative functionality. Not a complete solution.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory461Data Structure Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class707Improper Enforcement of Message or Data Structure
Research Concepts (primary)1000
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base464Addition of Data Structure Sentinel
Research Concepts1000
PeerOfWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeletion of data-structure sentinel
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "NUL-Termination Problems", Page 452.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Deletion of Data-structure Sentinel

CWE-415: Double Free

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

Description Summary

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

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: 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

Low to Medium

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Language:
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.

Example 2

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

(Bad Code)
Example Language:
#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
ReferenceDescription
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition that leads to a double free (CWE-415).
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free from invalid ASN.1 encoding.
Double free from malformed GIF.
Double free from malformed GIF.
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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfWeakness BaseWeakness Base666Operation on Resource in Wrong Phase of Lifetime
Research Concepts1000
ChildOfWeakness ClassWeakness Class675Duplicate Operations on Resource
Research Concepts1000
ChildOfCategoryCategory742CERT C Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfWeakness BaseWeakness Base825Expired Pointer Dereference
Research Concepts (primary)1000
ChildOfCategoryCategory876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory969SFP Secondary Cluster: Faulty Memory Release
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
PeerOfWeakness BaseWeakness Base416Use After Free
Development Concepts699
Research Concepts1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
CanFollowWeakness BaseWeakness Base364Signal Handler Race Condition
Research Concepts1000
+ Relationship Notes

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.

+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDFREE - Double-Free Vulnerability
7 Pernicious KingdomsDouble Free
CLASPDoubly freeing memory
CERT C Secure CodingMEM00-CAllocate and free memory in the same module, at the same level of abstraction
CERT C Secure CodingMEM01-CStore a new value in pointers immediately after free()
CERT C Secure CodingMEM31-CFree dynamically allocated memory exactly once
CERT C++ Secure CodingMEM01-CPPStore a valid value in pointers immediately after deallocation
CERT C++ Secure CodingMEM31-CPPFree dynamically allocated memory exactly once
Software Fault PatternsSFP12Faulty Memory Release
+ White Box Definitions

A weakness where code path has:

1. start statement that relinquishes a dynamically allocated memory resource

2. end statement that relinquishes the dynamically allocated memory resource

+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Double Frees", Page 379.. 1st Edition. Addison Wesley. 2006.
+ Maintenance Notes

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2010-12-13CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-462: Duplicate Key in Associative List (Alist)

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

Description Summary

Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.

Extended Description

A duplicate key entry -- if the alist is designed properly -- could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.

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

Languages

C

C++

Java

.NET

+ Common Consequences
ScopeEffect
Other

Technical Impact: Quality degradation; Varies by context

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

The following code adds data to a list and then attempts to sort the data.

(Bad Code)
 
alist = []
while (foo()): #now assume there is a string data with a key basename
queue.append(basename,data)
queue.sort()

Since basename is not necessarily unique, this may not sort how one would like it to be.

+ Potential Mitigations

Phase: Architecture and Design

Use a hash table instead of an alist.

Phase: Architecture and Design

Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory461Data Structure Issues
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base694Use of Multiple Resources with Duplicate Identifier
Research Concepts (primary)1000
ChildOfCategoryCategory744CERT C Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory878CERT C++ Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDuplicate key in associative list (alist)
CERT C Secure CodingENV02-CBeware of multiple environment variables with the same effective name
CERT C++ Secure CodingENV02-CPPBeware of multiple environment variables with the same effective name
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-782: Exposed IOCTL with Insufficient Access Control

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

Description Summary

The software implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.

Extended Description

When an IOCTL contains privileged functionality and is exposed unnecessarily, attackers may be able to access this functionality by invoking the IOCTL. Even if the functionality is benign, if the programmer has assumed that the IOCTL would only be accessed by a trusted process, there may be little or no validation of the incoming data, exposing weaknesses that would never be reachable if the attacker cannot call the IOCTL directly.

The implementations of IOCTLs will differ between operating system types and versions, so the methods of attack and prevention may vary widely.

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

Languages

C: (Often)

C++: (Often)

Operating Systems

UNIX-based

Windows-based

Platform Notes

Because IOCTL functionality is typically performing low-level actions and closely interacts with the operating system, this weakness may only appear in code that is written in low-level languages.

+ Common Consequences
ScopeEffect
Integrity
Availability
Confidentiality

Attackers can invoke any functionality that the IOCTL offers. Depending on the functionality, the consequences may include code execution, denial-of-service, and theft of data.

+ Likelihood of Exploit

Low to Medium

+ Observed Examples
ReferenceDescription
Operating system does not enforce permissions on an IOCTL that can be used to modify network settings.
Device driver does not restrict ioctl calls to its master.
ioctl does not check for a required capability before processing certain requests.
Chain: insecure device permissions allows access to an IOCTL, allowing arbitrary memory to be overwritten.
Chain: anti-virus product uses weak permissions for a device, leading to resultant buffer overflow in an exposed IOCTL.
Chain: sandbox allows opening of a TTY device, enabling shell commands through an exposed ioctl.
Anti-virus product uses insecure security descriptor for a device driver, allowing access to a privileged IOCTL.
Unauthorized user can disable keyboard or mouse by directly invoking a privileged IOCTL.
+ Potential Mitigations

Phase: Architecture and Design

In Windows environments, use proper access control for the associated device or device namespace. See References.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class284Improper Access Control
Development Concepts699
ChildOfWeakness BaseWeakness Base749Exposed Dangerous Method or Function
Development Concepts (primary)699
Research Concepts (primary)1000
CanPrecedeWeakness VariantWeakness Variant781Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code
Research Concepts1000
+ Relationship Notes

This can be primary to many other weaknesses when the programmer assumes that the IOCTL can only be accessed by trusted parties. For example, a program or driver might not validate incoming addresses in METHOD_NEITHER IOCTLs in Windows environments (CWE-781), which could allow buffer overflow and similar attacks to take place, even when the attacker never should have been able to access the IOCTL at all.

+ References
Microsoft. "Securing Device Objects". <http://msdn.microsoft.com/en-us/library/ms794722.aspx>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-07-15MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-12-28CWE Content TeamMITREInternal
updated Time_of_Introduction

CWE-122: Heap-based Buffer Overflow

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

Description Summary

A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Availability

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

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Integrity
Confidentiality
Availability
Access Control

Technical Impact: Execute unauthorized code or commands; Bypass protection mechanism; Modify memory

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.

Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.

Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Execute unauthorized code or commands; Bypass protection mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

+ Likelihood of Exploit

High to Very High

+ Demonstrative Examples

Example 1

While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, heap-based buffer overflows:

(Bad Code)
Example Language:
#define BUFSIZE 256
int main(int argc, char **argv) {
char *buf;
buf = (char *)malloc(sizeof(char)*BUFSIZE);
strcpy(buf, argv[1]);
}

The buffer is allocated heap memory with a fixed size, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.

Example 2

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

(Bad Code)
Example Language:
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 &lt; */
}
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.

+ Observed Examples
ReferenceDescription
Chain: integer signedness passes signed comparison, leads to heap overflow
Chain: product does not handle when an input string is not NULL terminated, leading to buffer over-read or heap-based buffer overflow.
+ Potential Mitigations

Pre-design: Use a language or compiler that performs automatic bounds checking.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Build and Compilation

Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible, but should not be relied upon.

Phase: Implementation

Implement and perform bounds checking on input.

Phase: Implementation

Strategy: Libraries or Frameworks

Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.

Phase: Operation

Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfWeakness BaseWeakness Base787Out-of-bounds Write
Development Concepts699
Research Concepts1000
ChildOfWeakness BaseWeakness Base788Access of Memory Location After End of Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
+ Relationship Notes

Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows.

+ Affected Resources
  • Memory
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPHeap overflow
Software Fault PatternsSFP8Faulty Buffer Access
+ White Box Definitions

A buffer overflow where the buffer from the Buffer Write Operation is dynamically allocated

+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 5, "Heap Overruns" Page 138. 2nd Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-7] 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-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes, Relationship_Notes
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated References
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-781: Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code

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

Description Summary

The software defines an IOCTL that uses METHOD_NEITHER for I/O, but it does not validate or incorrectly validates the addresses that are provided.

Extended Description

When an IOCTL uses the METHOD_NEITHER option for I/O control, it is the responsibility of the IOCTL to validate the addresses that have been supplied to it. If validation is missing or incorrect, attackers can supply arbitrary memory addresses, leading to code execution or a denial of service.

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

Languages

C: (Often)

C++: (Often)

Operating Systems

Windows XP: (Sometimes)

Windows 2000: (Sometimes)

Windows Vista: (Sometimes)

Platform Notes

Because IOCTL functionality is typically performing low-level actions and closely interacts with the operating system, this weakness may only appear in code that is written in low-level languages.

+ Common Consequences
ScopeEffect
Integrity
Availability
Confidentiality

Technical Impact: Modify memory; Read memory; Execute unauthorized code or commands; DoS: crash / exit / restart

An attacker may be able to access memory that belongs to another process or user. If the attacker can control the contents that the IOCTL writes, it may lead to code execution at high privilege levels. At the least, a crash can occur.

+ Likelihood of Exploit

Low to Medium

+ Observed Examples
ReferenceDescription
Driver for file-sharing and messaging protocol allows attackers to execute arbitrary code.
Anti-virus product does not validate addresses, allowing attackers to gain SYSTEM privileges.
DVD software allows attackers to cause a crash.
Personal firewall allows attackers to gain SYSTEM privileges.
chain: device driver for packet-capturing software allows access to an unintended IOCTL with resultant array index error.
+ Potential Mitigations

Phase: Implementation

If METHOD_NEITHER is required for the IOCTL, then ensure that all user-space addresses are properly validated before they are first accessed. The ProbeForRead and ProbeForWrite routines are available for this task. Also properly protect and manage the user-supplied buffers, since the I/O Manager does not do this when METHOD_NEITHER is being used. See References.

Phase: Architecture and Design

If possible, avoid using METHOD_NEITHER in the IOCTL and select methods that effectively control the buffer size, such as METHOD_BUFFERED, METHOD_IN_DIRECT, or METHOD_OUT_DIRECT.

Phases: Architecture and Design; Implementation

If the IOCTL is part of a driver that is only intended to be accessed by trusted users, then use proper access control for the associated device or device namespace. See References.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory465Pointer Issues
Development Concepts699
CanPrecedeWeakness BaseWeakness Base822Untrusted Pointer Dereference
Development Concepts699
CanFollowWeakness VariantWeakness Variant782Exposed IOCTL with Insufficient Access Control
Research Concepts1000
+ Research Gaps

While this type of issue has been known since 2006, it is probably still under-studied and under-reported. Most of the focus has been on high-profile software and security products, but other kinds of system software also use drivers. Since exploitation requires the development of custom code, it requires some skill to find this weakness.

Because exploitation typically requires local privileges, it might not be a priority for active attackers. However, remote exploitation may be possible for software such as device drivers. Even when remote vectors are not available, it may be useful as the final privilege-escalation step in multi-stage remote attacks against application-layer software, or as the primary attack by a local user on a multi-user system.

+ References
Ruben Santamarta. "Exploiting Common Flaws in Drivers". 2007-07-11. <http://reversemode.com/index.php?option=com_content&task=view&id=38&Itemid=1>.
Yuriy Bulygin. "Remote and Local Exploitation of Network Drivers". 2007-08-01. <https://www.blackhat.com/presentations/bh-usa-07/Bulygin/Presentation/bh-usa-07-bulygin.pdf>.
Anibal Sacco. "Windows driver vulnerabilities: the METHOD_NEITHER odyssey". October 2008. <http://www.net-security.org/dl/insecure/INSECURE-Mag-18.pdf>.
Microsoft. "Buffer Descriptions for I/O Control Codes". <http://msdn.microsoft.com/en-us/library/ms795857.aspx>.
Microsoft. "Using Neither Buffered Nor Direct I/O". <http://msdn.microsoft.com/en-us/library/cc264614.aspx>.
Microsoft. "Securing Device Objects". <http://msdn.microsoft.com/en-us/library/ms794722.aspx>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-07-15MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-12-28CWE Content TeamMITREInternal
updated Common_Consequences, Potential_Mitigations, References, Time_of_Introduction
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences

CWE-460: Improper Cleanup on Thrown Exception

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

Description Summary

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

Extended Description

Often, when functions or loops become complicated, some level of resource cleanup is needed throughout execution. Exceptions can disturb the flow of the code and prevent the necessary cleanup from happening.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Java

.NET

+ Common Consequences
ScopeEffect
Other

Technical Impact: Varies by context

The code could be left in a bad state.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

(Bad Code)
Example Languages: C++ and Java 
public class foo {
public static final void main( String args[] ) {

boolean returnValue;
returnValue=doStuff();
}
public static final boolean doStuff( ) {

boolean threadLock;
boolean truthvalue=true;
try {

while(
//check some condition
) {

threadLock=true; //do some stuff to truthvalue
threadLock=false;
}
}
catch (Exception e){

System.err.println("You did something bad");
if (something) return truthvalue;
}
return truthvalue;
}
}

In this case, you may leave a thread locked accidentally.

+ Potential Mitigations

Phase: Implementation

If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory452Initialization and Cleanup Errors
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base459Incomplete Cleanup
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts1000
ChildOfCategoryCategory851CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory961SFP Secondary Cluster: Incorrect Exception Behavior
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPImproper cleanup on thrown exception
CERT Java Secure CodingERR03-JRestore prior object state on method failure
CERT Java Secure CodingERR05-JDo not let checked exceptions escape from a finally block
CERT C++ Secure CodingERR39-CPPGuarantee exception safety
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-06-23CWE Content TeamMITREInternal
updated Description, Other_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-244: Improper Clearing of Heap Memory Before Release ('Heap Inspection')

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

Description Summary

Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.

Extended Description

When sensitive data such as a password or an encryption key is not removed from memory, it could be exposed to an attacker using a "heap inspection" attack that reads the sensitive data using memory dumps or other methods. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Confidentiality
Other

Technical Impact: Read memory; Other

Be careful using vfork() and fork() in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.

+ Demonstrative Examples

Example 1

The following code calls realloc() on a buffer containing sensitive data:

(Bad Code)
Example Language:
cleartext_buffer = get_secret();...
cleartext_buffer = realloc(cleartext_buffer, 1024);
...
scrub_memory(cleartext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for cleartext_buffer.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base226Sensitive Information Uncleared Before Release
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class227Improper Fulfillment of API Contract ('API Abuse')
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory742CERT C Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness ClassWeakness Class669Incorrect Resource Transfer Between Spheres
Research Concepts1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsHeap Inspection
CERT C Secure CodingMEM03-CClear sensitive information stored in reusable resources returned for reuse
CERT C++ Secure CodingMEM03-CPPClear sensitive information stored in returned reusable resources
Software Fault PatternsSFP23Exposed Data
+ White Box Definitions

A weakness where code path has:

1. start statement that stores information in a buffer

2. end statement that resize the buffer and

3. path does not contain statement that performs cleaning of the buffer

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Name, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Name
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Description, Other_Notes
2010-12-13CWE Content TeamMITREInternal
updated Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Heap Inspection
2008-09-09Failure to Clear Heap Memory Before Release
2009-05-27Failure to Clear Heap Memory Before Release (aka 'Heap Inspection')
2010-12-13Failure to Clear Heap Memory Before Release ('Heap Inspection')

CWE-130: Improper Handling of Length Parameter Inconsistency

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

Description Summary

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

Extended Description

If an attacker can manipulate the length parameter associated with an input such that it is inconsistent with the actual length of the input, this can be leveraged to cause the target application to behave in unexpected, and possibly, malicious ways. One of the possible motives for doing so is to pass in arbitrarily large input to the application. Another possible motivation is the modification of application state by including invalid data for subsequent properties of the application. Such weaknesses commonly lead to attacks such as buffer overflows and execution of arbitrary code.

+ Alternate Terms
length manipulation
length tampering
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

All

+ Common Consequences
ScopeEffect
Other

Technical Impact: Varies by context

+ Demonstrative Examples

Example 1

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 Languages: C and 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 message body. This can result in a buffer over read 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
ReferenceDescription
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
Web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.
Buffer overflow in internal string handling routine allows remote attackers to execute arbitrary commands via a length argument of zero or less, which disables the length check.
Web server allows remote attackers to cause a denial of service via an HTTP request with a content-length value that is larger than the size of the request, which prevents server from timing out the connection.
Service does not properly check the specified length of a cookie, which allows remote attackers to execute arbitrary commands via a buffer overflow, or brute force authentication by using a short cookie length.
Traffic analyzer allows remote attackers to cause a denial of service and possibly execute arbitrary code via invalid IPv4 or IPv6 prefix lengths, possibly triggering a buffer overflow.
Chat client allows remote attackers to cause a denial of service or execute arbitrary commands via a JPEG image containing a comment with an illegal field length of 1.
Server allows remote attackers to cause a denial of service and possibly execute arbitrary code via a negative Content-Length HTTP header field causing a heap-based buffer overflow.
Help program allows remote attackers to execute arbitrary commands via a heap-based buffer overflow caused by a .CHM file with a large length field
Name services does not properly validate the length of certain packets, which allows attackers to cause a denial of service and possibly execute arbitrary code. Can overlap zero-length issues
Policy manager allows remote attackers to cause a denial of service (memory consumption and crash) and possibly execute arbitrary code via an HTTP POST request with an invalid Content-Length value.
Heap-based buffer overflow in library allows remote attackers to execute arbitrary code via a modified record length field in an SSLv2 client hello message.
When domain logons are enabled, server allows remote attackers to cause a denial of service via a SAM_UAS_CHANGE request with a length value that is larger than the number of structures that are provided.
Multiple SSH2 servers and clients do not properly handle packets or data elements with incorrect length specifiers, which may allow remote attackers to cause a denial of service or possibly execute arbitrary code.
Server allows remote attackers to cause a denial of service (CPU and memory exhaustion) via a POST request with a Content-Length header set to -1.
Multiple buffer overflows in xml library that may allow remote attackers to execute arbitrary code via long URLs.
Application does not properly validate the length of a value that is saved in a session file, which allows remote attackers to execute arbitrary code via a malicious session file (.ht), web site, or Telnet URL contained in an e-mail message, triggering a buffer overflow.
Server allows remote attackers to cause a denial of service via a remote password array with an invalid length, which triggers a heap-based buffer overflow.
Product allows remote attackers to cause a denial of service and possibly execute arbitrary code via an SMB packet that specifies a smaller buffer length than is required.
Server allows remote attackers to execute arbitrary code via a LoginExt packet for a Cleartext Password User Authentication Method (UAM) request with a PathName argument that includes an AFPName type string that is longer than the associated length field.
PDF viewer allows remote attackers to execute arbitrary code via a PDF file with a large /Encrypt /Length keyLength value.
SVN client trusts the length field of SVN protocol URL strings, which allows remote attackers to cause a denial of service and possibly execute arbitrary code via an integer overflow that leads to a heap-based buffer overflow.
Is effectively an accidental double increment of a counter that prevents a length check conditional from exiting a loop.
Length field of a request not verified.
Buffer overflow by modifying a length value.
Length field inconsistency crashes cell phone.
+ Potential Mitigations

Phase: Implementation

When processing structured incoming data containing a size field followed by raw data, ensure that you identify and resolve any inconsistencies between the size field and the actual size of the data.

Phase: Implementation

Do not let the user control the size of the buffer.

Phase: Implementation

Validate that the length of the user-supplied data is consistent with the buffer size.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
ChildOfWeakness VariantWeakness Variant240Improper Handling of Inconsistent Structural Elements
Research Concepts (primary)1000
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base805Buffer Access with Incorrect Length Value
Research Concepts1000
+ Relationship Notes

This probably overlaps other categories including zero-length issues.

+ Causal Nature

Implicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERLength Parameter Inconsistency
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITREInternal
updated Description, Name
2009-12-28CWE Content TeamMITREInternal
updated Observed_Examples
2010-02-16CWE Content TeamMITREInternal
updated Description, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-07-17CWE Content TeamMITREInternal
updated Type
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Type
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Length Parameter Inconsistency
2009-03-10Failure to Handle Length Parameter Inconsistency

CWE-170: Improper Null Termination

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

Description Summary

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

Extended Description

Null termination errors frequently occur in two different ways. An off-by-one error could cause a null to be written out of bounds, leading to an overflow. Or, a program could use a strncpy() function call incorrectly, which prevents a null terminator from being added at all. Other scenarios are possible.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Platform Notes

Conceptually, this does not just apply to the C language; any language or representation that involves a terminator could have this type of problem.

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability

Technical Impact: Read memory; Execute unauthorized code or commands

The case of an omitted null character is the most dangerous of the possible issues. This will almost certainly result in information disclosure, and possibly a buffer overflow condition, which may be exploited to execute arbitrary code.

Confidentiality
Integrity
Availability

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

If a null character is omitted from a string, then most string-copying functions will read data until they locate a null character, even outside of the intended boundaries of the string. This could:

  • cause a crash due to a segmentation fault

  • cause sensitive adjacent memory to be copied and sent to an outsider

  • trigger a buffer overflow when the copy is being written to a fixed-size buffer

Integrity
Availability

Technical Impact: Modify memory; DoS: crash / exit / restart

Misplaced null characters may result in any number of security problems. The biggest issue is a subset of buffer overflow, and write-what-where conditions, where data corruption occurs from the writing of a null character over valid data, or even instructions. A randomly placed null character may put the system into an undefined state, and therefore make it prone to crashing. A misplaced null character may corrupt other data in memory.

Integrity
Confidentiality
Availability
Access Control
Other

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

Should the null character corrupt the process flow, or affect a flag controlling access, it may lead to logical errors which allow for the execution of arbitrary code.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a NULL terminator.

(Bad Code)
Example Language:
#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null terminate
strcpy(pathbuf,input_buf); //requires null terminated input
...

The code above will behave correctly if the data read from cfgfile is null terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected NULL character, the call to strcpy() will continue copying from memory until it encounters an arbitrary NULL character. This will likely overflow the destination buffer and, if the attacker can control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack.

Example 2

In the following code, readlink() expands the name of a symbolic link stored in the buffer path so that the buffer filename contains the absolute path of the file referenced by the symbolic link. The length of the resulting value is then calculated using strlen().

(Bad Code)
Example Language:
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(filename);
...

The code above will not behave correctly because the value read into buf by readlink() will not be null terminated. In testing, vulnerabilities like this one might not be caught because the unused contents of buf and the memory immediately following it may be NULL, thereby causing strlen() to appear as if it is behaving correctly. However, in the wild strlen() will continue traversing memory until it encounters an arbitrary NULL character on the stack, which results in a value of length that is much larger than the size of buf and may cause a buffer overflow in subsequent uses of this value. Buffer overflows aside, whenever a single call to readlink() returns the same value that has been passed to its third argument, it is impossible to know whether the name is precisely that many bytes long, or whether readlink() has truncated the name to avoid overrunning the buffer. Traditionally, strings are represented as a region of memory containing data terminated with a NULL character. Older string-handling methods frequently rely on this NULL character to determine the length of the string. If a buffer that does not contain a NULL terminator is passed to one of these functions, the function will read past the end of the buffer. Malicious users typically exploit this type of vulnerability by injecting data with unexpected size or content into the application. They may provide the malicious input either directly as input to the program or indirectly by modifying application resources, such as configuration files. In the event that an attacker causes the application to read beyond the bounds of a buffer, the attacker may be able use a resulting buffer overflow to inject and execute arbitrary code on the system.

Example 3

While the following example is not exploitable, it provides a good example of how nulls can be omitted or misplaced, even when "safe" functions are used:

(Bad Code)
Example Language:
#include <stdio.h>
#include <string.h>

int main() {

char longString[] = "String signifying nothing";
char shortString[16];

strncpy(shortString, longString, 16);
printf("The last character in shortString is: %c %1$x\n", shortString[15]);
return (0);
}

The above code gives the following output: The last character in shortString is: l 6c So, the shortString array does not end in a NULL character, even though the "safe" string function strncpy() was used.

+ Observed Examples
ReferenceDescription
Attacker does not null-terminate argv[] when invoking another program.
Interrupted step causes resultant lack of null termination.
Fault causes resultant lack of null termination, leading to buffer expansion.
Multiple vulnerabilities related to improper null termination.
Product does not null terminate a message buffer after snprintf-like call, leading to overflow.
Chain: product does not handle when an input string is not NULL terminated, leading to buffer over-read or heap-based buffer overflow.
+ Potential Mitigations

Phase: Requirements

Use a language that is not susceptible to these issues. However, be careful of null byte interaction errors (CWE-626) with lower-level constructs that may be written in a language that is susceptible.

Phase: Implementation

Ensure that all string functions used are understood fully as to how they append null characters. Also, be wary of off-by-one errors when appending nulls to the end of strings.

Phase: Implementation

If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naive and error-prone solution.

Phase: Implementation

Switch to bounded string manipulation functions. Inspect buffer lengths involved in the buffer overrun trace reported with the defect.

Phase: Implementation

Add code that fills buffers with nulls (however, the length of buffers still needs to be inspected, to ensure that the non null-terminated string is not written at the physical end of the buffer).

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory169Technology-Specific Special Elements
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class707Improper Enforcement of Message or Data Structure
Research Concepts (primary)1000
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory741CERT C Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory748CERT C Secure Coding Section 50 - POSIX (POS)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory973SFP Secondary Cluster: Improper NULL Termination
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant126Buffer Over-read
Research Concepts1000
PeerOfWeakness BaseWeakness Base463Deletion of Data Structure Sentinel
Research Concepts1000
PeerOfWeakness BaseWeakness Base464Addition of Data Structure Sentinel
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant147Improper Neutralization of Input Terminators
Research Concepts1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base193Off-by-one Error
Research Concepts1000
CanFollowWeakness ClassWeakness Class682Incorrect Calculation
Research Concepts1000
+ Relationship Notes

Factors: this is usually resultant from other weaknesses such as off-by-one errors, but it can be primary to boundary condition violations such as buffer overflows. In buffer overflows, it can act as an expander for assumed-immutable data.

Overlaps missing input terminator.

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERImproper Null Termination
7 Pernicious KingdomsString Termination Error
CLASPMiscalculated null termination
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingPOS30-CUse the readlink() function properly
CERT C Secure CodingSTR03-CDo not inadvertently truncate a null-terminated byte string
CERT C Secure CodingSTR32-CNull-terminate byte strings as required
CERT C++ Secure CodingSTR03-CPPDo not inadvertently truncate a null-terminated character array
CERT C++ Secure CodingSTR32-CPPNull-terminate character arrays as required
Software Fault PatternsSFP11Improper Null Termination
+ White Box Definitions

A weakness where the code path has:

1. end statement that passes a data item to a null-terminated string function

2. start statement that produces the improper null-terminated data item

Where "produces" is defined through the following scenarios:

1. data item never ended with null-terminator

2. null-terminator is re-written

+ Maintenance Notes

As currently described, this entry is more like a category than a weakness.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Common_Consequences
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-17KDM AnalyticsExternal
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes, Potential_Mitigations, White_Box_Definitions
2009-10-29CWE Content TeamMITREInternal
updated Description
2011-03-29CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-401: Improper Release of Memory Before Removing Last Reference ('Memory Leak')

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

Description Summary

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

Extended Description

This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions.

+ Alternate Terms
Memory Leak
+ Terminology Notes

"memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict).

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

Languages

C

C++

+ Modes of Introduction

Memory leaks 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

+ Common Consequences
ScopeEffect
Availability

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

Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing or hanging the program) or take advantage of other unexpected program behavior resulting from a low memory condition.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

The following C function leaks a block of allocated memory if the call to read() does not return the expected number of bytes:

(Bad Code)
Example Language:
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {

return NULL;
}
return buf;
}

Example 2

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

(Bad Code)
Example Language:
bar connection(){
foo = malloc(1024);
return foo;
}
endConnection(bar foo) {

free(foo);
}
int main() {

while(1) //thread 1
//On a connection
foo=connection(); //thread 2
//When the connection ends
endConnection(foo)
}
+ Observed Examples
ReferenceDescription
Memory leak because function does not free() an element of a data structure.
Memory leak when counter variable is not decremented.
chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
Memory leak via unknown manipulations as part of protocol test suite.
Memory leak via a series of the same command.
+ Potential Mitigations

Phase: Implementation

Strategy: Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.

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

When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [R.401.2].

To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phases: Architecture and Design; Build and Compilation

The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code.

This is not a complete solution as it is not 100% effective.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base772Missing Release of Resource after Effective Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory861CERT Java Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory982SFP Secondary Cluster: Failure to Release Resource
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
CanFollowWeakness ClassWeakness Class390Detection of Error Condition Without Action
Research Concepts1000
+ Relationship Notes

This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.

+ Affected Resources
  • Memory
+ Functional Areas
  • Memory management
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMemory leak
7 Pernicious KingdomsMemory Leak
CLASPFailure to deallocate data
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT Java Secure CodingMSC04-JDo not leak memory
Software Fault PatternsSFP14Failure to release resource
+ White Box Definitions

A weakness where the code path has:

1. start statement that allocates dynamically allocated memory resource

2. end statement that loses identity of the dynamically allocated memory resource creating situation where dynamically allocated memory resource is never relinquished

Where "loses" is defined through the following scenarios:

1. identity of the dynamic allocated memory resource never obtained

2. the statement assigns another value to the data element that stored the identity of the dynamically allocated memory resource and there are no aliases of that data element

3. identity of the dynamic allocated memory resource obtained but never passed on to function for memory resource release

4. the data element that stored the identity of the dynamically allocated resource has reached the end of its scope at the statement and there are no aliases of that data element

+ References
[R.401.1] J. Whittaker and H. Thompson. "How to Break Software Security". Addison Wesley. 2003.
[R.401.2] [REF-36] iOS Developer Library. "Transitioning to ARC Release Notes". 2013-08-08. <https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, References, Relationship_Notes, Taxonomy_Mappings, Terminology_Notes
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Other_Notes
2009-05-27CWE Content TeamMITREInternal
updated Name
2009-07-17KDM AnalyticsExternal
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITREInternal
updated White_Box_Definitions
2009-10-29CWE Content TeamMITREInternal
updated Modes_of_Introduction, Other_Notes
2010-02-16CWE Content TeamMITREInternal
updated Relationships
2010-06-21CWE Content TeamMITREInternal
updated Other_Notes, Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Demonstrative_Examples, Name
2011-03-29CWE Content TeamMITREInternal
updated Alternate_Terms
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Observed_Examples
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Memory Leak
2009-05-27Failure to Release Memory Before Removing Last Reference (aka 'Memory Leak')
2010-12-13Failure to Release Memory Before Removing Last Reference ('Memory Leak')

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

Weakness ID: 119
Abstraction: Class
Status: Usable
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.

As a result, an attacker may be able to execute arbitrary code, alter the intended control flow, read sensitive information, or cause the system to crash.

+ Alternate Terms
Memory Corruption:

The generic term "memory corruption" is often used to describe the consequences of writing to memory outside the bounds of a buffer, when the root cause is something other than a sequential copies of excessive data from a fixed starting location (i.e., classic buffer overflows or CWE-120). This may include issues such as incorrect pointer arithmetic, accessing invalid pointers due to incomplete initialization or memory release, etc.

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

Languages

C: (Often)

C++: (Often)

Assembly

Languages without memory management support

Platform Notes

It is possible in many programming languages to attempt an operation outside of the bounds of a memory buffer, but the consequences will vary widely depending on the language, platform, and chip architecture.

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands; Modify memory

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), he can redirect a function pointer to his 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.

Availability
Confidentiality

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

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.

Confidentiality

Technical Impact: Read memory

In the case of 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.

+ Likelihood of Exploit

High

+ 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

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.

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

  • Binary / Bytecode Quality Analysis

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • 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

Cost effective for partial coverage:

  • Source Code Quality Analyzer

Effectiveness: SOAR High

Architecture / Design Review

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

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

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

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

This 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:
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 we 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

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

(Bad Code)
Example Language:
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 &lt; */
}
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 3

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

(Bad Code)
Example Language:

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 4

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

(Bad Code)
Example Language:
int getValueFromArray(int *array, int len, int index) {

int value;

// check that the array index is less than the maximum
// length of the array
if (index < len) {

// get the value at the specified index of the array
value = array[index];
}
// if array index is invalid then output error message
// and return value indicating error
else {
printf("Value is: %d\n", array[index]);
value = -1;
}

return value;
}

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read (CWE-125) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.

(Good Code)
Example Language:

...

// check that the array index is within the correct
// range of values for the array
if (index >= 0 && index < len) {

...
+ Observed Examples
ReferenceDescription
Classic stack-based buffer overflow in media player using a long entry in a playlist
Heap-based buffer overflow in media player using a long entry in a playlist
large precision value in a format string triggers overflow
negative offset value leads to out-of-bounds read
malformed inputs cause accesses of uninitialized or previously-deleted objects, leading to memory corruption
chain: lack of synchronization leads to memory corruption
attacker-controlled array index leads to code execution
chain: -1 value from a function call was intended to indicate an error, but is used as an array index instead.
chain: incorrect calculations lead to incorrect pointer dereference and memory corruption
product accepts crafted messages that lead to a dereference of an arbitrary pointer
chain: malformed input causes dereference of uninitialized memory
OS kernel trusts userland-supplied length value, allowing reading of sensitive information
+ 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 [R.119.3], and the Strsafe.h library from Microsoft [R.119.2]. These libraries provide safer versions of overflow-prone string-handling functions.

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

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause 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 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 you are not in 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: Operation

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) [R.119.4] [R.119.6] and Position-Independent Executables (PIE) [R.119.10].

Effectiveness: Defense in Depth

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.119.6] [R.119.7].

Effectiveness: Defense in Depth

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.

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

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)Named Chain(s) this relationship pertains toChain(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts699
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class118Improper Access of Indexable Resource ('Range Error')
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory726OWASP Top Ten 2004 Category A5 - Buffer Overflows
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory740CERT C Secure Coding Section 06 - Arrays (ARR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory741CERT C Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory742CERT C Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory743CERT C Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory744CERT C Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory877CERT C++ Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory878CERT C++ Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base123Write-what-where Condition
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base125Out-of-bounds Read
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base130Improper Handling of Length Parameter Inconsistency
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base466Return of Pointer Value Outside of Expected Range
Research Concepts (primary)1000
ParentOfCompound Element: ChainCompound Element: Chain680Integer Overflow to Buffer Overflow
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base786Access of Memory Location Before Start of Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base787Out-of-bounds Write
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base788Access of Memory Location After End of Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base805Buffer Access with Incorrect Length Value
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base822Untrusted Pointer Dereference
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base823Use of Out-of-range Pointer Offset
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base824Access of Uninitialized Pointer
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base825Expired Pointer Dereference
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
CanFollowWeakness BaseWeakness Base128Wrap-around Error
Research Concepts1000
CanFollowWeakness BaseWeakness Base129Improper Validation of Array Index
Research Concepts1000
CanFollowWeakness BaseWeakness Base131Incorrect Calculation of Buffer Size
Development Concepts699
Research Concepts1000
CanFollowWeakness BaseWeakness Base190Integer Overflow or Wraparound
Research Concepts1000
Integer Overflow to Buffer Overflow680
CanFollowWeakness BaseWeakness Base193Off-by-one Error
Research Concepts1000
CanFollowWeakness VariantWeakness Variant195Signed to Unsigned Conversion Error
Research Concepts1000
CanFollowWeakness BaseWeakness Base839Numeric Range Comparison Without Minimum Check
Research Concepts1000
CanFollowWeakness BaseWeakness Base843Access of Resource Using Incompatible Type ('Type Confusion')
Research Concepts1000
+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A5ExactBuffer Overflows
CERT C Secure CodingARR00-CUnderstand how arrays work
CERT C Secure CodingARR33-CGuarantee that copies are made into storage of sufficient size
CERT C Secure CodingARR34-CEnsure that array types in expressions are compatible
CERT C Secure CodingARR35-CDo not allow loops to iterate beyond the end of an array
CERT C Secure CodingENV01-CDo not make assumptions about the size of an environment variable
CERT C Secure CodingFIO37-CDo not assume character data has been read
CERT C Secure CodingMEM09-CDo not assume memory allocation routines initialize memory
CERT C Secure CodingSTR31-CGuarantee that storage for strings has sufficient space for character data and the null terminator
CERT C Secure CodingSTR32-CNull-terminate byte strings as required
CERT C Secure CodingSTR33-CSize wide character strings correctly
WASC7Buffer Overflow
CERT C++ Secure CodingARR00-CPPUnderstand when to prefer vectors over arrays
CERT C++ Secure CodingARR30-CPPGuarantee that array and vector indices are within the valid range
CERT C++ Secure CodingARR33-CPPGuarantee that copies are made into storage of sufficient size
CERT C++ Secure CodingARR35-CPPDo not allow loops to iterate beyond the end of an array or container
CERT C++ Secure CodingSTR31-CPPGuarantee that storage for character arrays has sufficient space for character data and the null terminator
CERT C++ Secure CodingSTR32-CPPNull-terminate character arrays as required
CERT C++ Secure CodingMEM09-CPPDo not assume memory allocation routines initialize memory
CERT C++ Secure CodingFIO37-CPPDo not assume character data has been read
CERT C++ Secure CodingENV01-CPPDo not make assumptions about the size of an environment variable
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[R.119.1] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127; Chapter 14, "Prevent I18N Buffer Overruns" Page 441. 2nd Edition. Microsoft. 2002.
[R.119.2] [REF-27] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.
[R.119.3] [REF-26] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.
[R.119.4] [REF-22] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.
[R.119.5] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.
[R.119.6] [REF-29] "PaX". <http://en.wikipedia.org/wiki/PaX>.
[R.119.7] [REF-25] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.
[R.119.8] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Memory Corruption", Page 167.. 1st Edition. Addison Wesley. 2006.
[R.119.9] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189.. 1st Edition. Addison Wesley. 2006.
[R.119.10] [REF-37] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Likelihood_of_Exploit, Name, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Observed_Examples
2009-10-29CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Relationships, Time_of_Introduction
2009-12-28CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Observed_Examples
2010-02-16CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Name
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Demonstrative_Examples
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Buffer Errors
2009-01-12Failure to Constrain Operations within the Bounds of an Allocated Memory Buffer
2010-12-13Failure to Constrain Operations within the Bounds of a Memory Buffer

CWE-911: Improper Update of Reference Count

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

Description Summary

The software uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count.

Extended Description

Reference counts can be used when tracking how many objects contain a reference to a particular resource, such as in memory management or garbage collection. When the reference count reaches zero, the resource can be de-allocated or reused because there are no more objects that use it. If the reference count accidentally reaches zero, then the resource might be released too soon, even though it is still in use. If all objects no longer use the resource, but the reference count is not zero, then the resource might not ever be released.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

Language-independent

+ Likelihood of Exploit

Medium

+ Observed Examples
ReferenceDescription
chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
Reference count for shared memory not decremented when a function fails, potentially allowing unprivileged users to read kernel memory.
chain: improper reference count tracking leads to file descriptor consumption
chain: integer overflow in reference counter causes the same variable to be destroyed twice.
Incorrect reference count calculation leads to improper object destruction and code execution.
chain: incorrect update of reference count leads to memory leak.
chain/composite: use of incorrect data type for a reference counter allows an overflow of the counter, leading to a free of memory that is still in use.
Improper reference counting leads to failure of cryptographic operations.
chain: improper reference counting in a garbage collection routine leads to use-after-free
chain: reference count not correctly maintained when client disconnects during a large operation, leading to a use-after-free.
Reference count not always incremented, leading to crash or code execution.
improper reference counting leads to expired pointer dereference.
OS kernel increments reference count twice but only decrements once, leading to resource consumption and crash.
OS kernel driver allows code execution
improper reference counting leads to exhaustion of IP addresses
Race condition causes reference counter to be decremented prematurely, leading to the destruction of still-active object and an invalid pointer dereference.
improper reference counting leads to use-after-free
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory452Initialization and Cleanup Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts (primary)1000
CanPrecedeWeakness BaseWeakness Base672Operation on a Resource after Expiration or Release
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base772Missing Release of Resource after Effective Lifetime
Research Concepts1000
+ References
Mateusz "j00ru" Jurczyk. "Windows Kernel Reference Count Vulnerabilities - Case Study". November 2012. <http://j00ru.vexillium.org/dump/zn_slides.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2012-12-21MITREInternal CWE Team

CWE-129: Improper Validation of Array Index

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

Description Summary

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.
+ Alternate Terms
out-of-bounds array index
index-out-of-range
array index underflow
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C: (Often)

C++: (Often)

Language-independent

+ Common Consequences
ScopeEffect
Integrity
Availability

Technical Impact: DoS: crash / exit / restart

Use of an index that is outside the bounds of an array will very likely result in the corruption of relevant memory and perhaps instructions, leading to a crash, if the values are outside of the valid memory area.

Integrity

Technical Impact: Modify memory

If the memory corrupted is data, rather than instructions, the system will continue to function with improper values.

Confidentiality
Integrity

Technical Impact: Modify memory; Read memory

Use of an index that is outside the bounds of an array can also trigger out-of-bounds read or write operations, or operations on the wrong objects; i.e., "buffer overflows" are not always the result. This may result in the exposure or modification of sensitive data.

Integrity
Confidentiality
Availability

Technical Impact: 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 and possibly without the use of large inputs if a precise index can be controlled.

Integrity
Availability
Confidentiality

Technical Impact: DoS: crash / exit / restart; Execute unauthorized code or commands; Read memory; Modify memory

A single fault could allow either an overflow (CWE-788) or underflow (CWE-786) of the array index. What happens next will depend on the type of operation being performed out of bounds, but can expose sensitive information, cause a system crash, or possibly lead to arbitrary code execution.

+ Likelihood of Exploit

High

+ 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 array index errors that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

This is not a perfect solution, since 100% accuracy and coverage are not feasible.

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.

Black Box

Black box methods might not get the needed code coverage within limited time constraints, and a dynamic test might not produce any noticeable side effects even if it is successful.

+ Demonstrative Examples

Example 1

In the code snippet below, an untrusted integer value is used to reference an object in an array.

(Bad Code)
Example Language: Java 
public String getValue(int index) {
return array[index];
}

If index is outside of the range of the array, this may result in an ArrayIndexOutOfBounds Exception being raised.

Example 2

The following example takes a user-supplied value to allocate an array of objects and then operates on the array.

(Bad Code)
Example Language: Java 
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){
die("Negative value supplied for list size, die evil hacker!");
}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();
}

This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown.

Example 3

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

(Bad Code)
Example Language:
int getValueFromArray(int *array, int len, int index) {

int value;

// check that the array index is less than the maximum
// length of the array
if (index < len) {

// get the value at the specified index of the array
value = array[index];
}
// if array index is invalid then output error message
// and return value indicating error
else {
printf("Value is: %d\n", array[index]);
value = -1;
}

return value;
}

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read (CWE-125) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.

(Good Code)
Example Language:

...

// check that the array index is within the correct
// range of values for the array
if (index >= 0 && index < len) {

...

Example 4

The following example retrieves the sizes of messages for a pop3 mail server. The message sizes are retrieved from a socket that returns in a buffer the message number and the message size, the message number (num) and size (size) are extracted from the buffer and the message size is placed into an array using the message number for the array index.

(Bad Code)
Example Language:
/* capture the sizes of all messages */
int getsizes(int sock, int count, int *sizes) {
...
char buf[BUFFER_SIZE];
int ok;
int num, size;

// read values from socket and added to sizes array
while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0)
{

// continue read from socket until buf only contains '.'
if (DOTLINE(buf))
break;
else if (sscanf(buf, "%d %d", &num, &size) == 2)
sizes[num - 1] = size;
}
...
}

In this example the message number retrieved from the buffer could be a value that is outside the allowable range of indices for the array and could possibly be a negative number. Without proper validation of the value to be used for the array index an array overflow could occur and could potentially lead to unauthorized access to memory addresses and system crashes. The value of the array index should be validated to ensure that it is within the allowable range of indices for the array as in the following code.

(Good Code)
Example Language:
/* capture the sizes of all messages */
int getsizes(int sock, int count, int *sizes) {
...
char buf[BUFFER_SIZE];
int ok;
int num, size;

// read values from socket and added to sizes array
while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0)
{

// continue read from socket until buf only contains '.'
if (DOTLINE(buf))
break;
else if (sscanf(buf, "%d %d", &num, &size) == 2) {
if (num > 0 && num <= (unsigned)count)
sizes[num - 1] = size;
else
/* warn about possible attempt to induce buffer overflow */
report(stderr, "Warning: ignoring bogus data for message sizes returned by server.\n");
}
}
...
}

Example 5

In the following example the method displayProductSummary is called from a Web service servlet to retrieve product summary information for display to the user. The servlet obtains the integer value of the product number from the user and passes it to the displayProductSummary method. The displayProductSummary method passes the integer value of the product number to the getProductSummary method which obtains the product summary from the array object containing the project summaries using the integer value of the product number as the array index.

(Bad Code)
Example Language: Java 
// Method called from servlet to obtain product information
public String displayProductSummary(int index) {

String productSummary = new String("");

try {
String productSummary = getProductSummary(index);

} catch (Exception ex) {...}

return productSummary;
}

public String getProductSummary(int index) {
return products[index];
}

In this example the integer value used as the array index that is provided by the user may be outside the allowable range of indices for the array which may provide unexpected results or cause the application to fail. The integer value used for the array index should be validated to ensure that it is within the allowable range of indices for the array as in the following code.

(Good Code)
Example Language: Java 
// Method called from servlet to obtain product information
public String displayProductSummary(int index) {

String productSummary = new String("");

try {
String productSummary = getProductSummary(index);

} catch (Exception ex) {...}

return productSummary;
}

public String getProductSummary(int index) {
String productSummary = "";

if ((index >= 0) && (index < MAX_PRODUCTS)) {
productSummary = products[index];
}
else {
System.err.println("index is out of bounds");
throw new IndexOutOfBoundsException();
}

return productSummary;
}

An alternative in Java would be to use one of the collection objects such as ArrayList that will automatically generate an exception if an attempt is made to access an array index that is out of bounds.

(Good Code)
Example Language: Java 
ArrayList productArray = new ArrayList(MAX_PRODUCTS);
...
try {
productSummary = (String) productArray.get(index);
} catch (IndexOutOfBoundsException ex) {...}

Example 6

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

(Bad Code)
Example Language:

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

+ Observed Examples
ReferenceDescription
large ID in packet used as array index
negative array index as argument to POP LIST command
Integer signedness error leads to negative array index
product does not properly track a count and a maximum number, which can lead to resultant array index overflow.
Chain: device driver for packet-capturing software allows access to an unintended IOCTL with resultant array index error.
Chain: array index error (CWE-129) leads to deadlock (CWE-833)
+ Potential Mitigations

Phase: Architecture and Design

Strategies: Input Validation; Libraries or Frameworks

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. If you use Struts, be mindful of weaknesses covered by the CWE-101 category.

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.

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

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, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.

Phase: Operation

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) [R.129.3] [R.129.4] and Position-Independent Executables (PIE) [R.129.8].

Effectiveness: Defense in Depth

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.129.4] [R.129.5].

Effectiveness: Defense in Depth

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.

Phase: Implementation

Strategy: Input Validation

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

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

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

When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.

Phase: Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

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

+ Weakness Ordinalities
OrdinalityDescription
Resultant

The most common condition situation leading to an out-of-bounds array index is the use of loop index variables as buffer indexes. If the end condition for the loop is subject to a flaw, the index can grow or shrink unbounded, therefore causing a buffer overflow or underflow. Another common situation leading to this condition is the use of a function's return value, or the resulting value of a calculation directly as an index in to a buffer.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory189Numeric Errors
Development Concepts699
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory738CERT C Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory740CERT C Secure Coding Section 06 - Arrays (ARR)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory872CERT C++ Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant789Uncontrolled Memory Allocation
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base823Use of Out-of-range Pointer Offset
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Relationship Notes

This weakness can precede uncontrolled memory allocation (CWE-789) in languages that automatically expand an array when an index is used that is larger than the size of the array, such as JavaScript.

+ Theoretical Notes

An improperly validated array index might lead directly to the always-incorrect behavior of "access of array using out-of-bounds index."

+ Affected Resources
  • Memory