Breaking 64 bit aslr on Linux x86-64

In this article, I'll discuss about the application of the technique described by Samuel Groß in his Remote iPhone Exploitation Part 2: Bringing Light into the Darkness -- a Remote ASLR Bypass, to bypass ASLR on Linux x86_64.

To show this I'm gonna solve a pwnable challenge from Buckeye CTF, guess_god.

I'll try to keep the content as beginner friendly as possible, so feel free to skip any section if you feel confident enough and just want to see the exploit.

0. Introduction

I didn't play the CTF, but I got interested in the challenge about 2hrs before the ctf end thanks to Guray00, who was asking for help in fibonhack discord about some crypto shenanigans.

I couldn't help him, but I took a look at pwnable challenges, and figured it would be good to understand the P0 blogpost and hopefully get that bounty.

1. ASLR and how to bypass it

1.1 What is ASLR?

Address Space Layout Randomization (ASLR) is a computer security technique which involves randomly positioning the base address of an executable and the position of libraries, heap, and stack, in a process's address space.

1.2 ASLR on Linux

On linux, you can inspect the mappings of a process given its pid through procfs, by reading the file /proc/<pid>/maps.

If you are a process and you want to know your own memory mappings, you can read /proc/self/maps.

For example, you can try to read /proc/self/maps with cat:

root@088ec31b2ce9:/home/ctf/challenge# cat /proc/self/maps
55faeb01c000-55faeb01e000 r--p 00000000 fe:01 2497233                    /usr/bin/cat
55faeb01e000-55faeb023000 r-xp 00002000 fe:01 2497233                    /usr/bin/cat
55faeb023000-55faeb026000 r--p 00007000 fe:01 2497233                    /usr/bin/cat
55faeb026000-55faeb027000 r--p 00009000 fe:01 2497233                    /usr/bin/cat
55faeb027000-55faeb028000 rw-p 0000a000 fe:01 2497233                    /usr/bin/cat
55faeb115000-55faeb136000 rw-p 00000000 00:00 0                          [heap]
7fe15dfb1000-7fe15dfd5000 rw-p 00000000 00:00 0
7fe15dfd5000-7fe15dffb000 r--p 00000000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7fe15dffb000-7fe15e166000 r-xp 00026000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7fe15e166000-7fe15e1b2000 r--p 00191000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7fe15e1b2000-7fe15e1b5000 r--p 001dc000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7fe15e1b5000-7fe15e1b8000 rw-p 001df000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7fe15e1b8000-7fe15e1c3000 rw-p 00000000 00:00 0
7fe15e1c7000-7fe15e1c8000 r--p 00000000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7fe15e1c8000-7fe15e1ef000 r-xp 00001000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7fe15e1ef000-7fe15e1f9000 r--p 00028000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7fe15e1f9000-7fe15e1fb000 r--p 00031000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7fe15e1fb000-7fe15e1fd000 rw-p 00033000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7fff4388f000-7fff438b0000 rw-p 00000000 00:00 0                          [stack]
7fff43989000-7fff4398d000 r--p 00000000 00:00 0                          [vvar]
7fff4398d000-7fff4398f000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

root@088ec31b2ce9:/home/ctf/challenge# cat /proc/self/maps
55ffc0b1b000-55ffc0b1d000 r--p 00000000 fe:01 2497233                    /usr/bin/cat
55ffc0b1d000-55ffc0b22000 r-xp 00002000 fe:01 2497233                    /usr/bin/cat
55ffc0b22000-55ffc0b25000 r--p 00007000 fe:01 2497233                    /usr/bin/cat
55ffc0b25000-55ffc0b26000 r--p 00009000 fe:01 2497233                    /usr/bin/cat
55ffc0b26000-55ffc0b27000 rw-p 0000a000 fe:01 2497233                    /usr/bin/cat
55ffc2108000-55ffc2129000 rw-p 00000000 00:00 0                          [heap]
7f1ec6e0f000-7f1ec6e33000 rw-p 00000000 00:00 0
7f1ec6e33000-7f1ec6e59000 r--p 00000000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7f1ec6e59000-7f1ec6fc4000 r-xp 00026000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7f1ec6fc4000-7f1ec7010000 r--p 00191000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7f1ec7010000-7f1ec7013000 r--p 001dc000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7f1ec7013000-7f1ec7016000 rw-p 001df000 fe:01 2761561                    /usr/lib/x86_64-linux-gnu/libc-2.33.so
7f1ec7016000-7f1ec7021000 rw-p 00000000 00:00 0
7f1ec7025000-7f1ec7026000 r--p 00000000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7f1ec7026000-7f1ec704d000 r-xp 00001000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7f1ec704d000-7f1ec7057000 r--p 00028000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7f1ec7057000-7f1ec7059000 r--p 00031000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7f1ec7059000-7f1ec705b000 rw-p 00033000 fe:01 2761539                    /usr/lib/x86_64-linux-gnu/ld-2.33.so
7ffc72fa4000-7ffc72fc5000 rw-p 00000000 00:00 0                          [stack]
7ffc72fe7000-7ffc72feb000 r--p 00000000 00:00 0                          [vvar]
7ffc72feb000-7ffc72fed000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Memory mappings patterns

If you do this a couple of times, you could deduce that:

• The binary PIE base should be in the range 0x00005500_00000000-0x00005700_00000000, which means 2TB of possible addresses.
• The heap is near the binary.
• Libraries fall in the range 0x00007f00_00000000 - 0x00007fff_ffffffff, 1TB of possible addresses.
• Stack goes (most of the time) in the range 0x00007ffc_00000000 - 0x00007fff_ffffffff, 16gb of possible addresses.
• The range 0xffffffffff600000 - 0xffffffffff601000 is always mapped, you can read this article if you are curious about what it is.

1.3 How to bypass ASLR without an infoleak

Let's discuss what you can do to bypass ASLR when no information leak is possble.

This is my attempt to summarize what I got from reading Saelo's blogpost.

To bypass ASLR you need:

• A memory spraying technique, which lets you map contiguous memory of a given size, on a given range of addresses.

  As he says there are two ways of doing it:

  1. By abusing a memory leak (not an information leak!), a bug in which a chunk of memory is “forgotten” and never freed, and triggering it multiple times until the desired amount of memory has been leaked.
  2. By finding and abusing an “amplification gadget”: a piece of code that takes an existing chunk of data and copies it, potentially multiple times, thus allowing the attacker to spray a large amount of memory by only sending a relatively small number of bytes.

• An isAddressMapped oracle, which given an address tells you wheter or not that address is mapped.

PoC of ASLR bypass on Linux

Let's try to reproduce saelo's PoC to completely break aslr on Linux.