View source for Return-to-libc attack

{{Short description|Computer security attack}}
{{refimprove|date=April 2009}}
A '''"return-to-libc" attack''' is a [[computer security]] attack usually starting with a [[buffer overflow]] in which a subroutine [[return statement|return address]] on a [[call stack]] is replaced by an address of a subroutine that is already present in the [[Process (computing)|process]] executable memory, bypassing the [[NX bit|no-execute bit]] feature (if present) and ridding the attacker of the need to [[Code injection|inject]] their own code. The first example of this attack in the wild was contributed by [[Solar Designer|Alexander Peslyak]] on the [[Bugtraq]] mailing list in 1997.<ref>{{cite web
 | url = http://seclists.org/bugtraq/1997/Aug/63
 | title = Bugtraq: Getting around non-executable stack (and fix)
 | author = Solar Designer
 | date = 10 Aug 1997
}}</ref>

On [[POSIX]]-compliant [[operating system]]s the [[C standard library]] ("<code>libc</code>") is commonly used to provide a standard [[runtime environment]] for programs written in the [[C programming language]]. Although the attacker could make the code return anywhere, <code>libc</code> is the most likely target, as it is almost always linked to the program, and it provides useful calls for an attacker (such as the <code>[[C process control#system|system]]</code> function used to execute shell commands).

==Protection from return-to-libc attacks==
A [[NX bit|non-executable]] stack can prevent some buffer overflow exploitation, however it cannot prevent a return-to-libc attack because in the return-to-libc attack only existing executable code is used. On the other hand, these attacks can only call preexisting functions. [[Stack-smashing protection]] can prevent or obstruct exploitation as it may detect the corruption of the stack and possibly flush out the compromised segment.

{{anchor|ASCII armor}}"[[ASCII armoring]]" is a technique that can be used to obstruct this kind of attack. With ASCII armoring, all the system libraries (e.g., libc) addresses contain a [[Null byte|NULL byte]] (<code>0x00</code>). This is commonly done by placing them in the first <code>0x01010101</code> bytes of memory (a few pages more than 16&nbsp;MB, dubbed the "ASCII armor region"), as every address up to (but not including) this value contains at least one NULL byte. This makes it impossible to emplace code containing those addresses using string manipulation functions such as <code>strcpy()</code>. However, this technique does not work if the attacker has a way to overflow NULL bytes into the stack. If the program is too large to fit in the first 16&nbsp;[[megabyte|MB]], protection may be incomplete.<ref>{{cite web
 |author      = David A. Wheeler
 |title       = Secure programmer: Countering buffer overflows
 |publisher   = [[IBM]] DeveloperWorks
 |date        = 27 Jan 2004
 |url         = http://www.ibm.com/developerworks/library/l-sp4/index.html
 |url-status     = dead
 |archiveurl  = https://web.archive.org/web/20131018001904/http://www.ibm.com/developerworks/library/l-sp4/index.html
 |archivedate = 2013-10-18
}}</ref> This technique is similar to another attack known as '''return-to-plt''' where, instead of returning to libc, the attacker uses the Procedure Linkage Table (PLT) functions loaded in the [[position-independent code]] (e.g., <code>system@plt, execve@plt, sprintf@plt, strcpy@plt</code>).<ref>{{cite web
 | url = https://www.exploit-db.com/docs/english/17286-linux-exploit-development-part-4---ascii-armor-bypass-return-to-plt.pdf
 | title = Linux exploit development part 4 - ASCII armor bypass + return-to-plt
 | author = Sickness
 | date = 13 May 2011
}}</ref>

[[Address space layout randomization]] (ASLR) makes this type of attack extremely unlikely to succeed on [[64-bit computing|64-bit machines]] as the memory locations of functions are random. For [[32-bit computing|32-bit systems]], however, ASLR provides little benefit since there are only 16 bits available for randomization, and they can be defeated by [[Brute-force attack|brute force]] in a matter of minutes.<ref>{{Cite book | doi = 10.1145/1030083.1030124| chapter = On the Effectiveness of Address-space Randomization| title = Proceedings of the 11th ACM Conference on Computer and Communications Security | pages = 298–307| date=October 2004 | last1 = Shacham | first1 = H. | last2 = Page | first2 = M. | last3 = Pfaff | first3 = B. | last4 = Goh | first4 = E. J. | last5 = Modadugu | first5 = N. | last6 = Boneh | first6 = D. | isbn = 1-58113-961-6| s2cid = 5864467| url = http://www.stanford.edu/~blp/papers/asrandom.pdf}}</ref>

==See also==
* [[Buffer overflow]]
* [[Stack buffer overflow]]
* [[Stack-smashing protection]]
* [[NX bit|No eXecute (NX) bit]] 
* [[Address space layout randomization]]
* [[Return-oriented programming]]
* [[Gadget (machine instruction sequence)]]
* [[Unintended instructions]]

==References==
{{reflist}}

==External links==
* [https://css.csail.mit.edu/6.858/2010/readings/return-to-libc.pdf Bypassing non-executable-stack during exploitation using return-to-libc] by c0ntex at css.csail.mit.edu

[[Category:Computer security exploits]]
[[Category:C standard library]]