ELF Format Analysis and Exploitation Techniques

22/10/2016
The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog
Posted on October 20, 2011 by FlUxIuS
New systems make attackers life hard and common exploitation techniques get harder to reproduce. The purpose of this article is to be
very general on mitigation techniques and to cover attacks on x32 as a reference to x64 architectures to stick with the new constraints of
today.
Here, you will find the first step which is an ELF format file analysis. After that we will speak about the protections and ways to bypass
them. To finish, we will introduce the x86_64 that makes things more difficult for nowadays exploitations.
Pre-requisites:
Basics in Linux, asm x86,

a good understanding of buffer overflows, format string exploitations, heap overflows,
0x00900dc0ff33,
Ubuntu 11.04 on x86_64.
a default song: Zeads dead Paradise Circus (Massive attack Remix)
Here is the contents:
The ELF format

A standard
Where is it used?
ELF Layout
Dissecting the ELF
The magic field
Reversing ELFs header
Sections
Relocations
Program Headers
http://fluxius.handgrep.se/2011/10/20/the-art-of-elf-analysises-and-exploitations/#comment-18585
1/21
22/10/2016
Exploitations
Old is always better (for attackers)
Nonexecutable stack
Address Space Layout Randomization
Brute-force
Return-to-registers
Stack Canary
RELRO
The x86_64 fact and current systems hardening
References & Acknowledgements
The ELF format

A standard
Replacing the COFF and a.out formats that Linux previously used, ELF (Executable and Linking Format) increased flexibility. Indeed,
when shared libraries are difficult to create and dynamically loading a shared library is cumbersome with a.out format, the ELF format
has come with these two benefits[1]:
It is much simpler to make shared libraries,

It make dynamic loading and has comes with other suggestions for dynamic loading have included super-fast
MUDs (Multi-User Domains also known as Multi-User Dungeon), where extra code could be compiled and
linked into the running executable without having to stop and restart the program.
This format has been selected by the Tool Interface Standards committee (TIS) as a standard for portable object files for a variety of
(Unix-Like) operating systems.
Where is it used?
Actually ELFs cover object files (.o), shared libraries (.so) and is also used for loadable kernel modules. As follows in listing 1, you can see
also which systems[4] have adopted the ELF format:
ELF Layout
An ELF as at least two headers: the ELF header (Elf32_Ehdr/Elf64_Ehdr struct) and the program header (Elf32_Phdr/struct Elf64_Phdr
struct)[5]. But there is also a header which is called the section header (Elf32_Shdr/struct Elf64_Shdr struct) and which describes section
like: .text, .data, .bss and so on (we will describe them later).
2/21
22/10/2016
As you can see in figure 1, there is two views. Indeed, the linking view is partitioned by sections and is used when program or library is
linked. The sections contain some object files informations like: datas, instructions, relocation informations, symbols, debugging
informations, and so on.
From the other part, the execution view, which is partitioned by segments, is used during a program execution. The program header as
shown in the left, contains informations for the kernel on how to start the program, will walk through segments and load them into
memory (mmap).
Dissecting the ELF

The magic field
In Linux forensic, it is common to use the file command to the type of a particular file, as follows:
fluxiux@nyannyan:~$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
Now lets focus on the ELF string. As you had probably noticed using hexdump on any ELF file (like /bin/ls for example), the file starts
with 0x7f then there are three next bytes for the encoded string ELF:
fluxiux@nyannyan:~$ hd -n 16 /bin/ls
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
The first 16 bytes represent the elf magic field, which is a way to identify an ELF file. But if bytes 1, 2 and 3 represent the encoded string
ELF, what represent bytes 4, 5, 6, 7, 8, 9?
Just have a look at elf.h source code:
3/21
22/10/2016
#define EI_CLASS
/* File class byte index */
#define ELFCLASSNONE 0
/* Invalid class */
#define ELFCLASS32
/* 32-bit objects */
#define ELFCLASS64
/* 64-bit objects */
#define ELFCLASSNUM
#define EI_DATA
/* Data encoding byte index */
#define ELFDATANONE
#define ELFDATA2LSB
0
1
#define ELFDATA2MSB
/* Invalid data encoding */

/* 2's complement, little endian */
/* 2's complement, big endian */
We can affirmatively say, that our file is an ELF of class 64, encoded in little endian with a UNIX System V ABI standard and has 0 padding
bytes. By the way, if you did not expected yet, we have compared to the structure we have observed here the e_ident of Elf64_Ehdr
structure.
Reversing ELFs header

