Memory safety#Impact

Memory errors were first considered in the context of resource management (computing) and time-sharing systems, in an effort to avoid problems such as fork bombs.{{Cite web |last=Anderson |first=James P. |date=October 1972 |title=Computer Security Planning Study |url=https://seclab.cs.ucdavis.edu/projects/history/papers/ande72.pdf}} Developments were mostly theoretical until the Morris worm, which exploited a buffer overflow in fingerd.{{cite book|last1=van der Veen|first1=Victor|last2=dutt-Sharma|first2=Nitish|last3=Cavallaro|first3=Lorenzo|last4=Bos|first4=Herbert|title=Research in Attacks, Intrusions, and Defenses |chapter=Memory Errors: The Past, the Present, and the Future |series=Lecture Notes in Computer Science |volume=7462|pages=86–106|doi=10.1007/978-3-642-33338-5_5|chapter-url=https://www.isg.rhul.ac.uk/sullivan/pubs/tr/technicalreport-ir-cs-73.pdf|accessdate=13 March 2017|year=2012|isbn=978-3-642-33337-8}} The field of computer security developed quickly thereafter, escalating with multitudes of new attacks such as the return-to-libc attack and defense techniques such as the non-executable stack{{cite web|last1=Wojtczuk|first1=Rafal|title=Defeating Solar Designer's Non-executable Stack Patch|url=http://insecure.org/sploits/non-executable.stack.problems.html|website=insecure.org|accessdate=13 March 2017}} and address space layout randomization. Randomization prevents most buffer overflow attacks and requires the attacker to use heap spraying or other application-dependent methods to obtain addresses, although its adoption has been slow. However, deployments of the technology are typically limited to randomizing libraries and the location of the stack.

In 2019, a Microsoft security engineer reported that 70% of all security vulnerabilities were caused by memory safety issues.{{cite web |title=Microsoft: 70 percent of all security bugs are memory safety issues |url=https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ |website=ZDNET |access-date=21 September 2022 |language=en}} In 2020, a team at Google similarly reported that 70% of all "severe security bugs" in Chromium were caused by memory safety problems. Many other high-profile vulnerabilities and exploits in critical software have ultimately stemmed from a lack of memory safety, including Heartbleed{{cite web |url=https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 |title=CVE-2014-0160 |website=Common Vulnerabilities and Exposures |publisher=Mitre |language=en |access-date=8 February 2018 |archive-date=24 January 2018 |archive-url=https://web.archive.org/web/20180124041203/https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160 |url-status=live}} and a long-standing privilege escalation bug in sudo.{{cite web |last1=Goodin |first1=Dan |title=Serious flaw that lurked in sudo for 9 years hands over root privileges |url=https://arstechnica.com/information-technology/2020/02/serious-flaw-that-lurked-in-sudo-for-9-years-finally-gets-a-patch/ |website=Ars Technica |language=en-us |date=4 February 2020}} The pervasiveness and severity of vulnerabilities and exploits arising from memory safety issues have led several security researchers to describe identifying memory safety issues as "shooting fish in a barrel".{{cite web |title=Fish in a Barrel |url=https://fishinabarrel.github.io/ |website=fishinabarrel.github.io |access-date=21 September 2022}}

Some modern high-level programming languages are memory-safe by default{{Citation needed|date=May 2023}}, though not completely since they only check their own code and not the system they interact with. Automatic memory management in the form of garbage collection is the most common technique for preventing some of the memory safety problems, since it prevents common memory safety errors like use-after-free for all data allocated within the language runtime.{{cite web |last1=Crichton |first1=Will |title=CS 242: Memory safety |url=https://stanford-cs242.github.io/f19/lectures/06-2-memory-safety.html |website=stanford-cs242.github.io |access-date=22 September 2022}} When combined with automatic bounds checking on all array accesses and no support for raw pointer arithmetic, garbage collected languages provide strong memory safety guarantees (though the guarantees may be weaker for low-level operations explicitly marked unsafe, such as use of a foreign function interface). However, the performance overhead of garbage collection makes these languages unsuitable for certain performance-critical applications.

For languages that use manual memory management, memory safety is not usually guaranteed by the runtime. Instead, memory safety properties must either be guaranteed by the compiler via static program analysis and automated theorem proving or carefully managed by the programmer at runtime. For example, the Rust programming language implements a borrow checker to ensure memory safety,{{cite web|title=References|url=https://doc.rust-lang.org/beta/nomicon/references.html|website=The Rustonomicon|publisher=Rust.org|accessdate=13 March 2017|language=en}} while C and C++ provide no memory safety guarantees. The substantial amount of software written in C and C++ has motivated the development of external static analysis tools like Coverity, which offers static memory analysis for C.{{cite journal|last1=Bessey|first1=Al|last2=Engler|first2=Dawson|last3=Block|first3=Ken|last4=Chelf|first4=Ben|last5=Chou|first5=Andy|last6=Fulton|first6=Bryan|last7=Hallem|first7=Seth|last8=Henri-Gros|first8=Charles|last9=Kamsky|first9=Asya|last10=McPeak|first10=Scott|title=A few billion lines of code later|journal=Communications of the ACM|date=1 February 2010|volume=53|issue=2|pages=66–75|doi=10.1145/1646353.1646374|s2cid=2611544 |doi-access=}}

DieHard,{{cite book|last1=Berger|first1=Emery D.|last2=Zorn|first2=Benjamin G.|title=Proceedings of the 27th ACM SIGPLAN Conference on Programming Language Design and Implementation |chapter=DieHard: Probabilistic memory safety for unsafe languages |date=1 January 2006|pages=158–168|doi=10.1145/1133981.1134000|chapter-url=http://www.cs.umass.edu/~emery/pubs/fp014-berger.pdf|accessdate=14 March 2017|publisher=ACM|isbn=1595933204 |s2cid=8984358|language=en}} its redesign DieHarder,{{cite book|last1=Novark|first1=Gene|last2=Berger|first2=Emery D.|title=Proceedings of the 17th ACM conference on Computer and communications security |chapter=DieHarder: Securing the heap |date=1 January 2010|pages=573–584|doi=10.1145/1866307.1866371|chapter-url=https://people.cs.umass.edu/~emery/pubs/ccs03-novark.pdf|accessdate=14 March 2017|publisher=ACM|isbn=9781450302456 |s2cid=7880497}} and the Allinea Distributed Debugging Tool are special heap allocators that allocate objects in their own random virtual memory page, allowing invalid reads and writes to be stopped and debugged at the exact instruction that causes them. Protection relies upon hardware memory protection and thus overhead is typically not substantial, although it can grow significantly if the program makes heavy use of allocation.{{cite web|url=https://www.allinea.com/user-guide/DDTMemoryDebugging.html|title=Memory Debugging in Allinea DDT|url-status=dead|archiveurl=https://web.archive.org/web/20150203130856/https://www.allinea.com/user-guide/DDTMemoryDebugging.html|archivedate=2015-02-03}} Randomization provides only probabilistic protection against memory errors, but can often be easily implemented in existing software by relinking the binary.

The memcheck tool of Valgrind uses an instruction set simulator and runs the compiled program in a memory-checking virtual machine, providing guaranteed detection of a subset of runtime memory errors. However, it typically slows the program down by a factor of 40,{{cite web|last1=Gyllenhaal|first1=John|title=Using Valgrind's Memcheck Tool to Find Memory Errors and Leaks|url=https://computing.llnl.gov/code/memcheck/|website=computing.llnl.gov|accessdate=13 March 2017|archive-url=https://web.archive.org/web/20181107004639/https://computing.llnl.gov/code/memcheck/|archive-date=7 November 2018|url-status=dead}} and furthermore must be explicitly informed of custom memory allocators.{{cite web|title=Memcheck: a memory error detector|url=http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools|website=Valgrind User Manual|publisher=valgrind.org|accessdate=13 March 2017|language=en}}{{cite web|last1=Kreinin|first1=Yossi|title=Why custom allocators/pools are hard|url=http://yosefk.com/blog/why-custom-allocatorspools-are-hard.html|website=Proper Fixation|accessdate=13 March 2017}}

With access to the source code, libraries exist that collect and track legitimate values for pointers ("metadata") and check each pointer access against the metadata for validity, such as the Boehm garbage collector.{{cite web|title=Using the Garbage Collector as Leak Detector|url=http://www.hboehm.info/gc/leak.html|website=www.hboehm.info|accessdate=14 March 2017|language=en-us}} In general, memory safety can be safely assured using tracing garbage collection and the insertion of runtime checks on every memory access; this approach has overhead, but less than that of Valgrind. All garbage-collected languages take this approach. For C and C++, many tools exist that perform a compile-time transformation of the code to do memory safety checks at runtime, such as CheckPointer{{cite web|title=Semantic Designs: CheckPointer compared to other safety checking tools|url=http://www.semanticdesigns.com/Products/MemorySafety/MemorySafetyComparison.html|website=www.semanticdesigns.com|publisher=Semantic Designs, Inc.}} and AddressSanitizer which imposes an average slowdown factor of 2.{{cite web|title=AddressSanitizerPerformanceNumbers

|website=GitHub|url=https://github.com/google/sanitizers/wiki/AddressSanitizerPerformanceNumbers}}

BoundWarden is a new spatial memory enforcement approach that utilizes a combination of compile-time transformation and runtime concurrent monitoring techniques.{{Cite journal |last=Dhumbumroong |first=Smith |date=2020 |title=BoundWarden: Thread-enforced spatial memory safety through compile-time transformations |journal=Science of Computer Programming |volume=198 |pages=102519|doi=10.1016/j.scico.2020.102519 |s2cid=224925197 }}

Fuzz testing is well-suited for finding memory safety bugs and is often used in combination with dynamic checkers such as AddressSanitizer.

Many different types of memory errors can occur:{{cite web|last1=Gv|first1=Naveen|title=How to Avoid, Find (and Fix) Memory Errors in your C/C++ Code|url=http://www.cprogramming.com/tutorial/memory_debugging_parallel_inspector.html|website=Cprogramming.com|accessdate=13 March 2017}}{{cite web|title=CWE-633: Weaknesses that Affect Memory|url=https://cwe.mitre.org/data/definitions/633.html|website=Community Weakness Enumeration|publisher=MITRE|accessdate=13 March 2017|language=en}}

• Spatial
• 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.
• Buffer over-read – out-of-bound reads can reveal sensitive data or help attackers bypass address space layout randomization.
• Temporal
• Use after free – dereferencing a dangling pointer storing the address of an object that has been deleted.
• Double free – repeated calls to free may prematurely free a new object at the same address. If the exact address has not been reused, other corruption may occur, especially in allocators that use free lists.
• Uninitialized variables – a variable that has not been assigned a value is used. It may contain sensitive information or bits that are not valid for the type.
• 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.
• Invalid free – passing an invalid address to free can corrupt the heap.
• Mismatched free – when multiple allocators are in use, attempting to free memory with a deallocation function of a different allocator{{cite web |title=CWE-762: Mismatched Memory Management Routines |url=https://cwe.mitre.org/data/definitions/762.html |accessdate=13 March 2017 |website=Community Weakness Enumeration |publisher=MITRE |language=en}}

Depending on the language and environment, other types of bugs can contribute to memory unsafety:

• Stack exhaustion – occurs when a program runs out of stack space, typically because of too deep recursion. A guard page typically halts the program, preventing memory corruption, but functions with large stack frames may bypass the page, and kernel code may not have the benefit of guard pages.
• Heap exhaustion – the program tries to allocate more memory than the amount available. In some languages, this condition must be checked for manually after each allocation.
• Memory leak – Failing to return memory to the allocator may set the stage for heap exhaustion (above). Failing to run the destructor of an RAII object may lead to unexpected results,{{cite web | url=https://doc.rust-lang.org/stable/reference/destructors.html#not-running-destructors | title=Destructors - the Rust Reference }}{{cite web | url=https://doc.rust-lang.org/nomicon/leaking.html | title=Leaking - the Rustonomicon }}
• Null pointer dereference – A null pointer dereference will often 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. In C++, because dereferencing a null pointer is undefined behavior, compiler optimizations may cause other checks to be removed, leading to vulnerabilities elsewhere in the code.{{Cite web |title=Security flaws caused by compiler optimizations |url=https://www.redhat.com/en/blog/security-flaws-caused-compiler-optimizations |access-date=2024-06-26 |website=www.redhat.com |language=en}}{{Cite web |title=NVD - CVE-2009-1897 |url=https://nvd.nist.gov/vuln/detail/CVE-2009-1897 |access-date=2024-06-26 |website=nvd.nist.gov}}

Some lists may also include race conditions (concurrent reads/writes to shared memory) as being part of memory safety (e.g., for access control). The Rust programming language prevents many kinds of memory-based race conditions by default, because it ensures there is at most one writer or one or more readers. Many other programming languages, such as Java, do not automatically prevent memory-based race conditions, yet are still generally considered "memory safe" languages. Therefore, countering race conditions is generally not considered necessary for a language to be considered memory safe.

{{Reflist}}

{{Memory management navbox}}

Category:Software bugs

Category:Computer security exploits

Category:Programming language implementation