Memory safety

This article is about protection of memory in software development. For hardware protection of memory, see Memory protection.

Memory safety is a concern in software development that aims to avoid software bugs that cause security vulnerabilities dealing with random-access memory (RAM) access, such as buffer overflows and dangling pointers.

Computer languages such as C and C++ that support arbitrary pointer arithmetic, casting, and deallocation are typically not memory safe. There are several approaches to find errors in such languages: see the Detection section below.

Most high-level programming languages avoid the problem by disallowing pointer arithmetic and casting entirely, and by enforcing tracing garbage collection as the sole memory management scheme.

A language could support even more uses of pointer arithmetic, casting, and deallocation without sacrificing memory safety by using automated theorem proving as a form of static code analysis. ESC/Java with JML demonstrates a way that programmers can declare their invariants in ways that can be understood by a theorem prover.

Types of memory errors

Several types of memory errors can occur, depending on the programming language used:

• Buffer overflow - out-of bound writes can corrupt the content of adjacent objects, or internal data (like bookkeeping information for the heap) or return addresses.
• Dynamic memory errors - incorrect management of dynamic memory and pointers:
  • Dangling pointer - a pointer storing the address of an object that has been deleted.
  • Double frees - repeated calls to free though the object has been already freed can cause freelist-based allocators to fail.
  • Invalid free - passing an invalid address to free can corrupt the heap or sometimes lead to undefined behavior.
  • Null pointer accesses will cause an exception or program termination in most environments, but can cause corruption in operating system kernels or systems without memory protection, or when use of the null pointer involves a large or negative offset.
• Uninitialized variables - a variable that has not been assigned a value is used. It may contain an undesired or, in some languages, a corrupt value.
  • Wild pointers arise when a pointer is used prior to initialization to some known state. They show the same erratic behaviour as dangling pointers, though they are less likely to stay undetected.
• Out-of-memory errors are sometimes treated as violations of memory safety:
  • Stack overflow - occurs when a program runs out of stack space, typically because of too deep recursion.
  • Allocation failures - the program tries to use more memory than the amount available. In some languages, this condition must be checked for manually after each allocation.

Detection

There are many ways to detect memory errors in programs written in unsafe languages:

• By using special heap allocators that provide dead zones around heap allocated storage and check that accesses don't reach into such dead zones. DieHard and the Allinea Distributed Debugging Tool do this by allocating objects in their own virtual memory page, allowing invalid reads and writes to be stopped and debugged at the exact instruction that causes them.
• Dangling pointers can be trapped using hardware memory protection to stop and debug processes as soon as they try to access memory that has been freed.
• By instrumenting the source code. Tools like SoftBound, CheckPointer and AddressSanitizer do this to collect and track legitimate values for pointers ("metadata") and check each pointer access against the metadata for validity.
• By running the compiled program in a memory-checking virtual machine. The memcheck tool of Valgrind works this way.
• Static code analysis can detect errors in some cases as well.
• By use of an instruction set simulator incorporating memory protection as part of its debugger, such as IBM OLIVER (CICS interactive test/debug)