To begin the complete dissection, lets just start making a simple binary file as follows:
#include <stdio.h>
main()
{
printf("huhu la charrue");
}
And produce an ELF before linking it:
gcc toto.c -c
We will use now one of the most used tool as objdump to analysis ELF files which is readelf from binutils to display every fields. That will
simplify our analysis but if you are interested for dissecting ELF files yourself, you can look for libelf and we will also talk about some
interesting libraries in Python to do it much more quickly.
Now, we observe the ELF header:
fluxiux@nyannyan:~$ readelf -h toto

ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class:
ELF64
Data:
2's complement, little endian
Version:
OS/ABI:
ABI Version:
Type:
Machine:
1 (current)
UNIX - System V
0
REL (Relocatable file)
Advanced Micro Devices X86-64
The result seems to be very implicit, but now just lets try to identify these field using our lovely hexdump tool (in warrior forensic style!
or not):
4/21
22/10/2016
fluxiux@nyannyan:~$ hd -n 64 toto
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 01 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 |..>.............|
00000020 00 00 00 00 00 00 00 00 38 01 00 00 00 00 00 00 |........8.......|
00000030 00 00 00 00 40 00 00 00 00 00 40 00 0d 00 0a 00 |....@.....@.....|
00000040
We already know the first line, but what can say about the three others? As you can see, in the second line, the first two bytes represent
the e_type. Indeed, if you look at elf.h file, you could observe that 01 00 in little-Indian, means: Relocatable file.
Now look at the two next bytes. We have 3e 00 that is equivalent to 62 in decimal (3*16 + c = 62), which defines the AMD x86-64
architecture:
#define EM_X86_64
62
/* AMD x86-64 architecture */
After we have the e_version field with 01 00 as a value for Current version:
/* Legal values for e_version (version). */

#define EV_NONE
#define EV_CURRENT
#define EV_NUM
/* Invalid ELF version */

1
/* Current version */
Bytes 24 to 26 indicate the entry point address (which is 0x0 while it is not linked) . And we finish with two more most important think that
we will talk about in this article :
Program Headers with 6 headers, starting at byte 64 (byte 32 and 33 in hexdump),

section headers with 29 headers, starting at byte (byte 40 43 in hexdump).
For the rest, we will use readelf and I will let you finish the header part by yourself.
Sections
Lets just see toto.o sections with the following command:
fluxiux@nyanyan:~$ readelf -S toto.o

There are 13 section headers, starting at offset 0x138:
Section Headers:
[Nr] Name
Size
[ 0]
Type
Address
Offset
EntSize
Flags Link Info Align
NULL
0000000000000000 00000000
0000000000000000 0000000000000000
[ 1] .text
PROGBITS
0000000000000000 00000040
0000000000000018 0000000000000000 AX
As you can see, there is a lot of sections which are part of the ELF64_Shdr:
5/21
22/10/2016
Code sections (.text),

data section (.data, .bss, .rodata),
the .comment which is used to store extra informations,
relocation tables (.rela.*),
symbol tables (.symtab),
section String Tables (.shstrtab) which stores the name of each section,
string tables (.strtab).
The address column normally shows where sections should be loaded into virtual memory, but this was not filled in for each section. The
reason is that we did not linked it yet, so we will do that:
fluxiux@nyannyan:~$ gcc toto.o -o toto

fluxiux@nyannyan:~$ readelf -S toto
There are 30 section headers, starting at offset 0x1178:
Section Headers:
[Nr] Name
Size
[ 0]
Type
Address
Offset
EntSize
Flags Link Info Align
NULL
0000000000000000 00000000
0000000000000000 0000000000000000
[ 1] .interp
PROGBITS
0000000000400238 00000238
000000000000001c 0000000000000000 A
Wow! Some new sections appeared:
.interp which holds pathname of the program interpreter,

code sections (.plt, .init, .fini),
table of imported/exported symbols (.dynsym),
dynamic names table (.dynstr),
dynamic hash table (.hash),
new relocation tables (.rela.*),
constructor and Destructor tables (.ctors, .dtors),
section reserved for dynamic binaries (.got, .dynamic, .plt).
After the address column, you have the offset within the file of the section, then you have the size in byte of each section, the section
header size in byte, the required alignment, the Flags (Read, Write, Execute), and so on.
In this article, we will discover some important sections to target for any attack.
Relocations
The relocation is made to modify the memory image of mapped segments to make them executable. As you saw before, there are some
.rela.* sections which are used to show where to patch the memory and how. Lets look the different relocations using our favorite tool
readelf:
fluxiux@nyannyan:~$ readelf -r toto
6/21
22/10/2016
Relocation section '.rela.dyn' at offset 0x380 contains 1 entries:

Offset
Info
Type
Sym. Value Sym. Name + Addend
000000600fe0 000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0

Relocation section '.rela.plt' at offset 0x398 contains 2 entries:
Offset
Info
Type
Sym. Value Sym. Name + Addend
000000601000 000100000007 R_X86_64_JUMP_SLO 0000000000000000 printf + 0

000000601008 000300000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main + 0
For example, it means for printf we need to patch the offset 0x000000600fe0 from the beginning of the .plt section.
For more informations, you have also a description of relocation types in elf.h:
/* x86-64 relocation types, taken from asm-x86_64/elf.h */

#define R_X86_64_NONE
/* No reloc */
[...]
#define R_X86_64_GLOB_DAT
/* Create GOT entry */
/* Create PLT entry */
#define R_X86_64_JUMP_SLOT
[...]
Program Headers
The section header table is not loaded into memory, because the kernel nor the dynamic loader will be able to use that table. To load a file
into memory, program headers are used to provide informatios that are required:
fluxiux@nyanyan:~$ readelf -W -l toto

