Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform sanity checks for untrusted data. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Category ChildOf 137 1000 Weakness CanPrecede 289 Cleansing, Canonicalization, and Comparison Errors All 80 79 71 53 72 64 3 78 52 43 The software fails to adequately filter HTTP headers for CR and LF characters. Including unvalidated data in an HTTP header allows an attacker to specify the entirety of the HTTP response rendered by the browser. When an HTTP request contains unexpected CR and LF characters the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks. Construct HTTP headers very carefully, avoiding the use of non-validated input data. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Input (specifically, unexpected CRLFs) that is not appropriate should not be processed into HTTP headers. The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response. Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form: HTTP/1.1 200 OK ... Set-Cookie: author=Jane Smith ... However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form: HTTP/1.1 200 OK ... Set-Cookie: author=Wiley Hacker HTTP/1.1 200 OK ... Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting and page hijacking. Others examples: Cross-User Defacement: An attacker can make a single request to a vulnerable server that will cause the sever to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the sever. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker can leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker. Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although the user of the local browser instance will be affected. Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account. Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker can cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim. CVE-2005-1951 Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-2146 Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1620 HTTP response splitting via CRLF in parameter related to URL. CVE-2004-1656 HTTP response splitting via CRLF in parameter related to URL. CVE-2004-1687 HTTP response splitting via CRLF in parameter related to URL. CVE-2005-2060 Bulletin board allows response splitting via CRLF in parameter. CVE-2005-2065 Bulletin board allows response splitting via CRLF in parameter. CVE-2004-2512 Response splitting via CRLF in PHPSESSID. CVE-2005-1951 Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1687 Chain: HTTP response splitting via CRLF in parameter related to URL. HTTP response splitting vulnerabilities occur when: 1. Data enters a web application through an untrusted source, most frequently an HTTP request. 2. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. As with many software security vulnerabilities, HTTP response splitting is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control. Note that HTTP response splitting is probably only multi-factor in an environment that uses intermediaries. 1000 Weakness ChildOf 93 1000 Weakness CanPrecede 79 1000 Category PeerOf 442 HTTP response splitting HTTP Response Splitting All 63 31 85 34 Writing unsanitized user input into log files can allow an attacker to forge log entries or inject malicious content into logs. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate data is written to log files. The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened. If a user submits the string "twenty-one" for val, the following entry is logged: INFO: Failed to parse val=twenty-one However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged: INFO: Failed to parse val=twenty-one INFO: User logged out=badguy Clearly, attackers can use this same mechanism to insert arbitrary log entries. CVE-2006-4624 Chain: inject fake log entries with fake timestamps using CRLF injection Log forging vulnerabilities occur when: 1. Data enters an application from an untrusted source. 2. The data is written to an application or system log file. Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information. Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [22]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [17]. G. Hoglund G. McGraw Exploiting Software: How to Break Code Addison-Wesley February 2004 A. Muffet The night the log was forged http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm 1000 Weakness ChildOf 116 Log Forging All 81 93 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 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 does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). 1000 Weakness ChildOf 172 1000 Weakness CanPrecede 289 Alternate Encoding All 80 79 71 53 72 64 3 78 52 Improperly handled case sensitive data can lead to several possible consequences, including: - case-insensitive passwords reducing the size of the key space, making brute force attacks easier - bypassing filters or access controls using alternate names - multiple interpretation errors using alternate names. File Processing, Credentials File/Directory Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2000-0497 CVE-2000-0498 CVE-2001-0766 CVE-2001-0795 CVE-2001-1238 CVE-2003-0411 CVE-2002-0485 Leads to interpretation error CVE-1999-0239 CVE-2005-0269 CVE-2004-1083 CVE-2004-2154 Overlaps ACL bypass CVE-2000-0499 CVE-2002-2119 Case insensitive passwords lead to search space reduction. CVE-2004-2214 HTTP server allows bypass of access restrictions using URIs with mixed case. CVE-2004-2154 Mixed upper/lowercase allows bypass of ACLs. CVE-2004-2214 Bypass access restrictions using mixed case. CVE-2005-4509 Bypass malicious script detection by using tokens that aren't case sensitive. CVE-2002-1820 Mixed case problem allows "admin" to have "Admin" rights (alternate name property). CVE-2007-3365 Chain: uppercase file extensions causes web server to return script source code instead of executing the script. These are probably under-studied in Windows and Mac environments, where file names are case-insensitive and thus are subject to equivalence manipulations involving case. 1000 Category ChildOf 171 1000 Weakness CanPrecede 433 1000 Weakness CanPrecede 289 631 Category ChildOf 632 Case Sensitivity (lowercase, uppercase, mixed case) All An application uses a "blacklist" of prohibited values, but the blacklist is incomplete. Primary (Weakness exists independent of other weaknesses) Ensure black list covers all inappropriate content outlined in the Common Weakness Enumeration. Combine use of black list with appropriate use of white lists. CVE-2005-2782 PHP remote file inclusion in web application that filters "http" and "https" URLs, but not "ftp". CVE-2004-0542 Programming language does not filter certain shell metacharacters in Windows environment. CVE-2004-0595 XSS filter doesn't filter null characters before looking for dangerous tags, which are ignored by web browsers. MIE and validate-before-cleanse. CVE-2005-3287 Web-based mail product doesn't restrict dangerous extensions such as ASPX on a web server, even though others are prohibited. CVE-2004-2351 Resultant XSS from incomplete blacklist (only <script> and <style> are checked). CVE-2005-2959 Privileged program does not clear sensitive environment variables that are used by bash. Overlaps multiple interpretation error. CVE-2005-1824 SQL injection protection scheme does not quote the "\" special character. CVE-2005-2184 Incomplete blacklist prevents user from automatically executing .EXE files, but allows .LNK, allowing resultant Windows symbolic link. CVE-2007-1343 product doesn't protect one dangerous variable against external modification http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1343 CVE-2007-5727 Chain: only removes SCRIPT tags, enabling XSS CVE-2006-4308 Chain: only checks "javascript:" tag CVE-2007-3572 Chain: incomplete blacklist for OS command injection An incomplete blacklist frequently produces resultant weaknesses. Exploitation of those weaknesses using the obvious manipulations might fail, but minor variations might succeed. Some incomplete blacklist issues might arise from multiple interpretation errors, e.g. a blacklist for dangerous shell metacharacters might not include a metacharacter that only has meaning in one particular shell, not all of them; or a blacklist for XSS manipulations might ignore an unusual construct that's supported by one web browser, but not others. G. Hoglund G. McGraw Exploiting Software: How to Break Code Addison-Wesley February 2004 S. Christey Blacklist defenses as a breeding ground for vulnerability variants February 2006 http://seclists.org/fulldisclosure/2006/Feb/0040.html 1000 Category ChildOf 171 1000 Weakness ChildOf 693 1000 Weakness CanPrecede 79 1000 Weakness CanPrecede 78 1000 Compound_Element CanPrecede 434 1000 Compound_Element CanPrecede 98 1000 692 Weakness CanPrecede 79 Incomplete Blacklist All Architecture and Design Implementation 3 15 6 43 71 18 63 73 85 86 An integer overflow condition exists when an integer that has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing an unintended value. Non-specific, memory management, counters Medium Availability: Integer overflows generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high. Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the integer overflow has resulted in a buffer overflow condition, data corruption will most likely take place. Access control (instruction processing): Integer overflows 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. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use of sanity checks and assertions at the object level. Ensure that all protocols are strictly defined, such that all out of bounds behavior can be identified simply. 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. Use unsigned integers where possible The following code excerpt from OpenSSH 3.3 demonstrates a classic case of integer overflow: nres]]> If nresp has the value 1073741824 and sizeof(char*) has its typical value of 4, then the result of the operation nresp*sizeof(char*) overflows, and the argument to xmalloc() will be 0. Most malloc() implementations will happily allocate a 0-byte buffer, causing the subsequent loop iterations to overflow the heap buffer response. This example processes user input comprised of a series of variable-length structures. The first 2 bytes of input dictate the size of the structure to be processed. The programmer has set an upper bound on the structure size: if it is larger than 512, the input will not be processed. The problem is that len is a signed integer, so the check against the maximum structure length is done with signed integers, but len is converted to an unsigned integer for the call to memcpy(). If len is negative, then it will appear that the structure has an appropriate size (the if branch will be taken), but the amount of memory copied by memcpy() will be quite large, and the attacker will be able to overflow the stack with data in strm. Integer overflows can be complicated and difficult to detect. The following example is an attempt to show how an integer overflow may lead to undefined looping behavior: C In the above case, it is entirely possible that bytesRec may overflow, continuously creating a lower number than MAXGET and also overwriting the first MAXGET-1 bytes of buf. CVE-2002-0391 Integer overflow via a large number of arguments. CVE-2005-1141 Image with large width and height leads to integer overflow. CVE-2005-0102 Length value of -1 leads to allocation of 0 bytes and resultant heap overflow. CVE-2004-2013 Length value of -1 leads to allocation of 0 bytes and resultant heap overflow. Terminology Note: "integer overflow" is used to cover several types of errors, including signedness errors, or buffer overflows that involve manipulation of integer data types instead of characters. Part of the confusion results from the fact that 0xffffffff is -1 in a signed context. Integer overflows can be primary to buffer overflows. Yves Younan An overview of common programming security vulnerabilities and possible solutions Student thesis section 5.4.3 August 2003 http://fort-knox.org/thesis.pdf blexim Basic Integer Overflows Phrack - Issue 60, Chapter 10 http://www.phrack.org/archives/60/p60-0x0a.txt 1000 Category ChildOf 189 1000 680 Compound_Element CanPrecede 120 1000 Weakness CanPrecede 122 Integer overflow (wrap or wraparound) Integer Overflow Integer overflow Implementation 92 A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value. An "off-by-five" error was reported for sudo in 2002 (CVE-2002-0184), but that is more like a "length calculation" error. Resultant: can produce resultant buffer overflows CVE-2003-0466 CVE-2003-0252 CVE-2003-0625 CVE-2001-1391 CVE-2002-0083 CVE-2002-0653 CVE-2002-0844 CVE-1999-1568 CVE-2004-0346 CVE-2004-0005 CVE-2003-0356 CVE-2001-1496 CVE-2004-0342 This is an interesting example that might not be an off-by-one. CVE-2001-0609 An off-by-one enables a terminating null to be overwritten, which causes 2 strings to be merged and enable a format string. CVE-2002-1745 Off-by-one error allows source code disclosure of files with 4 letter extensions that match an accepted 3-letter extension. CVE-2002-1816 Off-by-one buffer overflow. CVE-2002-1721 Off-by-one error causes an snprintf call to overwrite a critical internal variable with a null value. CVE-2003-0466 Off-by-one error in function used in many products leads to a buffer overflow during pathname management, as demonstrated using multiple commands in an FTP server. CVE-2003-0625 Off-by-one error allows read of sensitive memory via a malformed request. CVE-2006-4574 Chain: security monitoring product has an off-by-one error that leads to unexpected length values, triggering an assertion. This is not always a buffer overflow. For example, an off-by-one error could be a factor in a partial comparison, a read from the wrong memory location, an incorrect conditional, etc. Under-studied. It requires careful code analysis or black box testing, where inputs of excessive length might not cause an error. Off-by-ones are likely triggered by extensive fuzzing, with the attendant diagnostic problems. Halvar Flake Third Generation Exploits presentation at Black Hat Europe 2001 http://www.blackhat.com/presentations/bh-europe-01/halvar-flake/bh-europe-01-halvarflake.ppt Steve Christey Off-by-one errors: a brief explanation Secprog and SC-L mailing list posts 2004-05-05 http://marc.theaimsgroup.com/?l=secprog&m=108379742110553&w=2 klog The Frame Pointer Overwrite Phrack Issue 55, Chapter 8 1999-09-09 http://kaizo.org/mirrors/phrack/phrack55/P55-08 G. Hoglund G. McGraw Exploiting Software: How to Break Code (The buffer overflow chapter) Addison-Wesley February 2004 1000 Weakness ChildOf 682 1000 Category ChildOf 189 1000 Weakness CanPrecede 617 1000 Weakness CanPrecede 170 Off-by-one Error All 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 The product includes sensitive information within an error message. High Confidentiality: Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server. Design: When an application detects illegal input, error messages should only provide generic feedback, such as "Illegal characters were detected." Messages should provide few, if any, implementation details. Implementation: Any error should be parsed for dangerous revelations. Build: Debugging information should not make its way into a production release. Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary. Java Here you are passing much more data than is needed. Another example is passing the SQL exceptions to a WebUser without filtering. Error messages should not provide attackers with any implementation details when the application detects an illegal action. This includes indicating exactly what is allowable, or exactly what was illegal about the user input. Such detailed information can help an attacker craft another attack that now will pass through the validation filters. The first thing an attacker may use -- once an attack has failed -- to stage the next attack is the error information provided by the server. SQL Injection attacks generally probe the server for information in order to stage a successful attack. 1000 Weakness ChildOf 200 Accidental leaking of sensitive information through error messages All 54 7 Ignoring a method's return value can cause the program to overlook unexpected states and conditions. Low Integrity: The data which were produced as a result of a function could be in a bad state. Implementation: Check all functions which return a value. Implementation: When designing any function make sure you return a value or throw an exception in case of an error. Example 1: Consider the following code: The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy(). Example 2: The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc(). The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations: - Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue. - It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state. - The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know. Example 3: The following code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and handle it as though it belongs to the attacker. Example 4: The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference. The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. Example 5: The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined. The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break. Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions. Important and common functions will return some value about the success of its actions. This will alert the program whether or not to handle any errors caused by that function. It is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. Most errors and unusual events in .NET result in an exception being thrown. (This is one of the advantages that .NET has over languages like C: Exceptions make it easier for programmers to think about what can go wrong.) But the stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. This behavior makes it important for programmers to examine the return value from Read() and other IO methods and ensure that they receive the amount of data they expect. It is not uncommon for Java programmers to misunderstand read() and related methods that are part of many java.io classes. Most errors and unusual events in Java result in an exception being thrown. (This is one of the advantages that Java has over languages like C: Exceptions make it easier for programmers to think about what can go wrong.) But the stream and reader classes do not consider it unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. This behavior makes it important for programmers to examine the return value from read() and other IO methods to ensure that they receive the amount of data they expect. 1000 Category ChildOf 389 1000 690 Weakness CanPrecede 476 Unchecked Return Value Ignored function return value All Implementation Hard coded passwords may compromise system security in a way that cannot be easily remedied. It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question. Design (for default accounts): Rather than hard code a default username and password for first time logins, utilize a "first login" mode which requires the user to enter a unique strong password. Design (for front-end to back-end connections): Three solutions are possible, although none are complete. The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals. Next, the passwords used should be limited at the back end to only performing actions valid to for the front end, as opposed to having full access. Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks. The following code uses a hardcoded password to connect to a database: This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above: javap -c ConnMngr.class 22: ldc #36; //String jdbc:mysql://ixne.com/rxsql 24: ldc #38; //String scott 26: ldc #17; //String tiger C C++ Java Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality." The use of a hard-coded password has many negative implications -- the most significant of these being a failure of authentication measures under certain circumstances. On many systems, a default administration account exists which is set to a simple default password which is hard-coded into the program or device. This hard-coded password is the same for each device or system of this type and often is not changed or disabled by end users. If a malicious user comes across a device of this kind, it is a simple matter of looking up the default password (which is freely available and public on the internet) and logging in with complete access. In systems that authenticate with a back-end service, hard-coded passwords within closed source or drop-in solution systems require that the back-end service use a password which can be easily discovered. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple. 1000 Category ChildOf 255 1000 Weakness ChildOf 344 1000 Weakness ChildOf 671 1000 Weakness PeerOf 321 1000 Weakness PeerOf 257 630 View ChildOf 630 Password Management: Hard-Coded Password Use of hard-coded password All Architecture and Design The software performs authentication based on the name of the resource being accessed, but there are multiple names for the resource, and not all names are checked. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2003-0317 CVE-2004-0847 Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues. "alternate name" itself is a rather general class of data-driven manipulation. 1000 Weakness ChildOf 592 Authentication bypass by alternate name All The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered High Authentication: If hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question. Design: Prevention schemes mirror that of hard-coded password storage. C C++ Java The main difference between the use of hard-coded passwords and the use of hard-coded cryptographic keys is the false sense of security that the former conveys. Many people believe that simply hashing a hard-coded password before storage will protect the information from malicious users. However, many hashes are reversible (or at least vulnerable to brute force attacks) -- and further, many authentication protocols simply request the hash itself, making it no better than a password. 1000 Category ChildOf 320 1000 Weakness ChildOf 344 1000 Weakness ChildOf 671 629 View ChildOf 629 Use of hard-coded cryptographic key All Sometimes an error is detected, and bad or no action is taken. Medium Implementation: Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment. Subject the software to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing. C C++ Java If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program. 1000 Category ChildOf 389 1000 Weakness CanPrecede 401 Improper error handling All 83 66 7 The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions. Memory management Medium Memory Availability: If an attacker can determine the cause of the memory leak, then the attacker may be able to cause the application to leak quickly and therefore cause the application to crash. 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: 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. Example 1: The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes: C Example 2: In C: C 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. CVE-2005-3119 Memory leak because function does not free() an element of a data structure. CVE-2004-0427 Memory leak when counter variable is not decremented. CVE-2002-0574 Memory leak when counter variable is not decremented. CVE-2005-3181 Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code. CVE-2004-0222 Memory leak via unknown manipulations as part of protocol test suite. CVE-2001-0136 Memory leak via a series of the same command. This is often a resultant weakness due to improper handling of malformed data or early termination of sessions. Terminology Note: "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). 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 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 the program) or take advantage of other unexpected program behavior resulting from a low memory condition [30]. J. Whittaker H. Thompson How to Break Software Security Addison Wesley 2003 1000 Weakness ChildOf 404 1000 Category ChildOf 399 630 View ChildOf 630 631 Category ChildOf 633 Memory leak Memory Leak Failure to deallocate data C C++ 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. identity of the dynamic allocated memory resource obtained but got re-written (missing beyond recovery) 3. identity of the dynamic allocated memory resource obtained but never passed on to function for memory resource release 4. the statement assigns another value to the last data element that stored the identity of the dynamically allocated memory resource (no more aliases remain) 5. the last data element that stored the identity of the dynamically allocated resource has reached the end of its scope at the statement Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Use-After-Free High Memory Integrity: The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere. Availability: If chunk consolidation occur after the use of previously freed data, the process may crash when invalid data is used as chunk information. Access Control (instruction processing): If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code. Implementation: Ensuring that all pointers are set to NULL once they memory they point to has been freed can be effective strategy. The utilization of multiple or complex data structures may lower the usefulness of this strategy. #include ]]>