When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. class Echo { public native void runEcho(); static { System.loadLibrary("echo"); } public static void main(String[] args) { new Echo().runEcho(); } } The following C code defines the native method implemented in the Echo class: Java #inc]]> JNIEX]]> Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not perform any bounds checking on its input. The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them. The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information leak in the Java application that exposes its use of JNI [See Reference]. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking. Many safety features that programmers may take for granted simply do not apply for native code, so you must carefully review all such code for potential problems. Other programming languages that may be more susceptible to buffer overflows and other attacks, such as C or C++, usually implement native code. Language-based encapsulation is broken. Fortify Software Fortify Descriptions http://vulncat.fortifysoftware.com B. Stearns The Java™ Tutorial: The Java Native Interface Sun Microsystems 2005 http://java.sun.com/docs/books/tutorial/native1.1/ 1000 Weakness ChildOf 100 Unsafe JNI Java Failure to enable validation when parsing XML gives an attacker the opportunity to supply malicious input. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Always validate XML input against a known XML Schema or DTD. 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. Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed. 1000 Weakness ChildOf 20 Missing XML Validation All 99 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 Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker. System Process Libraries that are loaded should be well understood and come from a trusted source. The application can execute code contained in the native libraries, which often contain calls that are susceptible to other security problems, such as buffer overflows or command injection. All native libraries should be validated to determine if the application requires the use of the library. It is very difficult to determine what these native libraries actually do, and the potential for malicious code is high. In addition, the potential for an inadvertent mistake in these native libraries is also high, as many are written in C or C++ and may be susceptible to buffer overflow or race condition problems. To help prevent buffer overflow attacks, validate all input to native calls for content and length. If the native library does not come from a trusted source, review the source code of the library. The library should be built from the reviewed source before using it. The following code uses System.loadLibrary() to load code from a native library named library.dll, which is normally found in a standard system directory. The problem here is that System.loadLibrary() accepts a library name, not a path, for the library to be loaded. From the Java 1.4.2 API documentation this function behaves as follows [1]: A file containing native code is loaded from the local file system from a place where library files are conventionally obtained. The details of this process are implementation-dependent. The mapping from a library name to a specific filename is done in a system-specific manner. If an attacker is able to place a malicious copy of library.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's library.dll will now be run with elevated privileges, possibly giving them complete control of the system. The following code from a privileged application uses a registry entry to determine the directory in which it is installed and loads a library file based on a relative path from the specified directory. C The code in this example allows an attacker to load an arbitrary library, from which code will be executed with the elevated privilege of the application, by modifying a registry key to specify a different path containing a malicious version of INITLIB. Because the program does not validate the value read from the environment, if an attacker can control the value of APPHOME, they can fool the application into running malicious code. The following code is from a web-based administration utility that allows users access to an interface through which they can update their profile on the system. The utility makes use of a library named =;liberty.dll, which is normally found in a standard system directory. The problem is that the program does not specify an absolute path for liberty.dll. If an attacker is able to place a malicious library named liberty.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's liberty.dll will now be run with elevated privileges, possibly giving the attacker complete control of the system. The type of attack seen in this example is made possible because of the search order used by LoadLibrary() when an absolute path is not specified. If the current directory is searched before system directories, as was the case up until the most recent versions of Windows, then this type of attack becomes trivial if the attacker can execute the program locally. The search order is operating system version dependent, and is controlled on newer operating systems by the value of the registry key: HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode Process control vulnerabilities take two forms: - An attacker can change the command that the program executes: the attacker explicitly controls what the command is. - An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means. We will first consider the first scenario, the possibility that an attacker may be able to control the command that is executed. Process control vulnerabilities of this type occur when: - Data enters the application from an untrusted source. - The data is used as or as part of a string representing a command that is executed by the application. - By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. 1000 Weakness ChildOf 20 631 Category ChildOf 634 Process Control All The software misinterprets an input, whether from an attacker or another product, in a security-relevant fashion. CVE-2005-2225 Product sees dangerous file extension in free text of a group discussion, disconnects all users. CVE-2001-0003 Product does not correctly import and process security settings from another product. This concept needs further study. It is likely a factor in several weaknesses, possibly resultant as well. Overlaps Multiple Interpretation Errors (MIE). 1000 Weakness ChildOf 20 1000 Weakness CanAlsoBe 436 Misinterpretation Error All 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 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 Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Availability: Wrap-around errors generally lead to undefined behavior, infinite loops, and therefore crashes. Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur. Access control (instruction processing): A wrap around 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: The choice could be made to use a language that is not susceptible to these issues. Design: Provide clear upper and lower bounds on the scale of any protocols designed. Implementation: Place sanity checks on all incremented variables to ensure that they remain within reasonable bounds. Due to how addition is performed by computers, if a primitive is incremented past the maximum value possible for its storage space, the system will fail to recognize this, and therefore increment each bit as if it still had extra space. Because of how negative numbers are represented in binary, primitives interpreted as signed may "wrap" to very large negative values. 1000 Weakness ChildOf 119 1000 Weakness PeerOf 190 Wrap-around error All Implementation 92 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 operates on user-controlled input (including length parameters) without validating that the length parameters match the actual length of the input data. If an attacker can manipulate the length parameter associated with an input such that it is inconsistent with the actual length of the input, this can be leveraged to cause the target application to behave in unexpected, and possibly, malicious ways. One of the possible motives for doing so is to pass in arbitrarily large input to the application. Another possible motivation is the modification of application state by including invalid data for subsequent properties of the application. Such weaknesses commonly lead to attacks such as buffer overflows and execution of arbitrary code. length manipulation, length tampering Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) CVE-2001-0825 CVE-2001-1186 CVE-2001-0191 CVE-2003-0429 CVE-2000-0655 CVE-2004-0492 CVE-2004-0201 CVE-2003-0825 can overlap zero-length issues CVE-2004-0095 CVE-2004-0826 CVE-2004-0808 CVE-2002-1357 CVE-2004-0774 CVE-2004-0940 CVE-2004-0989 CVE-2004-0568 CVE-2003-0327 CVE-2003-0345 CVE-2004-0430 CVE-2005-0064 CVE-2004-0413 leads to memory consumption, integer overflow, and heap overflow CVE-2004-0940 is effectively an accidental double increment of a counter that prevents a length check conditional from exiting a loop. CVE-2002-1235 length field of a request not verified CVE-2005-3184 buffer overflow by modifying a length value SECUNIA:18747 length field inconsistency crashes cell phone Probably overlaps other categories including zero-length issues 1000 Weakness ChildOf 118 Length Parameter Inconsistency All Implementation 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 uses externally-controlled format strings in printf-style functions, which can lead to buffer overflows or data representation problems. logging, errors, general output Very High Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Memory Confidentiality: Format string problems allow for information disclosure which can severely simplify exploitation of the program. Access Control: Format string problems can result in the execution of arbitrary code. Requirements specification: Choose a language which is not subject to this flaw. Implementation: Ensure that all format string functions are passed a static string which cannot be controlled by the user and that the proper number of arguments are always sent to that function as well. If at all possible, do not use the %n operator in format strings. Build: Heed the warnings of compilers and linkers, since they may alert you to improper usage. The following example is exploitable, due to the printf() call in the printWrapper() function. Note: The stack buffer was added to make exploitation more simple. C ]]> The following code copies a command line argument into a buffer using snprintf(). This code allows an attacker to view the contents of the stack and write to the stack using a command line argument containing a sequence of formatting directives. The attacker can read from the stack by providing more formatting directives, such as %x, than the function takes as arguments to be formatted. (In this example, the function takes no arguments to be formatted.) By using the %n formatting directive, the attacker can write to the stack, causing snprintf() to write the number of bytes output thus far to the specified argument (rather than reading a value from the argument, which is the intended behavior). A sophisticated version of this attack will use four staggered writes to completely control the value of a pointer on the stack. Certain implementations make more advanced attacks even easier by providing format directives that control the location in memory to read from or write to. An example of these directives is shown in the following code, written for glibc: This code produces the following output: 5 9 5 5 It is also possible to use half-writes (%hn) to accurately control arbitrary DWORDS in memory, which greatly reduces the complexity needed to execute an attack that would otherwise require four staggered writes, such as the one mentioned in the first example. CVE-2002-1825 format string in Perl program CVE-2001-0717 format string in bad call to syslog function CVE-2002-0573 format string in bad call to syslog function CVE-2002-1788 format strings in NNTP server responses CVE-2007-2027 Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages While Format String vulnerabilities typically fall under the Buffer Overflow category, technically they are not overflowed buffers. The Format String vulnerability is fairly new (circa 1999) and stems from the fact that there is no realistic way for a function that takes a variable number of arguments to determine just how many arguments were passed in. The most common functions that take a variable number of arguments, including C-runtime functions, are the printf() family of calls. The Format String problem appears in a number of ways. A *printf() call without a format specifier is dangerous and can be exploited. For example, printf(input); is exploitable, while printf(y, input); is not exploitable in that context. The result of the first call, used incorrectly, allows for an attacker to be able to peek at stack memory since the input string will be used as the format specifier. The attacker can stuff the input string with format specifiers and begin reading stack values, since the remaining parameters will be pulled from the stack. Worst case, this improper use may give away enough control to allow an arbitrary value (or values in the case of an exploit program) to be written into the memory of the running program Frequently targeted entities are file names, process names, identifiers Format string problems are a classic C/C++ issue that are now rare due to the ease of discovery. The reason format string vulnerabilities can be exploited is due to the %n operator. The %n operator will write the number of characters, which have been printed by the format string therefore far, to the memory pointed to by its argument. Through skilled creation of a format string, a malicious user may use values on the stack to create a write-what-where condition. Once this is achieved, he can execute arbitrary code. Format string issues are under-studied for languages other than C. Memory or disk consumption, control flow or variable alteration, and data corruption may result from format string exploitation in applications written in other languages such as Perl, PHP, Python, etc. Since format strings often occur in rarely-occurring erroneous conditions, it is highly that many latent issues exist in executables that do not have associated source code (or equivalent source). Steve Christey Format String Vulnerabilities in Perl Programs http://www.securityfocus.com/archive/1/418460/30/0/threaded Hal Burch Robert C. Seacord Programming Language Format String Vulnerabilities http://www.ddj.com/dept/security/197002914 Tim Newsham Format String Attacks Guardent September 2000 http://www.lava.net/~newsham/format-string-attacks.pdf 1000 Category ChildOf 133 1000 Weakness ChildOf 74 1000 Weakness PeerOf 123 630 View ChildOf 630 631 Category ChildOf 633 635 View ChildOf 635 Format string vulnerability Format String Format string problem All Implementation 67 A weakness where the code path has: 1. start statement that accepts input 2. end statement that passes a format to format output function where a. the input data is part of the format and b. the format is undesirable Where “undesirable” is defined through the following scenarios: 1. not validated 2. incorrectly validated 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++ Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal." Memory Overwrite sensitive data in memory prior to clearing. Where possible, encrypt sensitive data that are used by a software system. The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset(). The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++® .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system. It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency. Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts. Compiler optimization errors occur when: 1. Secret data are stored in memory. 2. The secret data are scrubbed from memory by overwriting its contents. 3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently. This is also an interaction error. This can be hard to diagnose. Michael Howard When scrubbing secrets in memory doesn't work BugTraq 2002-11-05 http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure10102002.asp Joseph Wagner GNU GCC: Optimizer Removes Code Necessary for Security Bugtraq 2002-11-16 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-11/0257.html 1000 Category ChildOf 503 1000 Weakness CanAlsoBe 435 631 Category ChildOf 633 Insecure Compiler Optimization Sensitive memory uncleared by compiler optimization .NET The software does not properly sanitize delimiters. Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 138 Delimiter Problems 15 One or more system settings or configuration elements can be externally controlled by a user. Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious, ways. Compartmentalize your system and determine where the trust boundaries exist. Any input/control outside the trust boundary should be treated as potentially hostile. Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control. In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker. The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine. C Although a process must be privileged to successfully invoke sethostid(), unprivileged users may be able to invoke the program. The code in this example allows user input to directly control the value of a system setting. If an attacker provides a malicious value for host ID, the attacker can misidentify the affected machine on the network or cause other unintended behavior. The following Java code snippet reads a string from an HttpServletRequest and sets it as the active catalog for a database Connection. Java In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database. Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application. 1000 Weakness ChildOf 610 1000 Category ChildOf 2 Setting Manipulation 13 76 77 69 The software does not handle when an expected special element (character or reserved word) is missing. Developers should anticipate that special elements will be removed in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-1362 Crash via message type without separator character CVE-2002-0729 Missing special character (separator) causes crash CVE-2002-1532 HTTP GET without \r\n\r\n CRLF sequences causes product to wait indefinitely and prevents other users from accessing it This can overlap incomplete input. 1000 Weakness ChildOf 159 Missing Special Element All The software does not handle when an additional unexpected special element (character or reserved word) is used. Developers should anticipate that extra special elements will be injected in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2000-0116 Extra "<" in front of SCRIPT tag. CVE-2001-1157 Extra "<" in front of SCRIPT tag. CVE-2002-2086 "<script" - probably a cleansing error 1000 Weakness ChildOf 159 Extra Special Element All The software does not handle when an inconsistency exists between two or more special characters or reserved words, e.g. if paired characters appear in the wrong order, or if the special characters are not properly nested. Developers should anticipate that inconsistent special elements will be injected/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 159 Inconsistent Special Elements All 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 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 Software needs to validate data at the proper time, after data has been canonicalized and cleansed. Early validation is susceptible to various manipulations that result in dangerous inputs that are produced by canonicalization and cleansing. Validate data after attempts to canonicalize the resource name. Since early validation errors usually arise from improperly implemented defensive mechanisms, it is likely that these will be reported more frequently as secure programming becomes implemented more widely. These errors are mostly reported in path traversal vulnerabilities, but the concept applies anyplace where filtering occurs. 1000 Category ChildOf 171 1000 Weakness ChildOf 693 Early Validation Errors All 71 3 43 Software cleanses or filters data in a way that causes the data to "collapse" into an unsafe value. Validate data after attempts to canonicalize. 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-2004-0815 "/.////" in pathname collapses to absolute path. CVE-2005-3123