Elf file type is EXEC (Executable file)
Entry point 0x400410
There are 9 program headers, starting at offset 64
Program Headers:
Type
PHDR
INTERP
Offset VirtAddr
PhysAddr
FileSiz MemSiz Flg Align
0x000040 0x0000000000400040 0x0000000000400040 0x0001f8 0x0001f8 R E 0x8

0x000238 0x0000000000400238 0x0000000000400238 0x00001c 0x00001c R 0x1
As you can see, each program header corresponds to one segment where you can find sections into it. But how does it work?
In the beginning, when the kernel sees the INTERP segment, it loads first the LOAD segments to the specified virtual addresses, then load
segments from program interpreter (/lib64/ld-linux-x86-64.so.2) and jumps to interpreters entry point. After that, the loader gets the
control and loads libraries specified in LD_PRELOAD and also DYNAMIC segments of the executable that are needed:
fluxiux@nyannyan:~$ readelf -d toto

Dynamic section at offset 0xe50 contains 20 entries:
7/21
22/10/2016
Tag
Type
Name/Value
0x0000000000000001 (NEEDED)
Shared library: [libc.so.6]
After relocations, the loader invokes all libraries INIT function and then jumps to executables entry point.
In static, there is less thinks to say because the kernel only loads LOAD segments to the virtual addresses and then jumps to the entry
points (easy eh?).
For some more details (I think), you can see an old but very good article published in Linux Journal #13 about ELF dissection by Eric
Youngdale[6].
Exploitation
Old is always better (for attackers)
Once upon a the time, you where at home and waiting for the rain to stop. As always you googled for some interesting informations (of
course!) and you found a kind of bible: Smashing the stack for fun and Profit[7].
Identifying the stack address, putting your shellcode at the beginning, adding some padding and rewriting the EIP, you could see that we
can execute anything we want while exploiting a stack overflow. But times have changed, and youre now confronted to canaris, ASLR
(Address Space Layout Randomization), no executable stack, RELRO (read-only relocations), PIE support, binary-to-text encoding, and so
on.
Nonexecutable stack
To make the stack nonexecutable, we use the bit NX (No eXecute for AMD) or bit XD (eXecute Disable for Intel). In figure 2, you could see
that it matches with the most significant bit of a 64-bit Page Table Entry:
Figure 2 64-bit Page Table Entry

(Source : A hardware-enforced BOF protection )
So trying to exploit a stack based overflow, you should be surprised by the fact your shellcode doesnt produce what you expected, and
thats the power of the bit NX (NX = 0 Execute, NX = 1 No eXecute).
Using readlef -l you can see if the stack is executable or not :
GNU_STACK
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW
8
8/21
22/10/2016
As you can see, the only flags we got is the Read and Write ones. You can disable the eXecute flag using execstack -s [binaryfile] and
see the difference (RWE).
To bypass it, we can use a method called Return-into-libc. Endeed, we know that any program that includes libc will have access to its
shared functions (such as printf, exit, and so on), and we can execute system(/bin/sh) to get a shell.
First, we fill the vulnerable buffer with some junk data up to EIP (AAAAAAAAAHH! is great). After that, we have to find system()
function, but if we want to exit the program properly, the exit() will be also needed (using gdb):
(gdb) r main
Starting program: /home/fluxius/toto main
huhu la charrue
Program exited with code 017.
(gdb) p system
$1 = {<text variable, no debug info>} 0x7ffff6b8a134 <system>
(gdb) p exit
$2 = {<text variable, no debug info>} 0x7ffff6b81890 <exit>
Then, we overwrite the return address with system() functions address and follow it with the exit() functions address. To finish, we put
the address of /bin/sh (that you can retrieve from a memcmp() or an environment variable).
Inject = [junk][system()][exit()][/bin/sh]
Note: NX bit is only available in Physical Address Extension (PAE), but can be emulated by PaX or ExecShield.
Moreover, we will see after on x86_64 platforms that return-into-libc doesnt work because of the ABI specifications[8], and thats
probably a problem youve already encountered.
Address Space Layout Randomization

To avoid attackers to execute a dangerous shellcode, people has created a concept named ASLR (Address Space Layout Randomization).
Indeed, it is a technique to arrange the position of the stack, heap, text, vdso, shared libraries and the base address of the executable
(when builded with Position-independent executable support). So if you try to execute any shellcode at a saved position, youll observe a
little fail, because the shellcode isnt executed (or you are very lucky) and you get the classic error for segmentation faults as we did not
ended properly.
When performing a stack overflow for example, you could disable ASLR changing the current level to 0:
# echo 0 > /proc/sys/kernel/randomize_va_space

Or there is another trick (proposed by perror), that does not require root privileges, using setarch to change reported architecture in a
new program environnement and setting personality flags:
$ setarch `uname -m` -R /bin/bash

