Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types. Medium Availability: Integer coercion often leads to undefined states of execution resulting in infinite loops or crashes. Access Control: In some cases, integer coercion errors can lead to exploitable buffer overflow conditions, resulting in the execution of arbitrary code. Integrity: Integer coercion errors result in an incorrect value being stored for the variable in question. Requirements specification: A language which throws exceptions on ambiguous data casts might be chosen. Design: Design objects and program flow such that multiple or complex casts are unnecessary Implementation: Ensure that any data type casting that you must used is entirely understood in order to reduce the plausibility of error in use. See the Examples section of the problem type Unsigned to signed conversion error for an example of integer coercion errors. Several flaws fall under the category of integer coercion errors. For the most part, these errors in and of themselves result only in availability and data integrity issues. However, in some circumstances, they may result in other, more complicated security related flaws, such as buffer overflow conditions. 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Weakness CanAlsoBe 197 1000 Weakness CanAlsoBe 194 Integer coercion error C C++ Java .NET Implementation Functions that manipulate strings encourage buffer overflows. Memory Windows provides the _mbs family of functions to perform various operations on multibyte strings. When these functions are passed a malformed multibyte string, such as a string containing a valid leading byte followed by a single null byte, they can read or write past the end of the string buffer causing a buffer overflow. The following functions all pose a risk of buffer overflow: _mbsinc _mbsdec _mbsncat _mbsncpy _mbsnextc _mbsnset _mbsrev _mbsset _mbsstr _mbstok _mbccpy _mbslen 1000 Category ChildOf 133 630 View ChildOf 630 631 Category ChildOf 633 Often Misused: Strings C C++ A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). Stack Overflow Very high Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. Access control (memory and instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution. Operational: Use OS-level preventative functionality. Not a complete solution. While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows: C There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which he places arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a "write-what-where" condition. Stack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc. Terminology Note: "Stack Overflow" is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged. 1000 Compound_Element ChildOf 120 630 View ChildOf 630 Stack overflow C C++ Implementation A buffer overflow where the buffer from the Buffer Write Operation is statically allocated 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(). High to Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Memory Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. Access control (memory and instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. 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. Operational: Use OS-level preventative functionality. Not a complete solution. C CVE-2007-4268 Chain: integer signedness passes signed comparison, leads to heap overflow Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows. 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. 1000 Compound_Element ChildOf 120 630 View ChildOf 630 631 Category ChildOf 633 Heap overflow C C++ Implementation 92 A buffer overflow where the buffer from the Buffer Write Operation is dynamically allocated Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow. High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Access control (memory and instruction processing): Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Availability: Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language that provides appropriate memory abstractions. Design: Integrate technologies that try to prevent the consequences of this problem. Implementation: Take note of mitigations provided for other flaws in this taxonomy that lead to write-what-where conditions. Operational: Use OS-level preventative functionality integrated after the fact. Not a complete solution. When the attacker has the ability to write arbitrary data to an arbitrary location in memory, the consequences are often arbitrary code execution. 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 using a write-what-where problem, 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. 1000 Weakness ChildOf 119 1000 Weakness PeerOf 134 Write-what-where condition C C++ The software allows a condition where buffers are written to using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer. This typically occurs when indexes are negative numbers or when pointer arithmetic results in a position before the beginning of the valid memory location. This can occur when a negative number is used as an offset, or if the pointer or its index is decremented to a position before the buffer. 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). Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Availability: Buffer underwrites will very likely result in the corruption of relevant memory, and perhaps instructions, leading to a crash. Access Control (memory and instruction processing): 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. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Sanity checks should be performed on all calculated values used as index or for pointer arithmetic. 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: C If the index to srcBuf is somehow under user control, this is an arbitrary write-what-where condition. CVE-2002-2227 Unchecked length of SSLv2 challenge value leads to buffer underflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2227 CVE-2007-4580 Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4580 CVE-2007-1584 Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1584 CVE-2007-0886 Buffer underflow resultant from encoded data that triggers an integer overflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0886 CVE-2006-6171 Product sets an incorrect buffer size limit, leading to "off-by-two" buffer underflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6171 CVE-2006-4024 Negative value is used in a memcpy() operation, leading to buffer underflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4024 CVE-2004-2620 Buffer underflow due to mishandled special characters http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2620 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). 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. Buffer UNDERFLOWS: What do you know about it? Vuln-Dev Mailing List 2004-01-10 http://seclists.org/vuln-dev/2004/Jan/0022.html 1000 Weakness ChildOf 119 1000 Compound_Element PeerOf 120 1000 Weakness PeerOf 129 UNDER - Boundary beginning violation ('buffer underflow' ?) Buffer underwrite C C++ Implementation The software reads data past the end, or before the beginning, of the intended buffer. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) CVE-2004-0112 out-of-bounds read due to improper length check CVE-2004-0183 packet with large number of specified elements cause out-of-bounds read. CVE-2004-0221 packet with large number of specified elements cause out-of-bounds read. CVE-2004-0184 out-of-bounds read, resultant from integer underflow CVE-2004-1940 large length value causes out-of-bounds read CVE-2004-0421 malformed image causes out-of-bounds read Under-studied and under-reported. Most issues are probably labeled as buffer overflows. 1000 Weakness ChildOf 119 Out-of-bounds Read C C++ Implementation The software reads data past the end of the intended buffer. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) 1000 Weakness ChildOf 125 Buffer over-read C C++ Implementation The software reads data before the start of the intended buffer. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Under-studied. 1000 Weakness ChildOf 125 Buffer under-read C C++ Implementation Unchecked array indexing occurs when an unchecked value is used as an index into a buffer. "out-of-bounds array index" or "index-out-of-range" or "array index underflow" Medium Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Memory Availability: Unchecked array indexing 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: If the memory corrupted is data, rather than instructions, the system will continue to function with improper values. Access Control: If the memory corrupted memory can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Include sanity checks to ensure the validity of any values used as index variables. In loops, use greater-than-or-equal-to, or less-than-or-equal-to, as opposed to simply greater-than, or less-than compare statements. CVE-2005-0369 large ID in packet used as array index CVE-2001-1009 negative array index as argument to POP LIST command CVE-2003-0721 Integer signedness error leads to negative array index CVE-2004-1189 product does not properly track a count and a maximum number, which can lead to resultant array index overflow. A single fault could allow both an overflow and underflow of the array index. An index overflow exploit might use buffer overflow techniques, but this can often be exploited without having to provide "large inputs." Array index overflows can also trigger out-of-bounds read operations, or operations on the wrong objects; i.e., "buffer overflows" are not always the result. Unchecked array indexing, depending on its instantiation, can be responsible for any number of related issues. Most prominent of these possible flaws is the buffer overflow condition. Due to this fact, consequences range from denial of service, and data corruption, to full blown arbitrary code execution. The most common condition situation leading to unchecked array indexing 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. 1000 Weakness ChildOf 119 631 Category ChildOf 633 Unchecked array indexing INDEX - Array index overflow C C++ Implementation The software does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow. CVE-2004-1363 substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed CVE-2004-0747 substitution overflow: buffer overflow using expansion of environment variables CVE-2005-2103 substitution overflow: buffer overflow using a large number of substitution strings CVE-2005-3120 transformation overflow: product adds extra escape characters to incoming data, but does not account for them in the buffer length CVE-2003-0899 transformation overflow: buffer overflow when expanding ">" to "&gt;", etc. CVE-2001-0334 expansion overflow: buffer overflow using wildcards CVE-2001-0248 expansion overflow: long pathname + glob = overflow CVE-2001-0249 expansion overflow: long pathname + glob = overflow CVE-2002-0184 special characters in argument are not properly expanded CVE-2004-0434 small length value leads to heap overflow CVE-2002-1347 multiple variants CVE-2005-0490 needs closer investigation, but probably expansion-based CVE-2004-0940 needs closer investigation, but probably expansion-based This is a broad category. Some examples include: (1) simple math errors, (2) incorrectly updating parallel counters, (3) not accounting for size differences when "transforming" one input to another format (e.g. URL canonicalization or other transformation that can generate a result that's larger than the original input, i.e. "expansion"). This level of detail is rarely available in public reports, so it is difficult to find good examples. 1000 Weakness ChildOf 119 Other length calculation error C C++ 47 Miscalculated null termination occurs when the placement of a null character at the end of a buffer of characters (or string) is misplaced or omitted. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Confidentiality: Information disclosure may occur if strings with misplaced or omitted null characters are printed. Availability: A randomly placed null character may put the system into an undefined state, and therefore make it prone to crashing. Integrity: A misplaced null character may corrupt other data in memory Access Control: Should the null character corrupt the process flow, or effect a flag controlling access, it may lead to logical errors which allow for the execution of arbitrary code. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. 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. 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: C #in]]> int ]]> 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. Miscalculated null termination is a common issue, and often difficult to detect. The most common symptoms occur infrequently (in the case of problems resulting from "safe" string functions), or in odd ways characterized by data corruption (when caused by off-by-one errors). 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. As for misplaced null characters, 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. These logic issues may result in any number of security flaws. 1000 Weakness ChildOf 119 1000 Weakness ChildOf 682 1000 Compound_Element PeerOf 120 1000 Weakness PeerOf 123 Miscalculated null termination C C++ The software does not properly calculate the length of strings that can contain wide or multi-byte characters. The following example would be exploitable if any of the commented incorrect malloc calls were used. C #inc]]> #include <]]> int main() {]]> The output from the printf() statement would be: Strlen() output: 0 Wcslen() output: 53 There are several ways in which improper string length checking may result in an exploitable condition. All of these, however, involve the introduction of buffer overflow conditions in order to reach an exploitable state. The first of these issues takes place when the output of a wide or multi-byte character string, string-length function is used as a size for the allocation of memory. While this will result in an output of the number of characters in the string, note that the characters are most likely not a single byte, as they are with standard character strings. So, using the size returned as the size sent to new or malloc and copying the string to this newly allocated memory will result in a buffer overflow. Another common way these strings are misused involves the mixing of standard string and wide or multi-byte string functions on a single string. Invariably, this mismatched information will result in the creation of a possibly exploitable buffer overflow condition. Again, if a language subject to these flaws must be used, the most effective mitigation technique is to pay careful attention to the code at implementation time and ensure that these flaws do not occur. 1000 Weakness ChildOf 682 1000 Category ChildOf 133 Improper string length checking C C++ The software does not properly terminate a string or array with a null character or equivalent terminator. 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. High If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naïve and error-prone solution. Switch to bounded string manipulation functions. Inspect buffer lengths involved in the buffer overrun trace reported with the defect. 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). 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. The code in Example 1 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(). The code in Example 2 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. CVE-2000-0312 Attacker does not null-terminate argv[] when invoking another program. CVE-2003-0777 Interrupted step causes resultant lack of null termination. CVE-2004-1072 Fault causes resultant lack of null termination, leading to buffer expansion. CVE-2001-1389 Multiple vulnerabilities related to improper null termination. CVE-2003-0143 Product does not null terminate a message buffer after snprintf-like call, leading to overflow. Conceptually, this does not just apply to the C language; any language or representation that involves a terminator could have this sort of problem. 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. 1000 Category ChildOf 169 1000 Compound_Element CanPrecede 120 1000 Weakness CanAlsoBe 147 630 View ChildOf 630 Improper Null Termination String Termination Error C C++ 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 removes the null-terminator from the data item Where “removes” is defined through the following scenarios: 1. data item never ended with null-terminator 2. null-terminator is re-written 3. null-terminator was purposely removed from data item The software makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior. Low Access control (including confidentiality and integrity): Can result in unintended modifications or information leaks of data. Design and Implementation: In flat address space situations, never allow computing memory addresses as offsets from another memory address. Design: Fully specify protocol layout unambiguously, providing a structured grammar (e.g., a compilable yacc grammar). Testing: Test that the implementation properly handles each case in the protocol grammar. C Here, b may not be one byte past a. It may be one byte in front of a. Or, they may have three bytes between them because they get aligned to 32-bit boundaries. When changing platforms or protocol versions, data may move in unintended ways. For example, some architectures may place local variables a and b right next to each other with a on top; some may place them next to each other with b on top; and others may add some padding to each. This ensured that each variable is aligned to a proper word size. In protocol implementations, it is common to offset relative to another field to pick out a specific piece of data. Exceptional conditions -- often involving new protocol versions -- may add corner cases that lead to the data layout changing in an unusual way. The result can be that an implementation accesses a particular part of a packet, treating data of one type as data of another type. 1000 Category ChildOf 137 Reliance on data layout C C++ The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result. This can happen in signed and unsigned cases. "Integer underflow" is sometimes used to identify signedness errors in which an originally positive number becomes negative as a result of subtraction. However, there are cases of bad subtraction in which unsigned integers are involved, so it's not always a signedness issue. "Integer underflow" is occasionally used to describe array index errors in which the index is negative. CVE-2004-0816 Integer underflow in firewall via malformed packet. CVE-2004-1002 Integer underflow by packet with invalid length. CVE-2005-0199 Long input causes incorrect length calculation. CVE-2005-1891 Malformed icon causes integer underflow in loop counter variable. Under-studied. 1000 Weakness ChildOf 682 1000 Category ChildOf 189 Integer underflow (wrap or wraparound) C C++ Java .NET Implementation If one extends a signed number incorrectly, if negative numbers are used, an incorrect extension may result. High Integrity: If one attempts to sign extend a negative variable with an unsigned extension algorithm, it will produce an incorrect result. Authorization: Sign extension errors -- if they are used to collect information from smaller signed sources -- can often create buffer overflows and other memory based problems. Implementation: Use a sign extension library or standard function to extend signed numbers. Implementation: When extending signed numbers fill in the new bits with 0 if the sign bit is 0 or fill the new bits with 1 if the sign bit is 1. C Sign extension errors -- if they are used to collect information from smaller signed sources -- can often create buffer overflows and other memory based problems. 1000 Weakness ChildOf 682 1000 Category ChildOf 189 Sign extension error C C++ Java .NET Implementation A signed-to-unsigned conversion error takes place when a signed primitive is used as an unsigned value, usually as a size variable. Conversion between signed and unsigned values can lead to a variety of errors, but from a security standpoint is most commonly associated with integer overflow and buffer overflow vulnerabilities. In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned. If the error condition in the code above is met, then the return value of readdata() will be 4,294,967,295 on a system uses 32-bit integers. In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number. If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers. CVE-2007-4268 Chain: integer signedness passes signed comparison, leads to heap overflow It is dangerous to rely on implicit casts between signed and unsigned numbers because the result can take on an unexpected value and violate weak assumptions made elsewhere in the program. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanPrecede 122 Signed to unsigned conversion error C C++ Implementation An unsigned-to-signed conversion error takes place when a large unsigned primitive is used as a signed value. Medium Availability: Incorrect sign conversions generally lead to undefined behavior, and therefore crashes. Integrity: If a poor cast lead to a buffer overflow or similar condition, data integrity may be affected. Access control (instruction processing): Improper signed-to-unsigned conversions without proper checking can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy. Requirements specification: Choose a language which is not subject to these casting flaws. Design: Design object accessor functions to implicitly check values for valid sizes. Ensure that all functions which will be used as a size are checked previous to use as a size. If the language permits, throw exceptions rather than using in-band errors. Implementation: Error check the return values of all functions. Be aware of implicit casts made, and use unsigned variables for sizes if at all possible. In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: If returnChunkSize() happens to encounter an error, and returns -1, memcpy will assume that the value is unsigned and therefore interpret it as MAXINT-1, therefore copying far more memory than is likely available in the destination buffer. Often, functions will return negative values to indicate a failure state. In the case of functions which return values which are meant to be used as sizes, negative return values can have unexpected results. If these values are passed to the standard memory copy or allocation functions, they will implicitly cast the negative error-indicating value to a large unsigned value. In the case of allocation, this may not be an issue; however, in the case of memory and string copy functions, this can lead to a buffer overflow condition which may be exploitable. Also, if the variables in question are used as indexes into a buffer, it may result in a buffer underflow condition. Although less frequent an issue than signed-to-unsigned casting, unsigned-to-signed casting can be the perfect precursor to dangerous buffer underwrite conditions that allow attackers to move down the stack where they otherwise might not have access in a normal buffer overflow condition. Buffer underwrites occur frequently when large unsigned values are cast to signed values, and then used as indexes into a buffer or for pointer arithmetic. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 124 1000 Compound_Element CanAlsoBe 120 Unsigned to signed conversion error C C++ Implementation 92 Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion. Low Integrity: The true value of the data is lost and corrupted data is used. Implementation: Ensure that no casts, implicit or explicit, take place that move from a larger size primitive or a smaller size primitive. This example, while not exploitable, shows the possible mangling of values associated with truncation errors: int main() { ]]> The above code, when compiled and run, returns the following output: Int MAXINT: 2147483647 Short MAXINT: -1 A frequent paradigm for such a problem being exploitable is when the truncated value is used as an array index, which can happen implicitly when 64-bit values are used as indexes, as they are truncated to 32 bits. When a primitive is cast to a smaller primitive, the high order bits of the large value are lost in the conversion, potentially resulting in an unexpected value that is not equal to the original value. This value may be required as an index into a buffer, a loop iterator, or simply necessary state data. In any case, the value cannot be trusted and the system will be in an undefined state. While this method may be employed viably to isolate the low bits of a value, this usage is rare, and truncation usually implies that an implementation error has occurred. Under-studied and under-reported. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Category CanAlsoBe 192 1000 Weakness CanAlsoBe 194 Numeric truncation error Truncation error C C++ Java .NET Implementation The program calls a function that can never be guaranteed to work safely. High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. The > operator is unsafe to use when reading into a character buffer because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the > operator and overflow the destination buffer. 1000 Category ChildOf 18 Dangerous Functions C C++ Implementation When a product uses the chroot() system call to create a jail, but does not change the working directory afterward, this might allow attackers to access files outside of the jail. High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) File/Directory Example: Consider the following source code from a (hypothetical) FTP server: 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 fails to 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. 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. 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. 1000 Weakness ChildOf 573 1000 Weakness ChildOf 669 631 Category ChildOf 632 Directory Restriction C C++ Implementation Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory. Memory The following code calls realloc() on a buffer containing sensitive data: 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. Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory. 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. Be careful using {vfork, fork} in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use. 1000 Weakness ChildOf 404 1000 Weakness ChildOf 669 630 View ChildOf 630 631 Category ChildOf 633 Heap Inspection C C++ Implementation Failing to catch an exception thrown from a dangerous function can potentially cause the program to crash. The _alloca() function allocates memory on the stack. If an allocation request is too large for the available stack space, _alloca() throws an exception. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. _alloca() has been deprecated as of Microsoft Visual Studio 2005®. It has been replaced with the more secure _alloca_s(). EnterCriticalSection() can raise an exception, potentially causing the program to crash. Under operating systems prior to Windows 2000, the EnterCriticalSection() function can raise an exception in low memory situations. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. 1000 Category ChildOf 389 1000 Weakness ChildOf 691 Often Misused: Exception Handling C C++ Java .NET 54 Passing an inadequately-sized output buffer to a path manipulation function can result in a buffer overflow. Memory File/Directory Always specify output buffers large enough to handle the maximum-size possible result from path manipulation functions. The C standard library function realpath() takes two arguments. The first argument specifies a filename to be converted to canonical form. The second argument specifies an output buffer. Regardless of the length of the canonicalized file name, realpath() will not write more than PATH_MAX bytes to the output buffer. Some programmers incorrectly assume that, by allocating a buffer of size PATH_MAX, there will always be enough room in the buffer to hold any file name that might be found on the system. However, PATH_MAX only bounds the longest possible relative path that can be passed to the kernel in a single call. On most Unix and Linux systems, there is no easily-determined maximum length for a path. In this example the function creates a directory named "output\<name>" in the current directory and returns a heap-allocated copy of its name. For most values of the current directory and the name parameter, this function will work properly. However, if the name parameter is particularly long, then the second call to PathAppend() could overflow the outputDirectoryName buffer, which is smaller than MAX_PATH bytes. Windows provides a large number of utility functions that manipulate buffers containing filenames. In most cases, the result is returned in a buffer that is passed in as input. (Usually the filename is modified in place.) Most functions require the buffer to be at least MAX_PATH bytes in length, but you should check the documentation for each function individually. If the buffer is not large enough to store the result of the manipulation, a buffer overflow can occur. 1000 Compound_Element ChildOf 120 631 Category ChildOf 632 631 Category ChildOf 633 Often Misused: File System C C++ Race conditions occur frequently in signal handlers, since they are asynchronous actions. These race conditions may have any number of root-causes and symptoms. Signals, interprocess communication Medium System Process Authorization: It may be possible to execute arbitrary code through the use of a write-what-where condition. Integrity: Signal race conditions often result in data corruption. Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code. Design: Design signal handlers to only set flags rather than perform complex functionality. Implementation: Ensure that non-reentrant functions are not found in signal handlers. Also, use sanity checks to ensure that state is consistent be performing asynchronous actions which effect the state of execution. C #include #include ]]> ]]> CVE-2001-1349 CVE-2004-0794 CVE-2004-2259 Signal race conditions are a common issue that have only recently been seen as exploitable. These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. If these functions are called at an inopportune moment -- such as while a non-reentrant function is already running --, memory corruption occurs that may be exploitable. Another signal race condition commonly found occurs when free is called within a signal handler, resulting in a double free and therefore a write-what-where condition. This is a perfect example of a signal handler taking actions which cannot be accounted for in state. Even if a given pointer is set to NULL after it has been freed, a race condition still exists between the time the memory was freed and the pointer was set to NULL. This is especially prudent if the same signal handler has been set for more than one signal -- since it means that the signal handler itself may be reentered. Probably under-studied. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 415 1000 Weakness PeerOf 416 1000 Weakness PeerOf 479 1000 Weakness PeerOf 123 631 Category ChildOf 634 Signal handler race condition Signal Handling Race Conditions Race condition in signal handler C C++ The code contains a switch statement in which the switched variable can be modified while the switch is still executing, resulting in unexpected behavior. Medium Undefined: This flaw will result in the system state going out of sync. Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements. C C++ ]]> int]]>st_ctime); ]]>st_ctime % 2){ ]]> This issue is particularly important in the case of switch statements that involve fall-through style case statements -- ie., those which do not end with break. If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption. For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 364 1000 Weakness PeerOf 366 Race condition in switch C C++ Java .NET If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined. Medium System Process Integrity: The main problem is that -- if a lock is overcome -- data could be altered in a bad state. Design: Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multi-threaded environment. Design: Create resource-locking sanity checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution. C C++ foo) foo = num;]]> Java 1000 Weakness ChildOf 362 1000 Category ChildOf 557 631 Category ChildOf 634 Race condition within a thread C C++ Java .NET 26 29 Sending non-cloned mutable data as an argument may result in that data being altered or deleted by the called function, thereby putting the calling function into an undefined state. Medium Integrity: Potentially data could be tampered with by another function which should not have been tampered with. Implementation: Pass in data which should not be altered as constant or immutable. Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way -- regardless of what changes are made to the data -- a valid copy is retained for use by the class. C C++ In this example, bar and baz will be passed by reference to doOtherStuff() which may change them. In situations where unknown code is called with references to mutable data, this external code may possibly make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of execution. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 Mutable objects passed by reference C C++ Java .NET Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function, thereby putting the class in an undefined state. Medium Access Control / Integrity: Potentially data could be tampered with by another function which should not have been tampered with. Implementation: Pass in data which should not be altered as constant or immutable. Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class. C C++ Java In situations where functions return references to mutable data, it is possible that this external code, which called the function, may make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of the class in question. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 Passing mutable objects to an untrusted method C C++ Java .NET The software does not properly handle or manage a signal. System Process CVE-2002-2039 unhandled SIGSERV signal allows core dump CVE-1999-1224 SIGABRT (abort) signal not properly handled, causing core dump. CVE-2002-2039 SIGSERV (invalid memory reference) signal causes core dump.