• previous example was using stdcall convention • arguments pushed in reverse order on the stack • callee clean the stack at the end • spot it: ret imm16
Linux addressing is on 48 bits not 64 bits • Meaning maximum canonical address is 0x00007FFFFFFFFFFF • Meaning that you will not get `RIP=0x4141414141414141` but a CPU exception • Break on ret from vulnerable function and check pattern value pointed by RSP
protections disabled • less likely to happen nowadays on modern systems • maybe if you are lucky or exploiting an embedded system • Protections on multiple layers • compilation • os • Only targeting execution prevention in this workshop
execution of simple instructions already in the memory to execute code • simple instructions are called gadgets and are ended by RET • pop eax ; ret • mov [ebx], ecx ; ret
architecture (used by Intel processors) • a list of opcodes doesn’t have only one representation • possible to process them at various offsets • concept not applicable on RISC architectures (ARM, MIPS, …) • aligned on 2 bytes for Thumb mode and 4 bytes for standard
about stack based buffer overflow • as such your controlled data is in the stack • other types of exploits might not be as convenient • ex: heap overflow
be in the stack • need to change stack pointer register to point to user controlled data • beware: this zone might not be big enough for next calls to push • __kernel_vsyscall crashes usually
the vulnerable function • use si (step into) to go through every instruction • use context to see stack and registers • run vulnerable program through strace to get error messages rop | practice
that’s already present • Now what about the data ? • open(“./super_special_flag”) • address space might not contain super_special_flag rop | bringing data in
7) • on tp_rop • store hack.lu in .data • using only gadgets and not ret2libc technic • https://github.com/0xmilkmix/training/tree/master/hacklu rop | practice
pop a shell • Maybe you just want to call unlock_door on connected lock • Read content of a file • Bypass seccomp restrictions preventing exec* • Or simply stay out of the radars during an attack/defence CTF
arguments afterwards since they are passed in registers • Same apply on 64 bit as ABI uses registers to pass parameters also for functions calls • rdi, rsi, rdx, r10, r9, r8 rop | syscalls and 64 bit
to detect rop chains • high ratio of ret instructions per instructions blocks • shadow stack that validate that ret is returning to instruction following the right call instruction
stack degrade performance by at least 30% • as such most implementations are coarse grained • leaving holes that can be exploited • fine grained implementations in some academic r&d projects
libc base address to common base • brute-force the remaining 16 bit • only effective on 32 bit systems or if rebasing is built-into the binary • 64 bit Linux has 28 bit of entropy aslr | brute force
? • generate pattern that appears only once in the library • not present in other ones obviously • need a second vulnerability in the code • memory disclosure aslr | disclosure
of the corresponding function • filed by the loader when executing the binary • unless lazy binding is used, in this case only once function already called aslr | non-pie
or has been leaked • read at selected offset to retrieve current address of a function • open the libc binary and retrieve offset from this function • also extract offsets from the desired functions aslr | calculate