But its not quite fun, is it? So, attackers have found some ways to bypass this kind of technique. Indeed, in older kernels, they saw the
ESP points to the stack, and of course, the buffer is on the stack too. A technique using linux-gates instructions, that were static before
9/21
22/10/2016
the kernel 2.6.18, was used to retrieve the address of any interesting pattern \xff\xe4 (jump esp on x86) in memory. Other techniques
to bypass ASLR exist like Brute-force.
Brute-force
Thinking about exec() family functions, we can use execl to replace the current process image with a new process image. Lets make a
simple code to observe the randomization:
main()
{
char buffer[100];
printf("Buffer address: %p\n", &buffer);
}
If ASLR is enabled, you should see something like this:
fluxiux@handgrep:~/aslr$ ./buffer_addr
Buffer address: 0x7fff5e149710
Buffer address: 0x7fff71f6f0b0
Buffer address: 0x7fff763299c0
We see that 4 bytes change for each execution, and we have to be very lucky to point in our shellcode, if we try the brute-force way. So
we will use execl now to see any weakness when the memory layout is randomized for the process:
main()
{
int stack;
printf("Stack address: %p\n", &stack);
execl("./buffer_addr", "buffer_addr", NULL);
}
Compare the memory layouts with different runs of buffer_addr:
Buffer address: 0x7fffc5cfa180
Buffer address: 0x7fff1964d1f0
Buffer address: 0x7fffba20bd30
Buffer address: 0x7fffc8505ed0
Buffer address: 0x7ffff39cbc10
Buffer address: 0x7fff6eb3aa90
fluxiux@handgrep:~$ gdb -q --batch -ex "p 0x7fffc5cfa180 - 0x7fff1964d1f0"
10/21
22/10/2016
$1 = 2892681104
fluxiux@handgrep:~$ gdb -q --batch -ex "p 0x7fffc8505ed0 - 0x7fffba20bd30"
$1 = 238002592
fluxiux@handgrep:~$ gdb -q --batch -ex "p 0x7ffff39cbc10 - 0x7fff6eb3aa90"
$1 = 2229866880
And now with execl function:
fluxiux@handgrep:~/aslr$ ./weakaslr
Stack address: 0x7fff526d959c
Buffer address: 0x7fff2e95efd0
fluxiux@handgrep:~/aslr$ gdb -q --batch -ex "p 0x7fffaffcde50 - 0x7fff54800abc"
$1 = 1534907284
Stack address: 0x7fffed12acfc
Buffer address: 0x7fffa3a4f8f0
fluxiux@handgrep:~$ gdb -q --batch -ex "p 0x7fffdaf7d5fc - 0x7fff08361da0"
$1 = 3535911004 If we dig a little bit more, we can reduce the domain of probabilistic addresses using /proc/self/maps fil
Stack address: 0x7ffffbe8326c
Buffer address: 0x7fff792120c0
fluxiux@handgrep:~$ gdb -q --batch -ex "p 0x7ffffbe8326c - 0x7fff792120c0"
$1 = 2194084268
Stack address: 0x7fffed12acfc
Buffer address: 0x7fffa3a4f8f0
fluxiux@handgrep:~$ gdb -q --batch -ex "p 0x7fffed12acfc - 0x7fffa3a4f8f0"
$1 = 1231926284
Using this method, we could fill the buffer with return address, add a large NOP sled after the return address + the shellcode and guess
any correct offset, to point to it. As you can see, the degree of randomization is not the same, but you can play with that. Of course, this
attack is more effective on 32-bits and on older kernel versions[9].
If we dig a little bit more, we can reduce the domain of probabilistic addresses using /proc/self/maps files (local bypass), as shown
below:
...
00fa8000-00fc9000 rw-p 00000000 00:00 0
[heap]
7ffd77890000-7ffd77a1a000 r-xp 00000000 08:05 396967
/lib/x86_64-linux-gnu/libc-2.13.so
7ffd77a1a000-7ffd77c19000 ---p 0018a000 08:05 396967
7ffd77c19000-7ffd77c1d000 r--p 00189000 08:05 396967
7ffd77c1d000-7ffd77c1e000 rw-p 0018d000 08:05 396967
7ffd77c1e000-7ffd77c24000 rw-p 00000000 00:00 0

7ffd77c24000-7ffd77c26000 r-xp 00000000 08:05 397045
/lib/x86_64-linux-gnu/libutil-2.13.so
7ffd77c26000-7ffd77e25000 ---p 00002000 08:05 397045
7ffd77e25000-7ffd77e26000 r--p 00001000 08:05 397045
11/21
22/10/2016
7ffd77e26000-7ffd77e27000 rw-p 00002000 08:05 397045
7ffd77e27000-7ffd77e48000 r-xp 00000000 08:05 396954
/lib/x86_64-linux-gnu/ld-2.13.so
7ffd7801d000-7ffd78020000 rw-p 00000000 00:00 0

