CWE-476: NULL Pointer Dereference

Causes

• 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. 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).
• In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a NULL pointer exception when it attempts to call the trim() method.
• This Android application has registered to handle a URL when sent an intent: The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.
• Consider the following example of a typical client server exchange. The HandleRequest function is intended to perform a request and use a defer to close the connection whenever the function returns. If a user supplies a malformed request or violates the client policy, the Do method can return a nil response and a non-nil err.,This HandleRequest Function evaluates the close before checking the error. A deferred call's arguments are evaluated immediately, so the defer statement panics due to a nil response.

Remediation

• Implementation: For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
• Requirements: Select a programming language that is not susceptible to these issues.
• Implementation: Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
• Architecture and Design: Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
• Implementation: Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.

Detection

• Automated Dynamic Analysis: This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
• Manual Dynamic Analysis: Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.
• Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
• Automated Dynamic Analysis: Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].

Related CWEs

• CWE-1325: Improperly Controlled Sequential Memory Allocation
• CWE-252: Unchecked Return Value
• CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
• CWE-710: Improper Adherence to Coding Standards
• CWE-754: Improper Check for Unusual or Exceptional Conditions
• CWE-754: Improper Check for Unusual or Exceptional Conditions
• CWE-789: Memory Allocation with Excessive Size Value

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.