Return-to-libc attack
Return-to-libc is a type of computer security attack that happens when a program’s memory is corrupted and the return address on the call stack is redirected to a function that already exists in the program’s libraries. Instead of injecting new code, the attacker makes the program reuse existing code to perform actions they want.
The first known example of this attack appeared in 1997, described by Alexander Peslyak on Bugtraq.
Why target libc? On POSIX systems, programs usually link with libc, which provides many common functions. Because libc is almost always loaded with the program, an attacker can often call functions there (such as those that can run shell commands) to take control of the process.
Non-executable stacks (NX) were designed to stop code injection, but they do not stop return-to-libc attacks, since no new code is being injected. These attacks rely on existing, executable code instead.
Defenses include stack-protection mechanisms that detect or prevent memory corruption, and more general security practices. Some ideas to obstruct these attacks—like ASCII armoring, which hides library addresses by presenting them in a way that makes certain strings fail to copy properly—have been proposed, but they are not reliably effective in all cases.
There’s also a related approach called return-to-plt, where the attacker uses the program’s own PLT (Procedure Linkage Table) entries rather than libc directly.
To make such attacks harder, many systems use ASLR (address space layout randomization). On 64-bit systems, ASLR makes it very unlikely for an attacker to guess where functions live. On 32-bit systems, the smaller amount of randomization can still be brute-forced more easily, so ASLR is less protective there.
In short, return-to-libc exploits abuse existing library code to hijack a program’s behavior, and defenses rely on memory protections, careful coding, and address randomization to reduce risk.
This page was last edited on 3 February 2026, at 10:32 (CET).