7ffd78043000-7ffd78044000 rw-p 00000000 00:00 0
7ffd78045000-7ffd78047000 rw-p 00000000 00:00 0
7ffd78047000-7ffd78048000 r--p 00020000 08:05 396954
7ffd78048000-7ffd7804a000 rw-p 00021000 08:05 396954
7fff7d479000-7fff7d49a000 rw-p 00000000 00:00 0
[stack]
7fff7d589000-7fff7d58a000 r-xp 00000000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
Unfortunately, this leak is partially patched since 2.6.27 according to Julien Tinnes and Tavis Ormandy[10], and these files seem to be
protected if you cannot ptrace a pid. Anyway, there was any other way using /proc/self/stat and /proc/self/wchan that leak
informations such as stack pointer and instruction pointer (=>ps -eo pid,eip,esp,wchan), and by sampling kstkeip, we could reconstruct
the maps (see fuzzyaslr by Tavis Ormandy[11]).
Brute-forcing is always a very offensive way to get what you want, it takes time, and you should know that every tries recorded in logs.
The solution is maybe in registers.
Return-to-registers
Using a debugger like GDB, can help you to find other ways to bypass some protections like DEP as shown previously and ASLR of course.
To study this case, we will work with a better example:
#include <stdio.h>
#include <string.h>
vuln(char* string)
{
char buffer[50];
strcpy(buffer, string); // Guys! It's vulnerable!
}
main(int argc, char** argv)
{
if (argc > 1)
vuln(argv[1]);
}
By the way, dont forget to disable the stack protector (compile as follows: gcc -fno-stack-protector -z execstack -mpreferred-stackboundary=4 vuln2.c -o vuln2). Will see after what a canary is, but now, just lets focus on ASLR for the moment.
With few tries, we see that we can rewrite the instruction pointer:
(gdb) run `python -c 'print "A"*78'`

The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fluxiux/aslr/vuln2 `python -c 'print "A"*78'`
12/21
22/10/2016
Program received signal SIGSEGV, Segmentation fault.

0x0000414141414141 in ?? ()
Put now a break to the vuln() functions call and the return address:
(gdb) disas main

Dump of assembler code for function main:
0x0000000000400515 <+0>: push %rbp
0x0000000000400516 <+1>: mov %rsp,%rbp
0x0000000000400519 <+4>: sub $0x10,%rsp
0x000000000040051d <+8>: mov %edi,-0x4(%rbp)
0x0000000000400520 <+11>: mov %rsi,-0x10(%rbp)
0x0000000000400524 <+15>: cmpl $0x1,-0x4(%rbp)
0x0000000000400528 <+19>: jle 0x40053d <main+40>
0x000000000040052a <+21>: mov -0x10(%rbp),%rax
After that, put a break on the return address of the vuln() function:
(gdb) disas vuln

Dump of assembler code for function vuln:
0x00000000004004f4 <+0>: push %rbp
0x00000000004004f5 <+1>: mov %rsp,%rbp
0x00000000004004f8 <+4>: sub $0x50,%rsp
0x00000000004004fc <+8>: mov %rdi,-0x48(%rbp)
0x0000000000400500 <+12>: mov -0x48(%rbp),%rdx
0x0000000000400504 <+16>: lea -0x40(%rbp),%rax
0x0000000000400508 <+20>: mov %rdx,%rsi
0x000000000040050b <+23>: mov %rax,%rdi
0x000000000040050e <+26>: callq 0x400400 <strcpy@plt>
0x0000000000400513 <+31>: leaveq
0x0000000000400514 <+32>: retq
End of assembler dump.
(gdb) break *0x0000000000400514
Breakpoint 3 at 0x400514
As we can see, the RSP contains the return address:
(gdb) info reg rsp

rsp
0x7fffffffe148 0x7fffffffe148
(gdb) x/20x $rsp - 40

[...]
0x7fffffffe140: 0x00000000 0x00000000 0x0040053d 0x00000000
[]
The return address as been overwritten (we also noticed that previously):
13/21
22/10/2016
(gdb) info reg rsp

rsp
0x7fffffffe148 0x7fffffffe148
(gdb) x/20x $rsp - 40

0x7fffffffe120: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe130: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe140: 0x41414141 0x41414141 0x41414141 0x00004141
0x7fffffffe150: 0xffffe248 0x00007fff 0x00000000 0x00000002
0x7fffffffe160: 0x00000000 0x00000000 0xf7a66eff 0x00007fff
And running at the last breakpoint, we can observe that register RAX points to the beginning of our buffer:
(gdb) stepi
0x00000000004004f8 in vuln ()
(gdb) info reg rax
rax
0x7fffffffe520 140737488348448
(gdb) x/20x $rax - 40

0x7fffffffe4f8: 0x36387816 0x0034365f 0x00000000 0x2f000000
0x7fffffffe508: 0x656d6f68 0x756c662f 0x78756978 0x6c73612f
0x7fffffffe518: 0x75762f72 0x00326e6c 0x41414141 0x41414141
0x7fffffffe528: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe538: 0x41414141 0x41414141 0x41414141 0x41414141
(Note that if youre not sure, try with this payload: `python -c print A*70+B*8`).
After that, we look for a valid jmp/callq rax:
fluxiux@handgrep:~/aslr$ objdump -d ./vuln2 | grep "callq"

