History of memory corruption attacks (1972 to 2005)

In this article, we take a look at memory corruption attacks, examining their various uses, attacks and mitigations. In particular, we'll be focusing on stack overflow, which was most common in the late 90s and early 2000s.

It's important to note that this non-exhaustive review is limited to the Western perimeter and vision. It does not take into account the Russian or Chinese vision.

Memory allocation reminder

On a linux x86 system, each program, when executed, is allocated a fully isolated memory space using the virtual memory principle. Memory is addressed in words (4 bytes) and covers the address space 0x00000000 - 0xffffffff, i.e. 4 addressable gigabytes.

Virtual space is divided into two zones: user space (0x00000000 - 0xbfffffff) and kernel space (0xc0000000 - 0xffffffff). A user process cannot access kernel space, but the reverse is possible. An ELF executable is transformed into a process image by the program loader.
To create this memory image, the program loader will map all loadable segments of the executable and the required libraries into memory using the mmap() system call. Executables are loaded at the fixed memory address 0x08048000, known as the "base address".

The figure (above) shows the main sections of a program in memory. The .text'' section of the figure corresponds to the **program code**, i.e. the instructions. The.data'' section contains initialized global data (whose values are known at compile time) and the .bss'' section contains uninitialized global data. These two areas are reserved and known at compile time. An initialized static local variable is found in the.datasection, and an uninitialized static local variable is found in the.bss`` section.

The stack contains local variables. It operates on the LIFO (Last in First Out) principle, and grows towards the lower memory addresses. When a program is executed, its arguments (argc and argv) and environment variables are also stored on the stack. Variables allocated dynamically by the malloc() function are stored in the heap.

When a function is called, a new stack frame is created above the previous one to designate the function's memory space.

It therefore contains :

• local variables,
• save the base pointer of the calling function,
• as well as a saved EIP return address that indicates where to continue execution after the function.

Buffer overflow

A buffer overflow occurs when data written to a buffer also corrupts memory addresses adjacent to the destination buffer due to insufficient boundary checking. This can occur when data is copied from one buffer to another without first checking that the data fits in the destination buffer.

This overflow makes it possible to rewrite the saved EIP pointer, which will cause execution to be redirected when the function returns and, consequently, a potential takeover of program execution.

**The von Neumann architecture used in most modern computers uses the same hardware for instructions and data.

von Neumann architecture

Architecture contrary to the Harvard type, which physically separates instructions and data.

Harvard Architecture

We're going to explore the history of this type of operation, the different techniques used and the remedies provided over the years.

1972

• The problem has been known since at least 1972 in the "Computer Security Technology Planning Study":

The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine (Page 61).

source

1988

• First mass exploitation in 1988 by the Morris worm, created by a Cornell University student using, among other things, the fingerd service. It was also the first worm to spread via the Internet.

I had heard of the potential for exploits via overflow of the data segment buffers overwriting the next variable. That is, people were worried about code like this:

char buf[512];

