Ret2lib
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The essence of Ret2Libc is to redirect the execution flow of a vulnerable program to a function within a shared library (e.g., system, execve, strcpy) instead of executing attacker-supplied shellcode on the stack. The attacker crafts a payload that modifies the return address on the stack to point to the desired library function, while also arranging for any necessary arguments to be correctly set up according to the calling convention.
Get the address of the function to call (e.g. system) and the command to call (e.g. /bin/sh)
Generate a ROP chain to pass the first argument pointing to the command string and the execution flow to the function
Supposing that the libc used is the one from current machine you can find where it'll be loaded in memory with:
If you want to check if the ASLR is changing the address of libc you can do:
Knowing the libc used it's also possible to find the offset to the system function with:
Knowing the libc used it's also possible to find the offset to the string /bin/sh function with:
Knowing the libc used, It's also possible to use Peda or GEF to get address of system function, of exit function and of the string /bin/sh :
If the process is creating children every time you talk with it (network server) try to read that file (probably you will need to be root).
Here you can find exactly where is the libc loaded inside the process and where is going to be loaded for every children of the process.
In this case it is loaded in 0xb75dc000 (This will be the base address of libc)
It might be possible that you don't know the libc the binary is loading (because it might be located in a server where you don't have any access). In that case you could abuse the vulnerability to leak some addresses and find which libc library is being used:
And you can find a pwntools template for this in:
Check the page https://libc.blukat.me/ and use a couple of addresses of functions inside the libc to find out the version used.
These brute-forcing attacks are only useful for 32bit systems.
If the exploit is local, you can try to brute-force the base address of libc (useful for 32bit systems):
If attacking a remote server, you could try to burte-force the address of the libc function usleep, passing as argument 10 (for example). If at some point the server takes 10s extra to respond, you found the address of this function.
Execute a shell just jumping to one specific address in libc:
In this example ASLR brute-force is integrated in the code and the vulnerable binary is loated in a remote server:
Check the example from:
In the case of ARM64, the ret instruction jumps to whereber the x30 registry is pointing and not where the stack registry is pointing. So it's a bit more complicated.
Also in ARM64 an instruction does what the instruction does (it's not possible to jump in the middle of instructions and transform them in new ones).
Check the example from:
This allows to leak information from the process by calling printf/puts with some specific data placed as an argument. For example putting the address of puts in the GOT into an execution of puts will leak the address of puts in memory.
This basically means abusing a Ret2lib to transform it into a printf format strings vulnerability by using the ret2lib to call printf with the values to exploit it (sounds useless but possible):
https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html
Ret2lib, given a leak to the address of a function in libc, using one gadget
https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html
64 bit, ASLR enabled but no PIE, the first step is to fill an overflow until the byte 0x00 of the canary to then call puts and leak it. With the canary a ROP gadget is created to call puts to leak the address of puts from the GOT and the a ROP gadget to call system('/bin/sh')
https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html
64 bits, ASLR enabled, no canary, stack overflow in main from a child function. ROP gadget to call puts to leak the address of puts from the GOT and then call an one gadget.
https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html
64 bits, no pie, no canary, no relro, nx. Uses write function to leak the address of write (libc) and calls one gadget.
https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html
Uses a format string to leak the canary from the stack and a buffer overflow to calle into system (it's in the GOT) with the address of /bin/sh.
https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html
32 bit, no relro, no canary, nx, pie. Abuse a bad indexing to leak addresses of libc and heap from the stack. Abuse the buffer overflow o do a ret2lib calling system('/bin/sh') (the heap address is needed to bypass a check).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