4003cc: e8 6b 00 00 00
callq 40043c <call_gmon_start>
[...]
400604: ff d0
callq *%rax
..
At 0x400604 could be great, we just have to replace the junk data (A) by NOP sled and a precious shellcode that fits on the buffer and
we replace the instruction pointer by the address 0x400604. On 32-bits, Sickness has written a good article about that if you are
interested[12].
But as you know, by default on Linux (especially the user friendly one: Ubuntu), programs are compiled with the bit NX support, so be
lucky to use this technique on nowadays systems. Indeed, we use also an option to disable the stack protector, but what is it exactly?
Stack Canary
Named for their analogy to a canary in a coal mine, stack canary are used to protect against stack overflow attacks. Compiling with the
stack protector option (which is used by default), each dangerous function is changed in his prologue and epilogue.
If we compile the previous code letting stack protector to be used, we get something like that:
14/21
22/10/2016
fluxiux@handgrep:~/ssp$ gcc -z execstack -mpreferred-stack-boundary=4 vuln2.c -o vuln3

fluxiux@handgrep:~/spp$ ./vuln3
fluxiux@handgrep:~/spp$ ./vuln3 `python -c 'print "A"*76'`
*** stack smashing detected ***: ./vuln3 terminated
Disassembling the vuln() function, we can see in the epilogue that a comparison is done:
(gdb) disas vuln

Dump of assembler code for function vuln:
[...]
0x000000000040058d <+41>: callq 0x400470 <strcpy@plt>
0x0000000000400592 <+46>: mov -0x8(%rbp),%rdx
0x0000000000400596 <+50>: xor %fs:0x28,%rdx
0x000000000040059f <+59>: je
0x4005a6 <vuln+66>
0x00000000004005a1 <+61>: callq 0x400460 <__stack_chk_fail@plt>

0x00000000004005a6 <+66>: leaveq
[...]
If the value in fs:0x28 is the same as in %rdx, the vuln() function will end properly. In other case, the function __stack_chk_fail()
will be called and an error message shows up (*** stack smashing detected ***: ./vuln3 terminated ).
Putting a break on __stack_chk_fail() function, we can observe the values on $RSP:
(gdb) run `python -c 'print "A"*57'`

Starting program: /home/fluxiux/aslr/vuln3 `python -c 'print "A"*57'`
Breakpoint 1, 0x00000000004005cb in main ()
(gdb) c
Continuing.
Breakpoint 2, 0x00000000004005a1 in vuln ()
(gdb) x/30x $rsp
0x7fffffffe100: 0x00000000 0x00000000 0xffffe535 0x00007fff
0x7fffffffe110: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe120: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe130: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe140: 0x41414141 0x41414141 0xbf630041 0xe3b6079a
0x7fffffffe150: 0xffffe170 0x00007fff 0x004005d0 0x00000000
0x7fffffffe160: 0xffffe258 0x00007fff 0x00000000 0x00000002
0x7fffffffe170: 0x00000000 0x00000000
At 0x7fffffffe148, we have rewrote 1 byte of the stack cookie value saved on RSP (thats why the breakpoint 2 stopped
__stack_chk_fail()). At 0x7fffffffe158 , we see the return address of main. So the structure of this canary should be like in figure 3:
There are 3 kinds of canaries:
15/21
22/10/2016
Null (0x0),
terminator (letting the first bytes to be \a0\xff),
random.
The first 2 kinds are easy to bypass[14], because you just have to fill the buffer with your shellcode, giving a desired value to be at the
right position and rewrite the instruction pointer. But for the random one, it is a little more fun, because you have to guess its value at
each execution (Ow! A kind like ASLR?).
For random canaries, the __gard__setup() fills a global variable with random bytes generated by /dev/urandom, if possible. Latter in
the program, only 4|8 bytes are used to be the cookie. But, if we cannot use the entropy of /dev/urandom, by default we will get a
terminator or a null cookie.
Brute-force is a way, but you will use to much time. By overwriting further than the return address, we can hook the execution flow using
GOT entries. The canary will of course detect the compromising, but too late. A very good article covering the StackGuard and StackShield
explain four ways to bypass these protections[15].
However, on new kernels you also have to noticed that the random cookie is set with a null-byte at the end, and trying to recover the
value from forking or brute-forcing will not work with functions like strcpy. So the better way to do that, is to have the control of the
initialized cookie.
Format string vulnerabilities or heap overflow for example, are more easy to exploit with this protection, but this article is not finished yet
and we will see another memory corruption mitigation technique.
RELRO
In recent Linux distributions, a memory corruption mitigation technique has been introduced to harden the data sections for
binaries/processes. This protection can be viewable reading the program headers (with readelf for example):
fluxiux@handgrep:~/ssp$ readelf -l vuln3

[...]
Program Headers:
[...]
GNU_RELRO
0x0000000000000e28 0x0000000000600e28 0x0000000000600e28
0x00000000000001d8 0x00000000000001d8 R
On current Linux, your binaries are often compiled with RELRO. So that mean that following sections are mapped as read-only:
08
.ctors .dtors .jcr .dynamic .got
Optionally, you can compare dissecting a non-RELRO binary, as follows:
fluxiux@handgrep:~/ssp$ gcc -Wl,-z,norelro vuln2.c -o vuln4