int is_authorized; main(){

...;

gets(buf); 

The idea of using buffer overflow to inject code into a program and cause it to jump to that code occured to me while reading fingerd.c.

source

In response to the worm, the first CERT was created by Carnegie Mellon University.

1989

• ZARDOZ Security-Digest list is created where several people discuss different vulnerabilities source

• CERT publishes a vulnerability alert about an overflow in 4.3BSD bin/passwd.c source

1993

• Bugtraq was created in response to CERT's failure to publish vulnerabilities, and to vendors' failure to patch their programs. This was the beginning of the "full disclosure" movement. Bugtraq was an electronic mailing list devoted to computer security issues. Topics included new discussions on vulnerabilities, security announcements from vendors, exploit methods and how to patch them. It was a high-volume mailing list, with up to 776 messages per month, and almost all new security vulnerabilities were discussed on the list in its early days. The forum allowed anyone to disclose and discuss computer vulnerabilities, including security researchers and product vendors.

1995

• Thomas Lopatic posts on Bugtraq a buffer overflow of NCSA httpd 1.3. The post details the steps required to operate the service, as well as a POC (Proof Of Concept) that creates the /tmp/GOTCHA file.

Actually, this bug is similar to the bug in fingerd exploited by the internet worm. The HTTPD reads a maximum of 8192 characters when accepting a request from port 80. When parsing the URL part of the request a buffer with a size of 256 characters is used to prepend the document root (function strsubfirst(), called from translate_name()). Thus we are able to overwrite the data after the buffer. Since the stack grows towards higher addresses on the HP-PA, we are able to overwrite the return pointer which is used to return from the strcpy() call in strsubfirst(). The strcpy() overwrites its own return pointer. On systems with a stack growing the other direction, we'd have to overwrite the return pointer of strsubfirst()..

source

• CERT publishes a vulnerability alert for syslogd source

• Mudge from l0pht writes a paper on "How to write Buffer Overflows". These are notes on buffer overflows with an introduction to shellcodes and containing an exploit of the syslogd bug made public earlier. This document was circulated internally and only became public knowledge years later. source

• DaveG and VicM from Avalon Research publish on Bugtraq an alert and exploit for splitvt on Linux 2-3.x. The vulnerability is due to the use of an unbounded sprintf() exploited with a long environment variable. source

1996

• Aleph1 published "Smashing The Stack For Fun And Profit" in Phrack #49, probably one of the most quoted articles on the subject. It had a huge impact when published and was the first high-quality, step-by-step public introduction to stack overflow vulnerabilities and their exploitation. source

*Buffer overflows are well known in 1996, and their exploitation generally consists in taking control of the saved return pointer and returning to its code. The malicious code can be inserted anywhere in memory as long as it can be pointed to at runtime. For example, DaveG and VicM, in their exploit for splitvt, place their shellcode in an environment variable near the end of the stack. Aleph1, in his article, returns to its own buffer after rewriting the execution pointer.

1997

• Solar Designer releases an exploit for Superprobe. Here, a function pointer is rewritten to point to an environment variable, rather than the execution pointer. source

• A few months later, Solar Designer proposes a remediation against exploits that returns and executes code from the stack, rendering it non-executable. (nx stack) At the same time, it publishes a way of bypassing its own patch by returning to shared memory, which is always executable, in this case libc's system() function. (ret-to-libc) Finally, he proposes a patch against this workaround that modifies the way shared library functions are addressed in memory, ensuring that their addresses always contain a null byte. source

• At the end of the year, StackGuard was announced on Bugtrack. This is a patch for gcc that inserts a canary before the function's return address and causes the program to stop if it is modified. source

*1997 is already seeing the arrival of remedies against buffer overflow. Up to now, the principle has been to take control of the return pointer and return to a location on the stack containing our code. The solution proposed by StackGuard is to place, before the frame and return pointers, a value called canary which will be compared with a copy elsewhere in memory before the function returns. If the two values don't match, the program stops.

Solar Designer makes the stack non-executable. This makes it impossible to return to shellcode placed on the stack. A non-executable stack is now considered standard, and we can see in a current binary that the stack is non-executable by default. (stack is rw-)

To counter its own idea, Solar Designer proposes to return to the standard C libc library, which provides macros, type definitions and functions for tasks such as string manipulation, mathematical calculations, I/O processing, memory management and many other operating system services. It is also mapped into memory when the binary is launched, as can be seen in the previous screenshot. It begins by searching for the string "/bin/sh" in libc's memory space and passing a pointer to this string as an argument to the system() function. When the function is executed, the state of the stack is :.

1998

• After a first exploit for Internet Explorer 4 on Windows 95 at the end of 97, Dildog from l0pht is back with a new exploit, this time using a heap overflow. source

• In his Bugtraq post entitled "Defeating Solar Designer non-executable stack patch", Andy Church describes an attack where an override is used to overwrite snprintf parameters to create the first known example of a string format attack. source

• A few months later, Dildog again published "The Tao of Windows Buffer Overflow", which became the bible of Windows operation. source

*1998 saw the public introduction of two new types of attack: heap overflow, which we'll look at in more detail in the second part of this article, and "format string" attacks, described in more detail below.

1999

• sh0k from w00w00 publishes "w00w00 on Heap Overflows", which looks back at the work of its predecessors and the various stages that have brought it to this point. source

• Dark spyrit AKA Barnaby Jack publishes in phrack #55 "Win32 Buffer Overflows (Location, Exploitation and Prevention)". Using a publicly disclosed vulnerability in SLMail 3.2.3113, he demonstrates how to locate the bug using PE Dump and SoftIce and then explains the problems associated with shellcode on Win32 to finally cover the use of trampoline calls that allow reliable return to the beginning of the stack using gadgets in DLLs with fixed addressing. This is also one of the first signs of Bugtraq distancing itself from the accusations that it is no longer 100% full disclosure.

*Seattle Labs were contacted about this in a previous version but did not bother to remedy the situation, instead they just changed the default port from 27 to 8376.

Bad move.

*The vulnerabilities were made public by the way, so please, Russ, don't send me nasty emails.

source

• In the same issue of phrack, klog publishes "The Frame Pointer Overwrite". It demonstrates that, in certain circumstances, rewriting a single byte of the saved frame pointer allows the instruction pointer to be retrieved, when the function returns, from a location defined by the attacker. He also points out that other esoteric techniques are also possible, particularly in the case of loss of privileges. source

• Tymm Twillman publishes on bugtraq an exploit for proftpd 1.2.0pre6 using a string format bug discovered in 1989 by the University of Wisconsin. Format string exploits use the %n format specifier to write to memory when a variable controlled by the attacker is passed directly to a printf function. source

• Taeho Oh publishes "Advanced buffer overflow exploit" where he demonstrates advanced shellcode techniques to bypass certain filters, bypass seteuid(getuid()), escape from chroot(), or open a socket. source

1999 sees the first example of "modern" format string operation. The problem stems from the use of unchecked user input as a format string parameter in certain C functions that perform formatting, such as printf(). A malicious user can use the %s and %x format tokens, among others, to print data from the call stack or other memory locations. He can also write arbitrary data to arbitrary locations using the %n format token, which instructs printf() and similar functions to write the number of formatted bytes to an address stored on the stack. The format token can also be used to write arbitrary data to arbitrary locations using the %n format token, which instructs printf() and similar functions to write the number of formatted bytes to an address stored on the stack.

2000

• Three interesting articles are published in phrack #56:

  • Bulba and Kil3r demonstrate how to reliably bypass StackGuard and StackShield by writing to the Global Offset Table. source (Bypassing StackGuard and StackShield)
  • Rix highlights the possibility of taking control of execution by rewriting a virtual pointer in the virtual method table during a buffer overflow in C++. source (Smashing C++ VPTRs)
  • Twitch explains the possibility of exploiting the fact that certain functions considered safe (here strncpy()) do not terminate strings with a null byte if the buffer size is equal to the number of bytes copied.

The essence of the issue is that many functions that a programmer may take to be safe and/or 'magic bullets' against buffer overflows do not automatically terminate strings/buffers with a NULL. That in actuality, the buffer size argument provided to these functions is an absolute size not the size of the string.

source (Exploiting Non-adjacent Memory Spaces)

• Tf8 publishes its exploit for WU-FTPD 2.6.0 "WuFTPD: Providing remote root since at least1994" developed the previous year, finally drawing attention to string format bugs. source

• Lamagra publishes "Format Bugs: What are they, Where did they come from?", a paper covering most of the available information on format string bugs. source

• Solar Designer publishes "JPEG Com Marker vulnerability in Netscape" demonstrating how to create an image file that will overwrite the heap when decoded by Netscape. This article was the first known to discuss file format bugs that continue to be relevant today. Solar Designer also explains how to reliably execute code when the heap is overrun, using free() and unlink(). source

The image used as a POC to crash the program

• Tim Newsham published his paper "Format String Attacks", the most complete on the nature of the problem and its exploitation.

--[ INTRODUCTION I know it has happened to you. It has happened to all of us, at one point or another. You're at a trendy dinner party, and amidst the frenzied voices of your companions you hear the words "format string attack." "Format string attack? What is a format string attack?" you ask. Afraid of having your ignorance exposed among your peers you decide instead to break an uncomfortable smile and nod in hopes of appearing to be in the know. If all goes well, a few cocktails will pass and the conversation will move on, and no one will be the wiser. Well fear no more! This paper will cover everything you wanted to know about format string attacks but were afraid to ask!

source

• October sees the release of PaX, a security patch for the Linux kernel that provides non-executable memory pages. The first version uses only the PAGEEXEC method.

PAGEEXEC is the first proposed implementation of the NX bit on i386 architectures. The supervisor bit is overloaded to emulate the behavior of the NX bit. This implementation relies on the translation lookaside buffer (TLB), the cache used by the memory management unit. When an attempt is made to access a protected page not yet in the TLB at runtime, a protection fault is raised. As on recent processors, the TLB is separated into a cache for execution (ITLB) and a cache for data (DTLB), PaX can determine whether this is an instruction, which must then be prohibited.

source

• In November, PaX added the MPROTECT method, which prevents the introduction of new executable code into a task's memory space by restricting access to the mmap() and mprotect() interfaces.

• Juan M. Bello Rivas publishes "Overwriting ELF .dtors section to modify program execution" and explains how to take control of program execution by rewriting the constructor (.ctors) or destructor (.dtors) of a function (here main()). The injected code is then executed respectively before or after a call to the function. source

• At the end of the year, Brad Spengler released grsecurity, a security-enhancing patch for the Linux kernel. It includes various elements, including PaX, a role-based access control system, and various ways of strengthening the kernel's overall security.

2001

• eEye Digital Security publishes a security alert about a buffer overflow in an ISAPI extension. The exploit uses a heap spraying technique to execute code on Windows 2000 and NT4. source

• The same company discovers the "Code Red worm", which uses the IIS bug above (MS01-033). After analysis, the worm rewrote a SEH exception handler on the stack. The payload sent by the worm could look like this:

GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0

• PaX introduces random address space distribution (ASLR), which allows addressing to be changed each time the program is started. This means the attacker no longer knows which region to return to when checking the execution pointer.

*The goal of Address Space Layout Randomization is to introduce randomness into addresses used by a given task. This will make a class of exploit techniques fail with a quantifiable probability and also allow their detection since failed attempts will most likely crash the attacked task.

• At the 10th USENIX Security Symposium, StackGhost and FormatGuard are presented. Respectively addressing return pointer rewriting and format string attacks. source | source

• In Prack #57, two articles look back at previous Solar Designer discoveries.

• Once upon a free()..." is an introduction to heap overflow. source

• In "Vudo malloc tricks", MaXX begins by documenting Doug Lea's implementation of malloc() in great detail, as well as the various possible exploitation techniques. He ends the article by demonstrating an exploit using the unlink() technique against sudo-1.6.1-1 under RedHat 6.2.

The present paper could probably have been entitled "Smashing The Heap For Fun And Profit"... indeed, the memory allocator used by the GNU C Library (Doug Lea's Malloc) and the associated heap corruption techniques are presented. However, it was entitled "Vudo , An object superstitiously believed to embody magical powers" since a recent Sudo vulnerability and the associated Vudo exploit are presented as well..

source

• TESO's Scut publishes "Exploiting Format String Vulnerabilities", a comprehensive guide to finding and exploiting format string bugs. source

• In Prack #58, Nergal publishes "Advanced return-into-lib(c) exploits (PaX case study)". The first part covers simple and advanced return-to-libc attacks, some of which were already what we now call Return Oriented Programming (ROP). The second part focuses on ways of bypassing PaX. source

2001 saw the appearance of ASLR, which randomly organizes the address space positions of a process's key data zones, including the executable base and the positions of the stack, heap and libraries. As a result, if an attacker manages to take control of the saved return pointer, it is impossible to know where to return without first leaking information about the process's memory organization.

This is also the release of the first publication to talk about Return Oriented Programming (ROP), which allows the execution of carefully selected sequences of machine instructions already present in the machine's memory, called "gadgets". Each gadget generally ends with a return instruction and is located in a subroutine of the existing program and/or shared library code. Chained together, these gadgets enable an attacker to perform arbitrary operations on a machine employing defenses such as NX..

2002

• Halvar Flake, creator of TESO, presents "Third Generation Exploits on NT/Win2k Platforms" at Blackhat Briefings Windows 2002. He takes the Solar Designer exploit (4 bytes unlink()) and adapts it to Windows. He then documents an attack on Borland's heap allocator and finishes by explaining how SEH attacks work on Windows. This is also the beginning of the end of the full disclosure movement.

Some bug-hunters see bugs as a natural resource which is slowly being depleted - thus the "save the bugs movements" and more push in the underground to keep bugs secret.

source

• Microsoft releases /GS stack protection for Visual C++ 7. Like StackGuard, /GS sets a cookie on the stack before the return address and then calls __security_check_cookie() at the end of the function to validate that the cookie has not been modified. source

• mnemonix (David Litchfield) publishes "Non-stack Based Exploitation of Buffer Overrun Vulnerabilities on Windows NT/2000/XP", documenting return-to-libc attacks on Windows. source

• Tyler Durden publishes in Phrack #59 "Bypassing PaX ASLR protection" where he demonstrates how to leak information using a partial rewrite.

We may want to return-into-write or return-into-any_output_function if there is no printf and no send somewhere near the original return address, but depending on the output function, it would be quite hard to perform the attack since we would have to control many of the vulnerable function parameters.

source

• In the same issue of Phrack, riq and gera publish "Advances in format string exploitation".

This text deals with 2 different subjects. The first is about different tiny tricks that may help speeding up bruteforcing when exploiting format strings bugs, and the second is about exploiting heap based format strings bugs.

source

• Maximiliano Caceres' "Syscall Proxying - Simulating remote execution" demonstrates other ways of weaponizing exploits, by redefining shellcodes, for example for elevation of privileges, or for pivoting. source

• Grsecurity receives a learning mode, which automatically generates individual rules from normal system operation.

• Gera publishes "Four different tricks to bypass StackShield and StackGuard protection" demonstrating how to bypass compiler-level protection. (StackGuard, StackShield and Microsoft /GS) source

• The Slapper worm uses a memory leak to reliably exploit a heap overflow using an OpenSSL bug made public a few months earlier. source

• PaX introduces SEGMEXEC to implement the non-executable memory page feature and RANDKSTACK, which introduces randomness into the kernel stack.

SEGMEXEC emulates the operation of the NX bit on IA-32 processors. It works by segmenting memory into two zones of 1.5 GB each. The lower zone (from 0 to 1.5 GB) contains non-executable data, i.e. data but also instructions (which may indeed want to be read). The second, executable zone, on the other hand, contains only instructions. The mappings of both segments point to the same areas of physical memory, so the RAM used is not doubled. When a memory address is to be executed, it is translated into the area containing the executable code. If the code is not present at the translated address, the program is killed.

• Grsecurity adds protection for /dev/mem and /dev/kmem to prevent writing to kernel memory. Attack known since at least November 1998. source

• Blexim publishes "Basic Integer Overflows" where he discusses and demonstrates integer overflows. source

In 2002, the first public papers on SEH attacks on Windows were published. A SEH record has two parts: a pointer to the next SEH record and a pointer to the exception handler of the current SEH record. So, when the pointer to the current exception handler is overwritten, the pointer to the next exception handler must also be overwritten, as this is directly before the pointer to the current exception handler on the stack. When an exception occurs, the application goes to the current SEH record and executes the handler. So, when we overwrite the handler, we need to place a pointer to something that will take us to our shellcode..

2003

• Release of "pax-future.txt". This often overlooked document details many attacks and preventions that were either rediscovered years later or had not yet been implemented in software. The purpose of the document was to describe the current weaknesses of a system correctly implementing NX/ASLR and their future solutions. The design notes in section 1 classify all attacks against NX/ASLR that have been published and those yet to be published. Section c.1 deals with variants of in-code return techniques (including jmp instructions). Several methods for preventing all forms of these techniques are described. It also introduces for the first time (in section b.1) the concept of what will later be called KERNEXEC. source

• With the release of grsecurity 2.0, a role-based access control (RBAC) system was added. The previous ACL system had subject/object abstractions, and the new RBAC system has added a special user/group/role hierarchy behind these abstractions. It's a complete rewrite, both on the kernel side and on the user side.

• The metasploit.com website opened to the public in June, and version 1.0 of the free, open-source framework was released in October, including 9 exploits.

• PaX introduces non-executable kernel pages.

• David Litchfield publishes "Variations in Exploit methods between Linux and Windows". He refers to a "long-known technique" of overwriting the SEH record in the Windows stack (this is in fact the first known documentation of this attack). source

• Lord YuP from Sec-Labs releases "Win32 Device Drivers Communication Vulnerabilities" concerning memory corruption in device drivers, as well as an exploit for Norton Antivirus.

• David Litchfield publishes "Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server" where he bypasses the protection of registered SEHs by noting that unregistered exception handlers that are out of scope of loaded DLLs were considered valid. source

• Microsoft introduces /SAFESEH in Visual Studio 2003 in an attempt to limit the exploitation of overrun SEH handlers. /GS reorganizes the stack to limit the effects of overruns.

2004

• Matt Conover and Oded Horovitz present "Reliable Windows Heap Exploits", giving an overview of the reliable exploitation techniques available and exposing the protections of the forthcoming Windows XP-SP2. (PEB randomization, security cookies on chunks header, safe unlink from doubly linked list)

• David Litchfield presents "Windows Heap Overflows" at BlackHat USA 2004 on the free attack, which allows 4 bytes to be written anywhere, and potential write targets.

• Microsoft delivers XP-SP2. Windows itself is now compiled with /GS and /SAFESEH. DEP is supported by hardware and software. Heap cookie validation and Safe Unlinking are now included. PEB and TEB are randomized. Pointers are coded. Both stack and heap are marked as non-executable.

• Stanford researchers publish "On the effectiveness of address-space randomization". They demonstrate that the usefulness of ASLR on 32-bit platforms is limited by the number of bits available for randomization. They present an attack that is able to use brute force to determine the stack layout (by returning to sleep()) before launching a return-2-libc exploit on systems with PaX or W^X. source

• Barend-Jan Wever (SkyLined) publishes an "Internet Exploiter" exploit for overflowing Internet Explorer's IFRAME src and name parameters. His exploit uses "Heap Spraying" as an attack vector, filling memory with his code with the aim of returning to it. source

2005

• Alexander Anisimov publishes "Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass" abusing the lack of verification on lookaside lists and gets code execution. source

• Barnaby Jack publishes an article entitled "Remote Windows Kernel Exploitation, Step into the Ring 0", in which he uses, for illustration purposes, a previously disclosed bug in Symantec's personal firewall range. His shellcode example is a remote keylogger and kernel loader that can execute any userland shellcode. source

• The author of PaX (pageexec) publishes a privilege escalation bug in PaX. He calls the bug a "spectacular failure" that "destroys virtually everything PaX has ever stood for and been trusted to do" and attempts to leave the project. (He gives an in-depth explanation of the bug on the DailyDave Mailing List). source

• Symantec's Nicolas Falliere publishes "Critical Section Heap Exploit Technique" detailing a new exploitation technique against XP-SP2's heap protection mechanisms. It exploits a double-linked list overwrite of the critical section. source

• Sebastian Krahmer publishes "Borrowed Code Chunk Exploitation Technique", aimed specifically at x86-64 systems. The article effectively describes what would later be called return-oriented programming (ROP) to bypass DEP/NX/AVP. source

• In Uninformed Journal 2, Matt Miller (skape) and Ken Johnson (skywing) publish a technique for bypassing hardware DEP using a return-2-libc attack to return to functions that disable DEP. (ZwProtectVirtualMemory or NtSetInformationProcess) source

• Visual Studio 2005 comes with the strict GS pragma. /GS is now in version 2 and makes a hidden copy of argument parameters. It also introduces C++ operator::new integer overflow detection.

• Steve Christey publishes "Format String Vulnerabilities in Perl Programs". It covers the problems of format string bugs in the Perl interpreter and Perl programs, as well as a chronology of this type of attack. source

• Brett Moore publishes a technique for exploiting overflows in Freelist[0] on XP-SP2. It takes advantage of the fact that processes continue to run despite detected heap corruption. source

Conclusion

Memory errors have been present in software for over three decades now, leading to numerous security problems. Low-level languages such as C and C++, which are prone to this category of errors, are widely used. This means that many of today's systems are susceptible to attacks targeting memory corruption vulnerabilities. Consequently, program hardening and protection against this type of attack are of the utmost importance in building secure systems.

Bibliography

https://thinkst.com/resources/papers/BlackHat-USA-2010-Meer-History-of-Memory-Corruption-Attacks-wp.pdf
https://www.youtube.com/watch?v=oz7UWCbSMU0vz
https://www.isg.rhul.ac.uk/sullivan/pubs/tr/technicalreport-ir-cs-73.pdf