/ASLRay

Linux ELF x32 and x64 ASLR bypass exploit with stack-spraying

Primary LanguageShellMIT LicenseMIT

ASLRay

Linux ELF x32 and x64 ASLR bypass exploit with stack-spraying

Properties:

  • ASLR bypass
  • Cross-platform
  • Minimalistic
  • Simplicity
  • Unpatchable

Dependencies:

  • Linux 2.6.12+ - would work on any x86-64 Linux-based OS
    • BASH - the whole script

Limitations:

  • Stack needs to be executable (-z execstack)
  • Binary has to be exploited through arguments locally (not file, socket or input)
  • No support for other architectures and OSes (TODO)
  • Need to know the buffer limit/size

How it works

You might have heard of Heap Spraying attack? Well, Stack Spraying is similar, however, it was considered unpractical for most cases, especially ASLR on x86-64.

My work will prove the opposite.

For 32-bit, there are 2^32 (4 294 967 296) theoretical addresses, nevertheless, the kernel will allow to control about only half of bits (2^(32/2) = 65 536) for an execution in a virtualized memory, which means that if we control more that 50 000 characters in stack, we are almost sure to point to our shellcode, regardless the address, thanks to kernel redirection and retranslation. According to my tests, even 100 or 10 characters are enough.

This can be achieved using shell variables, which aren't really limited to a specific length, but practical limit is about one million, otherwise it will saturate the TTY.

So, in order to exploit successfully with any shellcode, we need to put a NOP sled following the shellcode into a shell variable and just exploit the binary with a random address. Note that NOP sled isn't necessary, this is just to universalise the exploit.

In 64-bit system the situation is different, but not so much as of my discovery.

Of course, you wouldn't have to cover all 2^64 possibilities, in fact, the kernel allows only 48 bits, plus a part of them are predictable and static, which left us with about 2^(4x8+5) (137 438 953 472) possibilities.

I have mentioned the shell variables size limit, but there is also a count limit, which appears to be about 10, thus allowing us to stock a 10 000 000 character shellcode, living us with just a tenth of thousand possibilities that can be tested rapidly and automatically. This time however, you will need to bruteforce and use NOP-sleds in order to make things quicker.

That said, ASLR on both 32 and 64-bits can be easily bypassed in few minutes and with few lines of shell...

HowTo

If you have exploited at least one buffer overflow in your life, you can skip, but just in case:

apt install gcc libc6-dev-i386 || kill -9 $$
chmod u+x ASLRay.sh
sudo gcc -z execstack test.c -o test
sudo gcc -m32 -z execstack test.c -o test32
sudo chmod +s test test32
source ASLRay.sh test32 1024
source ASLRay.sh test 1024
source ASLRay.sh test 1024 \x31\x80...your_shellcode_here

To prove that NOP-sled isn't necessary for Debian x32:

!!! WARNING !!! this will modify your /etc/passwd and change permissions of /etc/shadow, VM execution adviced

chmod u+x PoC.sh
source PoC.sh
grep ALI /etc/passwd

In case it still doesn't work, just add some NOPs (\x90) in the beginning.

Don't forget to check stack execution and ASLR both set:

scanelf -e test | grep RWX
or
readelf -l test | grep RWE
grep 2 /proc/sys/kernel/randomize_va_space

Thus you can just put your shellcode into a variable and give random addresses to registers for a shell with ASLR, I consider such kernel virtualization behaviour an unknown vulnerability, so the PoC is 0-day.

For Arch/Ubuntu you will also need to disable stack smashing protection, but 32-bit exploit isn't guaranteed to work (EIP \xff\xYY is redirected to \x08\x04 (not stack) and ESP is shifted to argv[1] (not argv[0])) and 64-bit will take much longer (execution delay, probably due to brk(NULL/0) syscall):

sudo gcc -z execstack -fno-stack-protector test.c -o test
sudo gcc -m32 -z execstack -fno-stack-protector test.c -o test32 

Notes

Always rely on multiple protections and not on a single one.

We need new system security mechanisms.

"From where we stand the rain seems random. If we could stand somewhere else, we would see the order in it. "

Tony Hillerman, Coyote Waits