[]
LOAD
0x0000000000000768 0x0000000000600768 0x0000000000600768

0x0000000000000200 0x0000000000000210 RW
200000
[]
03
.ctors .dtors .jcr .dynamic .got .got.plt .data .bss
[...]
16/21
22/10/2016
The exploitation of a format string bug for example, using the format parameter %n to write to any arbitrary address like GOTs is
suppose to fail. But as we noticed previously, PLT GOTs have write permissions and then we are face to a partial-RELRO only.
With the example in trapkits article about RELRO[16], we could see that it is very easy to rewrite a PLT entry. But in some cases (mostly
in dist-packages), binaries are compiled with a full-RELRO:
fluxiux@handgrep:~/relro$ gcc -Wl,-z,relro,-z,now -o fullrelro fmstr.c

[..]
fluxiux@handgrep:~/relro$ readelf -l ./fullrelro | grep "RELRO"
GNU_RELRO
0x0000000000000df8 0x0000000000600df8 0x0000000000600df8
fluxiux@handgrep:~/relro$ readelf -d ./fullrelro | grep "BIND"

0x0000000000000018 (BIND_NOW)
Note: BIND_NOW indicates that the binary is using full-RELRO.
The entire GOT is remapped as read-only, but there are other sections to write on. GOTs are use mostly for flexibility. Detour with .dtors
can be perform as Sebastian Krahmer described in his article about RELRO[17].
We have seen common Linux protection used by default, but the evolution of kernels and architectures have made things more difficult.
The x86_64 fact and current systems hardening

With time, the new versions of Linux distribution become well hardened by default. In my studies, the Ubuntu one surprised me a lot,
because in addition to these protections implanted by default, this system turns to take some openBSD solutions to be as user friendly and
secure as possible. Moreover, we have seen few protections and ways to bypass it, but the 64-bits give us other difficulties.
As you notices, addresses have changed and it more difficult to exploit some memory corruption because of the byte \x00, considered as
a EOF for some functions like strcpy(). We saw that NX is enabled and the compilation in gcc with its support are made by default. But
the worst is coming. Indeed, we now that the randomization space is larger but what interest us, is the System V ABI for x86_64[8].
Things have changed for parameters in functions. Indeed, instead of copying parameters in the stack, the first 6 integer and 8
float/double/vector arguments are passed in registers, rest on stack. See an example:
// Passing arguments example

typedef struct {
int a, b;
double d;
} structparm;
structparm s;
int e, f, g, h, i, j, k;
long double ld;
double m, n;
__m256 y;
extern void func (int e, int f,
structparm s, int g, int h,
17/21
22/10/2016
long double ld, double m,

__m256 y,
double n, int i, int j, int k);
func (e, f, s, g, h, ld, m, y, n, i, j, k);
The given register allocation looks like this (in figure 4):
I suggest you to read the slides Jon Larimer about Intro to x64 Reversing[18].
We could use the knowledge of borrowed code chunks article[19] that can help us to understand problems of NX, System V ABI x86_64
differences with x32, and ways to bypass them using instructions to write a value on one register, and call the function system(), for
example, that will use this register as a parameter.
Other sophisticated attacks like Return-oriented Programing are use to bypass these protection that make life difficult in an exploit
process.
As you could see, protections didnt make things impossible, but just harder and harder. So be aware of new applied protections and
conventions to not waste too much time.
References & Acknowledgements

[1] ELF HOWTO
http://cs.mipt.ru/docs/comp/eng/os/linux/howto/howto_english/elf/elf-howto-1.html
[2] Tool Interface Standard (TIS) Executable and
Linking Format (ELF) Specification
[3] Working with the ELF Program

Format http://www.ouah.org/RevEng/x430.htm
[4] Executable_and_Linkable_Format#Applications
-http://www.linuxjournal.com/article/1060
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format#Applications
[5] elf.h: ELF types, structures, and macros
http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/elf.h
[6] The ELF Object File Format by Dissection
http://www.linuxjournal.com/article/1060
[7] Smashing the stack for fun and Profit
http://www.phrack.org/issues.html?issue=49&id=14#article
[8] System V Application Binary Interface on x86-64
18/21
22/10/2016
http://www.x86-64.org/documentation/abi.pdf
[9] Hacking The art of exploitation (by Jon
Erickson)
[10] Local bypass of Linux ASLR through /proc
information leaks
http://blog.cr0.org/2009/04/local-bypass-of-linux-aslr-through-proc.html
[11] Fuzzy ASLR http://code.google.com/p/fuzzyaslr/
[12] ASLR bypass using ret2reg
http://www.exploit-db.com/download_pdf/17049
[13] /dev/urandom
http://en.wikipedia.org/wiki//dev/urandom
[14] Stack Smashing Protector (FreeBSD)
http://www.hackitoergosum.org/2010/HES2010-prascagneres-Stack-Smashing-Protector-in-FreeBSD.pdf
[15] Four different tricks to bypass StackShield and
StackGuard protection
http://www.coresecurity.com/files/attachments/StackguardPaper.pdf
http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.http://tk-blog.blogspot.com/2009/02/relro-not-so-well-knownmemory.htmlhtml
[17] RELRO by Sebastian Krahmer
http://www.suse.de/%7Ekrahmer/relro.txt
[18] Intro to x64 reversing
http://lolcathost.org/b/introx86.pdf
[19] x86-64 buffer overflow exploits and the borrowed
code chunks http://www.suse.de/~krahmer/no-nx.pdf
This entry was posted in Uncategorized. Bookmark the permalink.
October 21, 2011 at 8:05 am

