Sigreturn-oriented programming
Sigreturn-oriented programming (SROP) is a
Sigreturn-oriented programming can be considered a weird machine since it allows code execution outside the original specification of the program.[1]
Background
Sigreturn-oriented programming (SROP) is a technique similar to return-oriented programming (ROP), since it employs code reuse to execute code outside the scope of the original control flow. In this sense, the adversary needs to be able to carry out a
Stack hopping exploits
If mechanisms such as
Most programs do not contain functions that will allow the attacker to directly carry out the desired action (e.g., obtain access to a shell), but the necessary instructions are often scattered around memory.[6]
Return-oriented programming requires these sequences of instructions, called gadgets, to end with a RET
instruction. In this way, the attacker can write a sequence of addresses for these gadgets to the stack, and as soon as a RET
instruction in one gadget is executed, the control flow will proceed to the next gadget in the list.
Signal handler mechanism
This attack is made possible by how
sigreturn()
system call is called.
Calling the sigreturn syscall means being able to easily set the contents of registers using a single gadget that can be easily found on most systems.[1]
Differences from ROP
There are several factors that characterize an SROP exploit and distinguish it from a classical return-oriented programming exploit.[7]
First, ROP is dependent on available gadgets, which can be very different in distinct
Although
SROP exploits are usually portable across different binaries with minimal or no effort and allow easily setting the contents of the registers, which could be non-trivial or unfeasible for ROP exploits if the needed gadgets are not present.[6] Moreover, SROP requires a minimal number of gadgets and allows constructing effective shellcodes by chaining system calls. These gadgets are always present in memory, and in some cases are always at fixed locations:[7]
OS | ASLR | Gadget | Memory Map | Fixed Memory Location |
---|---|---|---|---|
Linux i386 | sigreturn | [vdso] | ||
Linux < 3.11 ARM | sigreturn | [vectors] | 0xffff0000 | |
Linux < 3.3 x86-64 | syscall&return | [vsyscall] | 0xffffffffff600000 | |
Linux ≥ 3.3 x86-64 | syscall&return | Libc | ||
Linux x86-64 | sigreturn | Libc | ||
FreeBSD 9.2 x86-64 | sigreturn | 0x7ffffffff000 | ||
Mac OSX x86-64 | sigreturn | Libc | ||
iOS ARM | sigreturn | Libsystem | ||
iOS ARM | syscall & return | Libsystem |
Attacks
Linux
An example of the kind of gadget needed for SROP exploits can always be found in the VDSO memory area on x86-Linux systems:
__kernel_sigreturn proc near:
pop eax
mov eax, 77h
int 80h ; LINUX - sys_sigreturn
nop
lea esi, [esi+0]
__kernel_sigreturn endp
On some Linux kernel versions, ASLR can be disabled by setting the limit for the stack size to unlimited,[9] effectively bypassing ASLR and allowing easy access to the gadget present in VDSO.
For Linux kernels prior to version 3.3, it is also possible to find a suitable gadget inside the vsyscall page, which is a mechanism to accelerate the access to certain system calls often used by legacy programs and resides always at a fixed location.
Turing-completeness
It is possible to use gadgets to write into the contents of the stack frames, thereby constructing a
PC
, a memory pointer P
, and a temporary register used for 8-bit addition A
. This means that also complex backdoors or obfuscated attacks can be devised.[1]
Defenses and mitigations
A number of techniques exists to mitigate SROP attacks, relying on
Address space layout randomization
Address space layout randomization makes it harder to use suitable gadgets by making their locations unpredictable.
Signal cookies
A mitigation for SROP called signal cookies has been proposed. It consists of a way of verifying that the sigcontext structure has not been tampered with by the means of a random cookie XORed with the address of the stack location where it is to be stored. In this way, the sigreturn syscall just needs to verify the cookie's existence at the expected location, effectively mitigating SROP with a minimal impact on performances.[1][10]
Vsyscall emulation
In Linux kernel versions greater than 3.3, the vsyscall interface is emulated, and any attempt to directly execute gadgets in the page will result in an exception.[11][12]
RAP
Grsecurity is a set of patches for the Linux kernel to harden and improve system security.[13] It includes the so-called Return-Address Protection (RAP) to help protect from code reuse attacks.[14]
CET
Starting in 2016,
See also
- Linux kernel interfaces
- Vulnerability (computing)
- Exploit (computer security)
- Buffer overflow
- Address space layout randomization
- Executable space protection
- NX bit
References
- ^ S2CID 6153855. Retrieved 2016-06-16.
- ^ "Award Papers of the 2014 IEEE Symposium on Security and Privacy". IEEE security. IEEE Computer Society's Technical Committee on Security and Privacy. Retrieved 2016-06-17.
- ^ "Linux Cross Reference - sigcontext.h".
- ^ "SIGRETURN(2) - Linux manual page".
- ^ a b "Playing with signals: An overview on Sigreturn Oriented Programming". Retrieved 2016-06-21.
- ^ a b c "Sigreturn-oriented programming and its mitigation". Retrieved 2016-06-20.
- ^ a b c Bosman, Erik; Bos, Herbert. "Framing Signals: a return to portable shellcode" (PDF).
- ^ "ROPC — Turing complete ROP compiler (part 1)".
- ^ "CVE-2016-3672 - Unlimiting the stack not longer disables ASLR". Retrieved 2016-06-20.
- ^ "Sigreturn-oriented programming and its mitigation". Retrieved 2016-06-20.
- ^ "On vsyscalls and the vDSO". Retrieved 2016-06-20.
- ^ "Hack.lu 2015 - Stackstuff 150: Why and how does vsyscall emulation work". Retrieved 2016-06-20.
- ^ "Linux Kernel Security (SELinux vs AppArmor vs Grsecurity)".
- ^ "RAP: RIP ROP" (PDF). Retrieved 2016-06-20.
- ^ "RIP ROP: Intel's cunning plot to kill stack-hopping exploits at CPU level". The Register. Retrieved 2016-06-20.
- ^ "Control-Flow-Enforcement technology preview" (PDF).