CWE-754: Improper Check for Unusual or Exceptional Conditions
Presentation Filter:
 DescriptionThe software does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the software. Extended DescriptionThe programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability. Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
 Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
Background Details Modes Of IntroductionThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Likelihood Of ExploitMedium Demonstrative ExamplesExample 1 Consider the following code segment: (bad code) Example Language: C char buf[10], cp_buf[10];
fgets(buf, 10, stdin); strcpy(cp_buf, buf); 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(). (bad code) Example Language: C buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size); 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:
Example 3 The following examples read a file into a byte array. (bad code) Example Language: C# char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) { String userName = (String) i.Current(); }String pFileName = PFILE_ROOT + "/" + userName; StreamReader sr = new StreamReader(pFileName); sr.Read(byteArray,0,1024);//the file is always 1k bytes sr.Close(); processPFile(userName, byteArray); (bad code) Example Language: Java FileInputStream fis;
byte[] byteArray = new byte[1024]; for (Iterator i=users.iterator(); i.hasNext();) { String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName; FileInputStream fis = new FileInputStream(pFileName); fis.read(byteArray); // the file is always 1k bytes fis.close(); processPFile(userName, byteArray); The 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 treat 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. (bad code) Example Language: Java String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) { ... }... The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference. (bad code) Example Language: Java String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) { ... }... 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. (bad code) Example Language: Java System.clearProperty("os.name");
... String os = System.getProperty("os.name"); if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported"); 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 6 The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value. (bad code) Example Language: C# Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte MyFile.Read(MyArray, 0, 50) DoDangerousOperation(MyArray(20)) In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. 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. Example 7 This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer. (bad code) Example Language: C void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr; char hostname[64]; in_addr_t inet_addr(const char *cp); /*routine that ensures user_supplied_addr is in the right format for conversion */ validate_addr_form(user_supplied_addr); addr = inet_addr(user_supplied_addr); hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET); strcpy(hostname, hp->h_name); If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy(). Note that this code is also vulnerable to a buffer overflow (CWE-119). Example 8 In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively. (bad code) Example Language: C++ int outputStringToFile(char *output, char *filename) {
openFileToWrite(filename); writeToFile(output); closeFile(filename); However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example. (good code) Example Language: C++ int outputStringToFile(char *output, char *filename) {
int isOutput = SUCCESS;
int isOpen = openFileToWrite(filename); if (isOpen == FAIL) { printf("Unable to open file %s", filename); }isOutput = FAIL; else { int isWrite = writeToFile(output);
if (isWrite == FAIL) { printf("Unable to write to file %s", filename); }isOutput = FAIL; int isClose = closeFile(filename); if (isClose == FAIL) isOutput = FAIL;
return isOutput; Example 9 In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method. (bad code) Example Language: Java private File readFile = null;
public void setInputFile(String inputFile) { // create readFile File object from string containing name of file public void readFromFile() { try {
reader = new FileReader(readFile);
// read input file However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code. (good code) Example Language: Java private File readFile = null;
public void setInputFile(String inputFile) { // create readFile File object from string containing name of file public void readFromFile() { try {
if (readFile == null) {
System.err.println("Input file has not been set, call setInputFile method before calling openInputFile"); }throw NullPointerException; reader = new FileReader(readFile); // read input file catch (NullPointerException ex) {...} Observed Examples
Potential Mitigations
Detection Methods
MembershipsThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NotesRelationship Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value. Taxonomy Mappings
References
Content History
More information is available — Please select a different filter. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Use of the Common Weakness Enumeration (CWE) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006-2021, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. |
|
