CWE-476 Detail

The product dereferences a pointer that it expects to be valid but is NULL.

Modes Of Introduction

Implementation

Applicable Platforms

Language

Name: C (Undetermined)
Name: C++ (Undetermined)
Name: Java (Undetermined)
Name: C# (Undetermined)
Name: Go (Undetermined)

Common Consequences

Observed Examples

Potential Mitigations

Phases : Implementation
If all pointers that could have been modified are checked for NULL before use, nearly all NULL pointer dereferences can be prevented.
Phases : Requirements
Select a programming language that is not susceptible to these issues.
Phases : Implementation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Phases : 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.
Phases : Implementation
Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.

Detection Methods

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.
Effectiveness : Moderate

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.)
Effectiveness : High

Vulnerability Mapping Notes

Rationale : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

REF-6

Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, Gary McGraw.
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf

REF-18

The CLASP Application Security Process
Secure Software, Inc..
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf

REF-1031

Null pointer / Null dereferencing
https://en.wikipedia.org/wiki/Null_pointer#Null_dereferencing

REF-1032

Null Reference Creation and Null Pointer Dereference
https://developer.apple.com/documentation/xcode/null-reference-creation-and-null-pointer-dereference

REF-1033

NULL Pointer Dereference [CWE-476]
https://www.immuniweb.com/vulnerability/null-pointer-dereference.html

Submission

Modifications