Weakness · High
CWE-476: NULL Pointer Dereference
What it is
The product dereferences a pointer that it expects to be valid but is NULL.
- Severity (our rating)
- High
- Likelihood of exploit
- Medium
- Introduced during
- Implementation
- Exploited in the wild
- 1 known exploited CVE
What an attacker can do
- DoS: Crash, Exit, or Restart (Availability)
- Execute Unauthorized Code or Commands (Integrity, Confidentiality)
- Read Memory (Integrity, Confidentiality)
- Modify Memory (Integrity, Confidentiality)
How to prevent it
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.
- Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
- Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
Requirements
- Select a programming language that is not susceptible to these issues.
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.
How to find it
- 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++.
Exploited in the wild: 1 CVE
Vulnerabilities caused by CWE-476 that attackers have used, from CISA's Known Exploited Vulnerabilities catalog, newest first.
H2 Security
Found it in your code?
We review where it appears, fix it with your team, and check it was not already used against you.
Talk to our teamT Academy
Stop writing it in the first place
Learn to build software and systems without weaknesses like this one, with practice on real hosts in your browser, every objective checked on the machine.
Start freeSource: MITRE Common Weakness Enumeration, CWE version 4.19.1. CWE is a trademark of The MITRE Corporation.