Excellent sum-up of ELF attack and defense, I really appreciated reading it.
It just miss one little trick to workaround ASLR that I noticed under Linux. So, this is Linux specific and wont work on any other POSIX system.
Basically, it plays with processes personality flags to mark a process to be out of ASLR. The good thing is that it do not require to be system
administrator to trigger it on and off. The bad thing being that it will break if you try to apply it to setuid programs (this is for obvious security
reasons).
So, the idea is that every process under Linux has personality flags that are inherited by all its childs. And one of these flag is about having the
ASLR activated or not. Triggering these flags is done through the command setarch (read man setarch to know more about it).
So, if you execute the following command, you will start a fresh shell environment where ASLR will be totally deactivated: setarch `uname -m`
addr-no-randomize /bin/bash
I tell this trick to my students to practice and try out things on systems where they do not have root access.
19/21
22/10/2016

Hope this helped ! And keep going on this blog, it is really interesting and you are really good at writing.
Reply
October 22, 2011 at 12:55 am

Nice trick perror =)! I didnt know that. By the way, I think we can play with that to try if there are some weaknesses.
Ill put this trick in the article anyway. Its interested to give people the possibility to disable the ASLR being a simple user =)
Thank you!
Reply
November 28, 2011 at 4:28 pm

WoW great document!
Thnx for your effort

Reply
November 30, 2011 at 11:27 pm

And thanks for reading it =)
Reply
May 31, 2013 at 9:52 am

Nice article, but I found one error.
The program header is only required in executables. Object files and shared objects do not need it.
Reply
Pingback:
20/21
22/10/2016
21/21

ELF Format Analysis and Exploitation Techniques

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ELF Format Analysis and Exploitation Techniques

Загружено:

Авторское право:

Доступные форматы

22/10/2016

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

Posted on October 20, 2011 by FlUxIuS

Basics in Linux, asm x86,

The ELF format

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

The ELF format

It is much simpler to make shared libraries,

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

Dissecting the ELF

fluxiux@nyannyan:~$ file /bin/ls

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

/* File class byte index */

/* Data encoding byte index */

/* Invalid data encoding */

Reversing ELFs header

Now, we observe the ELF header:

fluxiux@nyannyan:~$ readelf -h toto

2's complement, little endian

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

/* AMD x86-64 architecture */

/* Legal values for e_version (version). */

/* Invalid ELF version */

Program Headers with 6 headers, starting at byte 64 (byte 32 and 33 in hexdump),

fluxiux@nyanyan:~$ readelf -S toto.o

Flags Link Info Align

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

Code sections (.text),

fluxiux@nyannyan:~$ gcc toto.o -o toto

Flags Link Info Align

Wow! Some new sections appeared:

.interp which holds pathname of the program interpreter,

fluxiux@nyannyan:~$ readelf -r toto

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

Relocation section '.rela.dyn' at offset 0x380 contains 1 entries:

Sym. Value Sym. Name + Addend

000000600fe0 000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0

Sym. Value Sym. Name + Addend

000000601000 000100000007 R_X86_64_JUMP_SLO 0000000000000000 printf + 0

/* x86-64 relocation types, taken from asm-x86_64/elf.h */

/* Create GOT entry */

/* Create PLT entry */

fluxiux@nyanyan:~$ readelf -W -l toto

FileSiz MemSiz Flg Align

0x000040 0x0000000000400040 0x0000000000400040 0x0001f8 0x0001f8 R E 0x8

fluxiux@nyannyan:~$ readelf -d toto

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

Shared library: [libc.so.6]

Figure 2 64-bit Page Table Entry

Using readlef -l you can see if the stack is executable or not :

0x0000000000000000 0x0000000000000000 0x0000000000000000

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

Address Space Layout Randomization

# echo 0 > /proc/sys/kernel/randomize_va_space

$ setarch `uname -m` -R /bin/bash

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

The Art Of ELF: Analysis and Exploitations | FlUxIuS' Blog

7ffd77890000-7ffd77a1a000 r-xp 00000000 08:05 396967

7ffd77a1a000-7ffd77c19000 ---p 0018a000 08:05 396967

7ffd77c19000-7ffd77c1d000 r--p 00189000 08:05 396967

7ffd77c1d000-7ffd77c1e000 rw-p 0018d000 08:05 396967

7ffd77c1e000-7ffd77c24000 rw-p 00000000 00:00 0