Difference between revisions of "Null-pointer dereference"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to www.textlarolbodron.com)
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Template:SecureSoftware}}
+
{{template:CandidateForDeletion}}
 +
 
 +
#REDIRECT [[::Category:Vulnerability]]
 +
 
 +
 
  
 
==Overview==
 
==Overview==
Line 72: Line 76:
  
 
* [[State synchronization error]]
 
* [[State synchronization error]]
 
 
[[Category:Vulnerability]]
 
 
[[Category:Range and Type Errors]]
 
 
[[Category:OWASP_CLASP_Project]]
 

Revision as of 13:28, 27 May 2009


This page was marked to be reviewed for deletion.


#REDIRECT :Category:Vulnerability


Contents

Overview

A null-pointer dereference takes place when a pointer with a value of NULL is used as though it pointed to a valid memory area.

Consequences

  • Availability: Null-pointer dereferences invariably result in the failure of the process.

Exposure period

  • Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  • Implementation: Proper sanity checks at implementation time can serve to prevent null-pointer dereferences

Platform

  • Languages: C, C++, Assembly
  • Platforms: All

Required resources

Any

Severity

Medium

Likelihood of exploit

Medium

Avoidance and mitigation

  • Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  • Implementation: If all pointers that could have been modified are sanity-checked previous to use, nearly all null-pointer dereferences can be prevented.

Discussion

Null-pointer dereferences, while common, can generally be found and corrected in a simply way. They will always result in the crash of the process - unless exception handling (on some platforms) in invoked, and even then, little can be done to salvage the process.

Examples

Null-pointer dereference issue can occur through a number of flaws, including race conditions, and simple programming omissions. While there are no complete fixes aside from contentious programming, the following steps will go a long way to ensure that null-pointer dereferences do not occur.

Before using a pointer, ensure that it is not equal to NULL:

if (pointer1 != NULL) {
  /* make use of pointer1 */
  /* ... */
}

When freeing pointers, ensure they are not set to NULL, and be sure to set them to NULL once they are freed:

if (pointer1 != NULL) {
  free(pointer1);
  pointer1 = NULL;
}

If you are working with a multi-threaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished.

Related problems