Hey fellow pwners!

In the previous article, we discussed about function calling mechanisms in 32-bit and 64-bit Intel/AMD Systems. I hope you have understood those concepts properly because they are the foundations for this and many future posts.

In this article, we will look into one of the most infamous security vulnerabilities of all time, the amazing Buffer Overflow Vulnerability(BOF).You can think of this article as the beginning of a new sub-series because there are a lot of things to be discussed about BOF.

This is post number 7. So, create a directory with name post_7 in rev_eng_series directory.

Let us start!

Introduction

Before getting into details of BOF is, let us understand what a Security Vulnerability is, why is it caused, what are the problems of having such vulnerabilities in our systems.

Vulnerability

A Vulnerability is flaw in the code or design of the software. If you are able to do something the software is not intended to do, then that’s definitely a vulnerability. Let us take a small example to understand this better.

Consider a web server running on a machine. It is a process whose job is to serve specific webpages to clients who ask for it. Suppose a client finds a vulnerability in the web-server program and he does something that triggers the web-server process to crash and die, then that is unintended behavior. Crashing is not what we wanted out of that web-server. In this example, it is crashing. It could be any other behavior also.

Exploit

In the above example, we mentioned that the client does something to trigger the unintended behavior. That something is known as exploit. You exploit a vulnerability to enable the unintended behavior.

Why do vulnerabilities pop up?

a. Bad coding practices

b. Using unsecure API without knowledge of why they are unsecure and the problems behind it.

c. User Input plays a very key role here. In most cases, the way a person can trigger the vulnerability to make the software behave crazily is to give a crafted input to the software. Most software will have inputs from otuside. The input for PDF Readers is pdf files, the input for VLC Media player is a media file, for a server the input is the request from the client etc., If the input given from outside environment should ideally be processed, made sure it is clean and then pass it to the system. But many a times, this cleanliness check doesn’t happen. The user input is directly passed to the system. If the user is the bad guy, then we know what to wait for if the software has vulnerabilities. This concept of checking the the user input before passing it to the system is known as Sanity Check . Sanity is a fancy word for clean / proper.

Now, we just know the theory related to concepts like Vulnerability, Exploit, Reasons behind why vulnerabilities exist . Let us look at all these concepts using the Buffer Overflow Vulnerability. This way, we understand these concepts and understand BOF.

This article will have a lot of examples. The whole idea is to understand the above concepts well and understand BOF.

Buffer Overflow Vulnerability

Let us understand the name first. We know what a vulnerability is now. Let us understand what a Buffer Overflow is. For that,we will take the following simple example.

Program1

~/rev_eng_series/post_7$ cat code1.c
#include<stdio.h>
#include<string.h>

int main() {

        char buffer[10];
        scanf("%s", buffer);
        printf("buffer = %s, len(buffer) = %lu\n", buffer, strlen(buffer));

        return 0;
}

Overview

  1. It is a simple program.
  2. There is a buffer of size 10 bytes.
  3. We are using scanf to take user input and storing that user input into that buffer.
  4. The printf() statement prints the buffer contents and length of data stored in buffer.

Try out with different inputs

Let us compile the program normally and run it with several inputs.

~/rev_eng_series/post_7$ gcc code1.c -o code1

  1. Let us give an input of 4 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaa
buffer = aaaa, len(buffer) = 4

All good. We entered 4 bytes, it genuinely showed 4 bytes.

  1. Input of 6 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaa
buffer = aaaaaa, len(buffer) = 6

Even 6 bytes is fine.

if you think about it, any length till 10 bytes should be perfectly fine because we have a buffer of 10 bytes.

  1. Input of 10 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaa
buffer = aaaaaaaaaa, len(buffer) = 10

All good again, or is it really good? We will think about it a bit later.

Now after 10 bytes, any input should be invalid because we don’t have memory for input with length > 10 bytes . Let us continue our analysis

  1. Input of 11 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaa
buffer = aaaaaaaaaaa, len(buffer) = 11

Oh shit!! . That was unexpected! So, is there more memory for the buffer or what is happening? Let us continue the analysis

  1. Input of 13 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaaaa
buffer = aaaaaaaaaaaaa, len(buffer) = 13

  2. Input of 15 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaaaaaa
buffer = aaaaaaaaaaaaaaa, len(buffer) = 15

This has crossed all limits. We cannot accept this kind of behavior from our program.

  1. Input of 17 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaaaaaaaa
buffer = aaaaaaaaaaaaaaaaa, len(buffer) = 17

  2. Input of 20 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaaaaaaaaaaa
buffer = aaaaaaaaaaaaaaaaaaaa, len(buffer) = 20

  3. Input of 24 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaaaaaaaaaaaaaaa
buffer = aaaaaaaaaaaaaaaaaaaaaaaa, len(buffer) = 24

  4. Input of 28 bytes :

    ~/rev_eng_series/post_7$ ./code1
aaaaaaaaaaaaaaaaaaaaaaaaaaaa
buffer = aaaaaaaaaaaaaaaaaaaaaaaaaaaa, len(buffer) = 28
*** stack smashing detected ***: ./code1 terminated
Aborted (core dumped)

Finally something happened. For 28 bytes(or from 25 to 28 bytes) we got some error stack smashing detected and the program was terminated . It was Aborted in the middle.

NOTE : On your systems, this termination may or may not at 28 bytes, but you would notice this for some length of input. In some machines, the termination would have happened before 28 bytes, in some , you might have to try out longer inputs. But the concept is the same.

A quick recap of what we did.

We have a buffer of 10 bytes. So, we thought that any input upto length = 10 bytes is perfect and valid. But look at this case. It took in way more bytes than expected.Compare 10 bytes and 24 bytes.

It is safe to conclude that something fishy is happening. As security enthusiasts, we will look through the whole program, analyze every bit of it and find out the reason behind this.

Analysis with length of user input = 4 bytes

~/rev_eng_series/post_7$ gdb -q code1
Reading symbols from code1...(no debugging symbols found)...done.
gdb-peda$ disass main
Dump of assembler code for function main:
0x0000000000400646 <+0>:     push   rbp
0x0000000000400647 <+1>:     mov    rbp,rsp
0x000000000040064a <+4>:     sub    rsp,0x20
0x000000000040064e <+8>:     mov    rax,QWORD PTR fs:0x28
0x0000000000400657 <+17>:    mov    QWORD PTR [rbp-0x8],rax
0x000000000040065b <+21>:    xor    eax,eax
0x000000000040065d <+23>:    lea    rax,[rbp-0x20]
0x0000000000400661 <+27>:    mov    rsi,rax
0x0000000000400664 <+30>:    mov    edi,0x400748
0x0000000000400669 <+35>:    mov    eax,0x0
0x000000000040066e <+40>:    call   0x400530 <__isoc99_scanf@plt>
0x0000000000400673 <+45>:    lea    rax,[rbp-0x20]
0x0000000000400677 <+49>:    mov    rdi,rax
0x000000000040067a <+52>:    call   0x4004f0 <strlen@plt>
0x000000000040067f <+57>:    mov    rdx,rax
0x0000000000400682 <+60>:    lea    rax,[rbp-0x20]
0x0000000000400686 <+64>:    mov    rsi,rax
0x0000000000400689 <+67>:    mov    edi,0x400750
0x000000000040068e <+72>:    mov    eax,0x0
0x0000000000400693 <+77>:    call   0x400510 <printf@plt>
0x0000000000400698 <+82>:    mov    eax,0x0
0x000000000040069d <+87>:    mov    rcx,QWORD PTR [rbp-0x8]
0x00000000004006a1 <+91>:    xor    rcx,QWORD PTR fs:0x28
0x00000000004006aa <+100>:   je     0x4006b1 <main+107>
0x00000000004006ac <+102>:   call   0x400500 <__stack_chk_fail@plt>
0x00000000004006b1 <+107>:   leave
0x00000000004006b2 <+108>:   ret
End of assembler dump.
gdb-peda$

  1. Construction of StackFrame:

    0x0000000000400646 <+0>:     push   rbp
0x0000000000400647 <+1>:     mov    rbp,rsp
0x000000000040064a <+4>:     sub    rsp,0x20

Note that the StackFrame is of size 32 bytes but our buffer size is just 10 bytes .

Let us start the dynamic analysis.

  1. Let us break at main

    gdb-peda$ b main
Breakpoint 1 at 0x40064a
gdb-peda$ run
[----------------------------------registers-----------------------------------]
RAX: 0x400646 (<main>:  push   rbp)
RBX: 0x0
RCX: 0x0
RDX: 0x7fffffffdaf8 --> 0x7fffffffdf27 ("XDG_VTNR=7")
RSI: 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/co
de1")
RDI: 0x1RBP: 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RSP: 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RIP: 0x40064a (<main+4>:        sub    rsp,0x20)
R8 : 0x400730 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x846
R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)
R12: 0x400550 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdae0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x400641 <frame_dummy+33>:   jmp    0x4005c0 <register_tm_clones>
0x400646 <main>:     push   rbp
0x400647 <main+1>:   mov    rbp,rsp
=> 0x40064a <main+4>:   sub    rsp,0x20
0x40064e <main+8>:   mov    rax,QWORD PTR fs:0x28
0x400657 <main+17>:  mov    QWORD PTR [rbp-0x8],rax
0x40065b <main+21>:  xor    eax,eax
0x40065d <main+23>:  lea    rax,[rbp-0x20]
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0016| 0x7fffffffda10 --> 0x0
0024| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
0032| 0x7fffffffda20 --> 0x1f7ffcca0
0040| 0x7fffffffda28 --> 0x400646 (<main>:      push   rbp)
0048| 0x7fffffffda30 --> 0x0
0056| 0x7fffffffda38 --> 0xa5eef25a008d45bd
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 1, 0x000000000040064a in main ()
gdb-peda$

  • Right now, the size of the StackFrame is 0. This means the top of the stack is the Old rbp value. So, Old rbp = 0x4006c0 .

  • Return Address is the value below Old rbp. So, Return Address = 0x7ffff7a2d830 . It is important to make note of these values.

  1. Let us go over the next 3 instructions one by one. After executing sub rsp, 0x20, this is the state:

    [----------------------------------registers-----------------------------------]
RAX: 0x400646 (<main>:  push   rbp)
RBX: 0x0
RCX: 0x0
RDX: 0x7fffffffdaf8 --> 0x7fffffffdf27 ("XDG_VTNR=7")
RSI: 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
RDI: 0x1RBP: 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RSP: 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RIP: 0x40064e (<main+8>:        mov    rax,QWORD PTR fs:0x28)
R8 : 0x400730 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x846
R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)
R12: 0x400550 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdae0 --> 0x1
R14: 0x0R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overfl
ow)[-------------------------------------code----------------------------------
---]
0x400646 <main>:     push   rbp   0x400647 <main+1>:   mov    rbp,rsp
0x40064a <main+4>:   sub    rsp,0x20
=> 0x40064e <main+8>:   mov    rax,QWORD PTR fs:0x28
0x400657 <main+17>:  mov    QWORD PTR [rbp-0x8],rax
0x40065b <main+21>:  xor    eax,eax
0x40065d <main+23>:  lea    rax,[rbp-0x20]   0x400661 <main+27>:  mov    rsi,rax
[------------------------------------stack----------------------------------
---]
0000| 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x0
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x000000000040064e in main ()
gdb-peda$
  • You can look at the difference. The StackFrame has grown from 0 bytes to 32 bytes. rsp has changed.
  1. Let us execute the next instruction - mov rax,QWORD PTR fs:0x28 :

  • Before executing it, note that there is a segment register fs used here. If you recall, we had discussed that segment registers are still used for some special purposes. Well, this is one of them. Before executing the instruction, let us see what the value of fs is.

    gdb-peda$ info register fs
fs             0x0      0x0
gdb-peda$

  • fs has a value of 0. It means fs:0x28 is the address 0 * 16 + 0x28 = 0x28.

  • Let us try accessing the address 0x28.

    gdb-peda$ x/w 0x28
0x28:   <error: Cannot access memory at address 0x28>
gdb-peda$

  • This is something to think about. We are not able to access the address 0x28.

  • NOTE all the above observations related to the segment register and this instruction. They are important for future discussions.

  • Let’s execute the instruction:

    gdb-peda$ ni
[----------------------------------registers-----------------------------------]
RAX: 0xb18237f783657500
RBX: 0x0
RCX: 0x0
RDX: 0x7fffffffdaf8 --> 0x7fffffffdf27 ("XDG_VTNR=7")
RSI: 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/co
de1")
RDI: 0x1
RBP: 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RSP: 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RIP: 0x400657 (<main+17>:       mov    QWORD PTR [rbp-0x8],rax)
R8 : 0x400730 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x846
R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)
R12: 0x400550 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdae0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x400647 <main+1>:   mov    rbp,rsp
0x40064a <main+4>:   sub    rsp,0x20
0x40064e <main+8>:   mov    rax,QWORD PTR fs:0x28
=> 0x400657 <main+17>:  mov    QWORD PTR [rbp-0x8],rax
0x40065b <main+21>:  xor    eax,eax
0x40065d <main+23>:  lea    rax,[rbp-0x20]
0x400661 <main+27>:  mov    rsi,rax
0x400664 <main+30>:  mov    edi,0x400748
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x0
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x0000000000400657 in main ()
gdb-peda$

  • mov rax, QWORD PTR fs:0x28 : This means rax should have some value. The value is 0x194f8f3c12c69800 . It is an 8-byte number - seems like a random number to me. Note that you might get an entirely different 8-byte value.

  1. let us execute the next instruction - mov QWORD PTR [rbp-0x8],rax :

  • That 8-byte number is copied onto memory with address = rbp-0x8 - which is an address in the StackFrame of 32-bytes.

  • Note the current stack state. Let us execute the next instruction. Focussing only the stack,

    ------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x194f8f3c12c69800
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x000000000040065b in main ()
gdb-peda$

  • Look at the address 0x7fffffffd9f8 . It was 0 before. Now, it is the 8-byte value.

NOTE : At this point, I can tell you that this is a security feature added by the compiler into programs with buffers. Why it is a security feature, what will it protect us from etc., will be discussed shortly.

  1. Let’s break at 0x000000000040066e <+40>: call 0x400530 < __isoc99_scanf@plt > .

    gdb-peda$ b *0x40066e
Breakpoint 2 at 0x40066e
gdb-peda$ continue
[----------------------------------registers-----------------------------------]
RAX: 0x0
RBX: 0x0
RCX: 0x0
RDX: 0x7fffffffdaf8 --> 0x7fffffffdf27 ("XDG_VTNR=7")
RSI: 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RDI: 0x400748 --> 0x7325 ('%s')
RBP: 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RSP: 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RIP: 0x40066e (<main+40>:       call   0x400530 <__isoc99_scanf@plt>)
R8 : 0x400730 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x846
R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)
R12: 0x400550 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdae0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x400661 <main+27>:  mov    rsi,rax
0x400664 <main+30>:  mov    edi,0x400748
0x400669 <main+35>:  mov    eax,0x0
=> 0x40066e <main+40>:  call   0x400530 <__isoc99_scanf@plt>
0x400673 <main+45>:  lea    rax,[rbp-0x20]
0x400677 <main+49>:  mov    rdi,rax
0x40067a <main+52>:  call   0x4004f0 <strlen@plt>
0x40067f <main+57>:  mov    rdx,rax
Guessed arguments:
arg[0]: 0x400748 --> 0x7325 ('%s')
arg[1]: 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>: push   r15)
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x194f8f3c12c69800
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 2, 0x000000000040066e in main ()
gdb-peda$

  • Let us analyze the arguments for scanf(). It has 2 arguments - first argument = “%s” and second argument = buffer . So, rdi should have the address of “%s” . rsi should have the value of buffer variable.

    • rdi = 0x400748 which is the format string. Just verify it if you want.

      gdb-peda$ x/s 0x400748
0x400748:       "%s"
gdb-peda$

    • rsi = 0x7fffffffd9e0 which is the buffer address. (Do not care about the value it has). According to us, the valid size of the buffer is 10 bytes . So, ideally buffer is from address 0x7fffffffd9e0 to 0x7fffffffd9ea - 10 bytes.

  1. Let us run scanf() and input 4 bytes.

    gdb-peda$ ni
aaaa
[----------------------------------registers-----------------------------------]
RAX: 0x1
RBX: 0x0
RCX: 0xa ('\n')
RDX: 0x7ffff7dd3790 --> 0x0
RSI: 0x1
RDI: 0x7fffffffd4c0 --> 0x0
RBP: 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:    push   r15)
RSP: 0x7fffffffd9e0 --> 0x61616161 ('aaaa')
RIP: 0x400673 (<main+45>:       lea    rax,[rbp-0x20])
R8 : 0x0
R9 : 0x7ffff7fd6700 (0x00007ffff7fd6700)
R10: 0x7ffff7dd1b78 --> 0x602410 --> 0x0
R11: 0x246
R12: 0x400550 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdae0 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x400664 <main+30>:  mov    edi,0x400748
0x400669 <main+35>:  mov    eax,0x0
0x40066e <main+40>:  call   0x400530 <__isoc99_scanf@plt>
=> 0x400673 <main+45>:  lea    rax,[rbp-0x20]
0x400677 <main+49>:  mov    rdi,rax
0x40067a <main+52>:  call   0x4004f0 <strlen@plt>
0x40067f <main+57>:  mov    rdx,rax
0x400682 <main+60>:  lea    rax,[rbp-0x20]
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9e0 --> 0x61616161 ('aaaa')
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x194f8f3c12c69800
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x0000000000400673 in main ()
gdb-peda$

  • Let us look at the whole StackFrame once.

    gdb-peda$ x/32xb $rsp
0x7fffffffd9e0: 0x61    0x61    0x61    0x61    0x00    0x00    0x00    0x00
0x7fffffffd9e8: 0x50    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9f0: 0xe0    0xda    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9f8: 0x00    0x98    0xc6    0x12    0x3c    0x8f    0x4f    0x19
gdb-peda$
    • I chose 32xb because our StackFrame is 32-bytes in size
    • Look at 0x7fffffffd9e0 - the Starting address of the buffer . It has 4 bytes we entered. 0x61(97) is the ascii value for a .
    • The rest of the StackFrame is filled with garbage values and zeroes.

  • Let us look a few more bytes beyond the StackFrame

    gdb-peda$ x/48xb $rsp
0x7fffffffd9e0: 0x61    0x61    0x61    0x61    0x00    0x00    0x00    0x00
0x7fffffffd9e8: 0x50    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9f0: 0xe0    0xda    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9f8: 0x00    0x98    0xc6    0x12    0x3c    0x8f    0x4f    0x19
0x7fffffffda00: 0xc0    0x06    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffda08: 0x30    0xd8    0xa2    0xf7    0xff    0x7f    0x00    0x00

    • Observe the 0x7fffffffda00 keenly. It has the Old rbp value in reverse order . It is stored like this: 0xc0-0x06-0x40-0x00-0x00-x00-x00-x00 but we know that it’s actual value is 0x00-0x00-0x00-0x00-0x00-0x40-0x06-0xc0 or 0x00000000004006c0 . The same goes with the Return Address. We know that Return Address is 0x00007ffff7a2d830 but it is stored in the reverse direction. There is a fundamental reason behind this. We will talk about it in detail at the end of the article.

    • Now, Calculate the gap between the first byte of buffer at 0x7fffffffd9e0 and Old rbp value at 0x7fffffffda00 is 32-bytes.

  1. The printf functions will all work fine. So, let us analyze statically the following instructions:

    0x000000000040069d <+87>:    mov    rcx,QWORD PTR [rbp-0x8]
=> 0x00000000004006a1 <+91>:    xor    rcx,QWORD PTR fs:0x28
0x00000000004006aa <+100>:   je     0x4006b1 <main+107>
0x00000000004006ac <+102>:   call   0x400500 <__stack_chk_fail@plt>
0x00000000004006b1 <+107>:   leave
0x00000000004006b2 <+108>:   ret

  • Note that the 8-byte value in the stack is copied into rcx register.

  • After copying it into rcx, xor rcx,QWORD PTR fs:0x28 is executed. So, essentially the following is happening:

    xor QWORD PTR[rbp-0x8], QWORD PTR fs:0x28

  • Note that it is not a real instruction. It cannot be because both operands are memory locations and that is not possible in Intel Architecture.

  • The xor instruction performs bitwise xor of the 2 operands present and store the result in the left/destination operand .

  • You might be thinking that fs:0x28 has an 8-byte value = 0x194f8f3c12c69800 . The same value is present at rbp-0x8 also. So, doesn’t xor of those give a 0 and finally register rcx will be zero. What kind of security feature is this? xoring the same values, getting a zero and then what? Let us move ahead and see.

  • Next instruction = je 0x4006b1 < main+107 > . If the result of xor is zero, then the zero flag of EFLAGS register is set. Note that zero flag is also set when 2 things become equal or if their difference is 0 . So, if the result is 0, then the jump of je 0x4006b1 < main+107 > is taken. If the result is not zero, then the jump is not taken. Here, the result is zero. So, then jump is taken. Directly it jumps to < +107 >: leave .

  1. Executing leave instruction:
  • Old rbp = 0x4006c0

  • So, after this is execution, ReturnAddress should be at the top of the stack and the rbp register should be loaded with 0x4006c0 . Focussing only on stack and rbp .

    [------------------------------------stack-------------------------------------]
0000| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0008| 0x7fffffffda10 --> 0x0
0016| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
0024| 0x7fffffffda20 --> 0x1f7ffcca0
0032| 0x7fffffffda28 --> 0x400646 (<main>:      push   rbp)
0040| 0x7fffffffda30 --> 0x0
0048| 0x7fffffffda38 --> 0x78f3da2cdce900f4
0056| 0x7fffffffda40 --> 0x400550 (<_start>:    xor    ebp,ebp)
[------------------------------------------------------------------------------]
  • Register rbp = 0x4006c0 .
  1. ret is executed and the main function returns.

Here, our analysis for one input of length 4 bytes ends. It was a long analysis because there were a few concepts like the usage of segment register, storing bytes in reverse order etc., to be explained.

Let us do the analysis for InputLength = 28 bytes where was got a new error(stack smashing detected) and the program terminated . We have got to see why it happened.

Analysis with length of user input = 28 bytes

This time, we have to stop at these specific points:

    • 0x40064e < main+8 >: mov rax,QWORD PTR fs:0x28
    • 0x400657 < main+17 >: mov QWORD PTR [rbp-0x8],rax - To checkout the 8-byte value
    • 0x000000000040066e <+40>: call 0x400530 <__isoc99_scanf@plt > - To analyze the stack before and after **scanf** .

    • 0x40069d <+87>: mov rcx,QWORD PTR [rbp-0x8] and execute instructions one by one from here.

      ~/rev_eng_series/post_7$ gdb -q code1
Reading symbols from code1...(no debugging symbols found)...done.
gdb-peda$ b *0x40064e
Breakpoint 1 at 0x40064e
gdb-peda$ b *0x400657
Breakpoint 2 at 0x400657
gdb-peda$ b *0x000000000040066e
Breakpoint 3 at 0x40066e
gdb-peda$ b *0x40069d
Breakpoint 4 at 0x40069d
gdb-peda$ run

    • Let us focus on code and stack .

      [-------------------------------------code-------------------------------------]
0x400646 <main>:     push   rbp
0x400647 <main+1>:   mov    rbp,rsp
0x40064a <main+4>:   sub    rsp,0x20
=> 0x40064e <main+8>:   mov    rax,QWORD PTR fs:0x28
0x400657 <main+17>:  mov    QWORD PTR [rbp-0x8],rax
0x40065b <main+21>:  xor    eax,eax
0x40065d <main+23>:  lea    rax,[rbp-0x20]
0x400661 <main+27>:  mov    rsi,rax
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x0
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
        
Breakpoint 1, 0x000000000040064e in main ()
gdb-peda$

NOTE : The stack addresses while running this time and during previous analysis are different. Do not worry about that.

  • You can see that StackFrame size is 32 bytes. Old rbp = 0x4006c0 and Return Address = 0x7ffff7a2d830 .
  1. Let us run the next instruction - mov rax,QWORD PTR fs:0x28 :

  • After this was executed, the rax register has 0x80f8111d0d2a2800 . Note that is is entirely different from the value we saw in previous analysis.

  • Then in the next instruction, the 8-byte value is copied to the stack.

  1. Breakpoint at scanf :

  • Before executing call 0x400530 < __isoc99_scanf@plt > :

    [-------------------------------------code-------------------------------------]
0x400661 <main+27>:  mov    rsi,rax
0x400664 <main+30>:  mov    edi,0x400748
0x400669 <main+35>:  mov    eax,0x0
=> 0x40066e <main+40>:  call   0x400530 <__isoc99_scanf@plt>
0x400673 <main+45>:  lea    rax,[rbp-0x20]
0x400677 <main+49>:  mov    rdi,rax
0x40067a <main+52>:  call   0x4004f0 <strlen@plt>
0x40067f <main+57>:  mov    rdx,rax
Guessed arguments:
arg[0]: 0x400748 --> 0x7325 ('%s')
arg[1]: 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>: push   r15)
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9e0 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0008| 0x7fffffffd9e8 --> 0x400550 (<_start>:    xor    ebp,ebp)
0016| 0x7fffffffd9f0 --> 0x7fffffffdae0 --> 0x1
0024| 0x7fffffffd9f8 --> 0x80f8111d0d2a2800
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 3, 0x000000000040066e in main ()
gdb-peda$

    • Let us checkout the stack once.

      gdb-peda$ x/48wb $rsp
0x7fffffffd9e0: 0xc0    0x06    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9e8: 0x50    0x05    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9f0: 0xe0    0xda    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9f8: 0x00    0x28    0x2a    0x0d    0x1d    0x11    0xf8    0x80
0x7fffffffda00: 0xc0    0x06    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffda08: 0x30    0xd8    0xa2    0xf7    0xff    0x7f    0x00    0x00
gdb-peda$

    • rbp = 0x7fffffffd9f8 . (rbp-0x8) = 0x7fffffffd9f0 . Note that the 8-byte value is stored here (in the reverse order ofcourse).

    • 0x7fffffffda00 has the Old rbp .

    • 0x7fffffffda08 has the Return Address .

  • After executing scanf: Remember to input 28 bytes

    gdb-peda$ ni

    • The code and stack part:

      [-------------------------------------code-------------------------------------]
0x400664 < main+30 >:  mov    edi,0x400748
0x400669 < main+35 >:  mov    eax,0x0
0x40066e < main+40>:  call   0x400530 <__isoc99_scanf@plt>
=> 0x400673 < main+45>:  lea    rax,[rbp-0x20]
0x400677 < main+49>:  mov    rdi,rax
0x40067a < main+52>:  call   0x4004f0 < strlen@plt>
0x40067f < main+57>:  mov    rdx,rax
0x400682 < main+60>:  lea    rax,[rbp-0x20]
[------------------------------------stack----------------------------------
---]
0000| 0x7fffffffd9e0 ('a' < repeats 28 times>)
0008| 0x7fffffffd9e8 ('a' < repeats 20 times>)
0016| 0x7fffffffd9f0 ('a' < repeats 12 times>)
0024| 0x7fffffffd9f8 --> 0x80f8110061616161
0032| 0x7fffffffda00 --> 0x4006c0 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffda08 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0048| 0x7fffffffda10 --> 0x0
0056| 0x7fffffffda18 --> 0x7fffffffdae8 --> 0x7fffffffdf00 ("/home/adwi/rev_eng_series/post_7/code1")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x0000000000400673 in main ()
gdb-peda$

    • Let us look at the stack using the x/ command.

      gdb-peda$ x/48xb $rsp
0x7fffffffd9e0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd9e8: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd9f0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd9f8: 0x61    0x61    0x61    0x61    0x00    0x11    0xf8    0x80
0x7fffffffda00: 0xc0    0x06    0x40    0x00    0x00    0x00    0x00    0x00
0x7fffffffda08: 0x30    0xd8    0xa2    0xf7    0xff    0x7f    0x00    0x00
gdb-peda$

    • Notice that the input entered is way bigger than the buffer. The Input is said to have overflown the buffer. We say water is overflowing when it the bucket has reached it’s maximum capacity and excess water is coming out of it. The same analogy applies here. Water here is the user input and buffer[10] is the Bucket. The user input is coming out of the buffer because it is bigger that the buffer[10]. I hope you got what buffer overflow is.

    • Note that first 24 bytes are as. The next 4 bytes are also as. These 4 bytes have overwritten the last 4 bytes of the 8-byte value. The Value which was 0x80f8111d0d2a2800 has now become 0x80f8110061616161 . To be accurate, 5-bytes of the 8-byte value has been overwritten. The NULL byte of the user input string is also there.

  1. Let us continue and stop at the next breakpoint - 0x40069d < main+87 >

  • Let us execute 0x40069d < main+87 >: mov rcx,QWORD PTR [rbp-0x8] and look at the value of rcx .

  • rcx = 0x80f8110061616161 .

  • We all know what might happen when we try to execute 0x4006a1 < main+91 >: xor rcx,QWORD PTR fs:0x28

  • fs:0x28 will have the original value of 0x80f8111d0d2a2800 and rbp-0x8 has the tampered value of 0x80f8110061616161 . As they are not equal, the xor doesn’t return 0 . So ,the 0x4006aa < main+100 >: je 0x4006b1 < main+107 > is not executed. If it is not executed, then 0x4006ac < main+102 >: call 0x400500 < __stack_chk_fail@plt > will get executed.

  • Now, we know that this function __stack_chk_fail@plt is executed. Look at the name of the function. It says Stack Check Failed . So, this is thefeature we are talking about. That 8-byte value not allow the length of a string in stack go beyond certain length. If it goes, the 8-byte value will get tampered. Let us see what happens if it is tampered.

    Legend: code, data, rodata, value
Stopped reason: SIGABRT
0x00007ffff7a42428 in __GI_raise (sig=sig@entry=0x6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
gdb-peda$

  • Stopped reason: SIGABRT

  • So, the program is aborted.

Our analysis is done now.

These are the key points to be noted:

  1. We understood and witnessed a Buffer Overflow. Woohoo!!

  2. Specifying the buffer size in C programs has no effect on the number of bytes that can be entered by the user. Here, buffer size was 10 bytes, but we could enter input of size more than 10 bytes.

  3. Saw that if that 8-byte value is corrupted, then the program execution comes to an end immediately. We did NOT see how this is benificial. We just saw the program crashed. We will look into it in detail in later posts.

  4. There are functions in C library which are problematic - we just saw scanf. It was ready to take in as many bytes as the user entered.

That security feature was not administered till 2003. So, it is interesting and important to see what the scene is without this feature.

Let us start!

Program2

We will take the following program for analysis:

~/rev_eng_series/post_7$ cat code2.c
#include<stdio.h>
#include<string.h>

void func(char *SrcBuf);

int main(int argc, char **argv) {

        func(argv[1]);
        return 0;
}

void func(char *SrcBuf) {

        char DstBuf[10];
        strcpy(DstBuf, SrcBuf);

        return;
}
  • As we have already seen scanf, Let us look at another problematic function in this program - strcpy .

Overview

  1. main function takes 1 argument.
  2. That argument is passed by reference to a function named func .
  3. func has a buffer named DstBuf of size = 10 bytes defined.
  4. The strcpy() function copies Data in 2nd argument into 1st argument. So, SrcBuf - which is the argument we pass to main is copied into DstBuf.

Analysis with input size 8 bytes

  1. Let us look at disassembly of func - because this is the function under scrutiny.

    ~/rev_eng_series/post_7$ gdb -q code2
Reading symbols from code2...(no debugging symbols found)...done.
gdb-peda$ disass func
Dump of assembler code for function func:
0x000000000040054f <+0>:     push   rbp
0x0000000000400550 <+1>:     mov    rbp,rsp
0x0000000000400553 <+4>:     sub    rsp,0x20
0x0000000000400557 <+8>:     mov    QWORD PTR [rbp-0x18],rdi
0x000000000040055b <+12>:    mov    rdx,QWORD PTR [rbp-0x18]
0x000000000040055f <+16>:    lea    rax,[rbp-0x10]
0x0000000000400563 <+20>:    mov    rsi,rdx
0x0000000000400566 <+23>:    mov    rdi,rax
0x0000000000400569 <+26>:    call   0x400400 <strcpy@plt>
0x000000000040056e <+31>:    nop
0x000000000040056f <+32>:    leave
0x0000000000400570 <+33>:    ret
End of assembler dump.
gdb-peda$

  • Let us statically analyze the function.

    • Construction of StackFrame: A StackFrame of 32 bytes is constructed for this function. Note that DstBuf is just 10 bytes.

    • rdi has the argument - the address of argv1 string. That is copied to location with address rbp - 0x18 .

    • For strcpy(), rdi will have the first argument and should be the address of DstBuf . Look at line < +16 > and < +23 > . rdi has the address rbp-0x10 . So, Address of DstBuf = rbp-0x10 .

    • rsi will have the second argument which is the Address of SrcBuf or argv1.

  1. Let us break at 0x0000000000400569 <+26>: call 0x400400 < strcpy@plt > . So, we will look at the stack before and after it is executed. We will run with “aaaaaaaa” as argument.

    [----------------------------------registers-----------------------------------]
RAX: 0x7fffffffd9c0 --> 0xff000000000000
RBX: 0x0
RCX: 0x0
RDX: 0x7fffffffdf1e ("aaaaaaaa")
RSI: 0x7fffffffdf1e ("aaaaaaaa")RDI: 0x7fffffffd9c0 --> 0xff000000000000
RBP: 0x7fffffffd9d0 --> 0x7fffffffd9f0 --> 0x400580 (<__libc_csu_init>: push
r15)
RSP: 0x7fffffffd9b0 --> 0x1
RIP: 0x400569 (<func+26>:       call   0x400400 <strcpy@plt>)
R8 : 0x4005f0 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x846
R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)
R12: 0x400430 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdad0 --> 0x2
R14: 0x0
R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x40055f <func+16>:  lea    rax,[rbp-0x10]
0x400563 <func+20>:  mov    rsi,rdx
0x400566 <func+23>:  mov    rdi,rax
=> 0x400569 <func+26>:  call   0x400400 <strcpy@plt>
0x40056e <func+31>:  nop
0x40056f <func+32>:  leave
0x400570 <func+33>:  ret
0x400571:    nop    WORD PTR cs:[rax+rax*1+0x0]
Guessed arguments:
arg[0]: 0x7fffffffd9c0 --> 0xff000000000000
arg[1]: 0x7fffffffdf1e ("aaaaaaaa")
arg[2]: 0x7fffffffdf1e ("aaaaaaaa")
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9b0 --> 0x1
0008| 0x7fffffffd9b8 --> 0x7fffffffdf1e ("aaaaaaaa")
0016| 0x7fffffffd9c0 --> 0xff000000000000
0024| 0x7fffffffd9c8 --> 0x0
0032| 0x7fffffffd9d0 --> 0x7fffffffd9f0 --> 0x400580 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffd9d8 --> 0x400548 (<main+34>:   mov    eax,0x0)
0048| 0x7fffffffd9e0 --> 0x7fffffffdad8 --> 0x7fffffffdef7 ("/home/adwi/rev_eng_series/post_7/code2")
0056| 0x7fffffffd9e8 --> 0x200000000
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 1, 0x0000000000400569 in func ()
gdb-peda$

  • Let us look at the stack using x/ command.

    gdb-peda$ x/48xb $rsp
0x7fffffffd9b0: 0x01    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9b8: 0x1e    0xdf    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9c0: 0x00    0x00    0x00    0x00    0x00    0x00    0xff    0x00
0x7fffffffd9c8: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9d0: 0xf0    0xd9    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9d8: 0x48    0x05    0x40    0x00    0x00    0x00    0x00    0x00
gdb-peda$

    • rdi has the address 0x7fffffffd9c0. So, this is where DstBuf starts. It should end at 0x7fffffffd9c0 + 0xa = 0x7fffffffd9ca . Note that there is no information about length of DstBuf or Ending address of DstBuf. So, the program has no idea of where DstBuf ends. We will see how this is a problem.

    • The old rbp = 0x7fffffffd9f0 is stored in reverse order at 0x7fffffffd9d0 .

    • Return Address = 0x0000000000400548 is stored in reverse order at 0x7fffffffd9d8 . Look at main’s disassembly and confirm this is the Return Address.

    • One important thing : We asked for a buffer of 10 bytes. But we have 16 bytes - 8 bytes addressed by 0x7fffffffd9c0 and the next 8 bytes addressed by 0x7fffffffd9c8. This is because the stack in a 64-bit machine is 8-bytes aligned. So, everything should happen in multiples of 8 in the stack. So, if we had asked for 11, 12, 13, 14, 15 or 16 bytes, we would have got a space of 16 bytes. If we had asked for 17 bytes, we would have got 24 bytes. Note this when you write programs. Save space by taking buffers which align to the stack(whose size is a multiple of 8 in 64-bit machines / multiple of 4 in 32-bit machines)

  • Remember that size of argument is 8 bytes - “aaaaaaaa”

  • Let us go ahead and run strcpy().

    gdb-peda$ ni

  • Now again, we will look at the stack.

    gdb-peda$ x/48xb $rsp
0x7fffffffd9b0: 0x01    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9b8: 0x1e    0xdf    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9c0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd9c8: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9d0: 0xf0    0xd9    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9d8: 0x48    0x05    0x40    0x00    0x00    0x00    0x00    0x00
gdb-peda$

    • As expected, “aaaaaaaa” is stored at 0x7fffffffd9c0 .

    • As we spoke about it, it would not matter even if we give 11, 12, 13, 14, 15 bytes because we have been allocated 16bytes for DstBuf. But, why can’t we store 16 bytes? Is there a problem? Let us see.

  • Rest of the program is simple. func() returns peacefully to main and main returns back and program exits normally .

Analysis with input size = 16 bytes

  1. We will follow the same procedure. Break at strcpy and observe the stack before and after it is executed.

    gdb-peda$ run aaaaaaaaaaaaaaaa
[----------------------------------registers-----------------------------------]
RAX: 0x7fffffffd9b0 --> 0x0RBX: 0x0
RCX: 0x0
RDX: 0x7fffffffdf16 ('a' <repeats 16 times>)
RSI: 0x7fffffffdf16 ('a' <repeats 16 times>)
RDI: 0x7fffffffd9b0 --> 0x0
RBP: 0x7fffffffd9c0 --> 0x7fffffffd9e0 --> 0x400580 (<__libc_csu_init>: push
r15)
RSP: 0x7fffffffd9a0 --> 0x1
RIP: 0x400569 (<func+26>:       call   0x400400 <strcpy@plt>)
R8 : 0x4005f0 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x846
R11: 0x7ffff7a2d740 (<__libc_start_main>:       push   r14)R12: 0x400430 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdac0 --> 0x2
R14: 0x0
R15: 0x0
EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x40055f <func+16>:  lea    rax,[rbp-0x10]
0x400563 <func+20>:  mov    rsi,rdx
0x400566 <func+23>:  mov    rdi,rax
=> 0x400569 <func+26>:  call   0x400400 <strcpy@plt>
0x40056e <func+31>:  nop
0x40056f <func+32>:  leave
0x400570 <func+33>:  ret
0x400571:    nop    WORD PTR cs:[rax+rax*1+0x0]
Guessed arguments:
arg[0]: 0x7fffffffd9b0 --> 0x0
arg[1]: 0x7fffffffdf16 ('a' <repeats 16 times>)
arg[2]: 0x7fffffffdf16 ('a' <repeats 16 times>)
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9a0 --> 0x1
0008| 0x7fffffffd9a8 --> 0x7fffffffdf16 ('a' <repeats 16 times>)
0016| 0x7fffffffd9b0 --> 0x0
0024| 0x7fffffffd9b8 --> 0x0
0032| 0x7fffffffd9c0 --> 0x7fffffffd9e0 --> 0x400580 (<__libc_csu_init>:   push   r15)
0040| 0x7fffffffd9c8 --> 0x400548 (<main+34>:   mov    eax,0x0)
0048| 0x7fffffffd9d0 --> 0x7fffffffdac8 --> 0x7fffffffdeef ("/home/adwi/rev_eng_series/post_7/code2")
0056| 0x7fffffffd9d8 --> 0x200000000
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
    
Breakpoint 1, 0x0000000000400569 in func ()
gdb-peda$

  • Stack before strcpy() is executed.

    gdb-peda$ x/48xb $rsp
0x7fffffffd9a0: 0x01    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9a8: 0x16    0xdf    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9b0: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9b8: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9c0: 0xe0    0xd9    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9c8: 0x48    0x05    0x40    0x00    0x00    0x00    0x00    0x00
gdb-peda$

    • All good.

    • Note that Old rbp = 0x00007fffffffd9e0 .

  • Let us execute strcpy() and then see what the stack looks like.

    gdb-peda$ x/48xb $rsp
0x7fffffffd9a0: 0x01    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7fffffffd9a8: 0x16    0xdf    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9b0: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd9b8: 0x61    0x61    0x61    0x61    0x61    0x61    0x61    0x61
0x7fffffffd9c0: 0x00    0xd9    0xff    0xff    0xff    0x7f    0x00    0x00
0x7fffffffd9c8: 0x48    0x05    0x40    0x00    0x00    0x00    0x00    0x00
gdb-peda$

    • Look carefully. We had 16 bytes for DstBuf with us. Yes. All 16 bytes are filled with 0x61 which is the ascii equivalent of a . But we know that all strings are NULL-terminated . Which means, a string will have a NULL character at the end which is also stored .

    • We have a string of length 16 bytes. Where is the NULL character? If you observe, it is present at 0x7fffffffd9c0 which is actually the starting address of rbp . So, the NULL character of the string has overwritten the Least Significant Byte of Old rbp.

    • The actual old rbp = 0x00007fffffffd9e0 . But now, due to this, Old rbp value has changed to 0x00007fffffffd900 .

    • The system doesn’t know all this has happened. It is innocent :P

  • Let us execute the following instructions:

    =>0x000000000040056e <+31>:    nop
0x000000000040056f <+32>:    leave
0x0000000000400570 <+33>:    ret
    • nop stands for No-Operation. I will discuss about it later.

  • Execute the leave instruction. After leave instruction, the rbp register will have the Old rbp value in the stack. You guessed it right! rbp will be loaded with this wrong old rbp value.

  • Look at rbp register. It has the value 0x7fffffffd900.

  • The return value is the same. Let us execute the ret instruction. This is the current state:

    [----------------------------------registers----------------------------------]RAX: 0x7fffffffd9b0 ('a' <repeats 16 times>)
RBX: 0x0
RCX: 0x7ffff7ab2d30 (<__strcpy_sse2_unaligned+864>:     )
RDX: 0x0
RSI: 0x7fffffffdf26 --> 0x4e54565f47445800 ('')
RDI: 0x7fffffffd9c0 --> 0x7fffffffd900 --> 0x0
RBP: 0x7fffffffd900 --> 0x0
RSP: 0x7fffffffd9d0 --> 0x7fffffffdac8 --> 0x7fffffffdeef ("/home/adwi/rev_eng_series/post_7/code2")
RIP: 0x400548 (<main+34>:       mov    eax,0x0)
R8 : 0x4005f0 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x5d (']')
R11: 0x7ffff7b94d08 --> 0xfff1e038fff1e028
R12: 0x400430 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdac0 --> 0x2
R14: 0x0
R15: 0x0
EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x40053d <main+23>:  mov    rax,QWORD PTR [rax]
0x400540 <main+26>:  mov    rdi,rax
0x400543 <main+29>:  call   0x40054f <func>
=> 0x400548 <main+34>:  mov    eax,0x0
0x40054d <main+39>:  leave
0x40054e <main+40>:  ret
0x40054f <func>:     push   rbp
0x400550 <func+1>:   mov    rbp,rsp
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd9d0 --> 0x7fffffffdac8 --> 0x7fffffffdeef ("/home/adwi/rev_eng_series/post_7/code2")
0008| 0x7fffffffd9d8 --> 0x200000000
0016| 0x7fffffffd9e0 --> 0x400580 (<__libc_csu_init>:   push   r15)
0024| 0x7fffffffd9e8 --> 0x7ffff7a2d830 (<__libc_start_main+240>:       mov   edi,eax)
0032| 0x7fffffffd9f0 --> 0x0
0040| 0x7fffffffd9f8 --> 0x7fffffffdac8 --> 0x7fffffffdeef ("/home/adwi/rev_eng_series/post_7/code2")
0048| 0x7fffffffda00 --> 0x2f7ffcca0
0056| 0x7fffffffda08 --> 0x400526 (<main>:      push   rbp)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x0000000000400548 in main ()
gdb-peda$

  • The system still doesn’t know that it is the wrong rbp value of main which is stored in the register. Let us continue and see what happens.

    [----------------------------------registers-----------------------------------]
RAX: 0x0RBX: 0x0
RCX: 0x7ffff7ab2d30 (<__strcpy_sse2_unaligned+864>:     )
RDX: 0x0RSI: 0x7fffffffdf26 --> 0x4e54565f47445800 ('')
RDI: 0x7fffffffd9c0 --> 0x7fffffffd900 --> 0x0
RBP: 0x0RSP: 0x7fffffffd910 --> 0x0
RIP: 0x0
R8 : 0x4005f0 (<__libc_csu_fini>:       repz ret)
R9 : 0x7ffff7de7ab0 (<_dl_fini>:        push   rbp)
R10: 0x5d (']')
R11: 0x7ffff7b94d08 --> 0xfff1e038fff1e028R12: 0x400430 (<_start>:        xor    ebp,ebp)
R13: 0x7fffffffdac0 --> 0x2
R14: 0x0
R15: 0x0EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction over
flow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x0
[------------------------------------stack----------------------------------
---]0000| 0x7fffffffd910 --> 0x0
0008| 0x7fffffffd918 --> 0x0
0016| 0x7fffffffd920 ('/' <repeats 16 times>)
0024| 0x7fffffffd928 ("////////")
0032| 0x7fffffffd930 --> 0x0
0040| 0x7fffffffd938 --> 0x0
0048| 0x7fffffffd940 --> 0x7fffffffd9b0 ('a' <repeats 16 times>)
0056| 0x7fffffffd948 --> 0x0
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x0000000000000000 in ?? ()
gdb-peda$

  • And it Segfaulted. SEGV stands for Segment Violation .

  • It says Invalid $PC address: 0x0 . Look at rip value. It is 0. rip / Instruction Pointer always points to the next instruction. Points simply means it has the address of the next instruction.

  • If you check, originally the rbp of main pointed to 0x7fffffffd9e0 –> 0x400580 (< __libc_csu_init >: push r15) . That was a valid instruction. But because the rbp was changed due to the string we entered, the changed rbp pointed to 0x00. So, now the program tried to access 0x00. Well, that is not possible.

  • The program can access the addresses given to it. Refer the /proc/PID/maps file. It tells what are the address spaces a particular program can access.

  • Bottom line is that we were able to change the rbp value . Here, the NULL value just overwrote 1 byte of rbp.

That’s it for this round of analysis

Extending the thought

  • Look at what we did previously. We changed the value of rbp and made the program SegFault.

  • In the previous example, the stack looked something like this:

    <Unused: 8-bytes><Value of SrcBuf: 8-bytes><DstBuf: 16-bytes><Oldrbp: 8-bytes><ReturnAddress: 8-bytes>

  • We overwrote 1 byte of Oldrbp - which resulted in a SegFault. But is that the only thing we can do?

Absolutely not. There are several other things we can do, like write whatever value we want for OldRbp , whatever value we want for ReturnAddress .

  • This was a very simple example. Say the stack of some other function looked like this.

    <Unused: 8-bytes><Value of SrcBuf: 8-bytes><DstBuf: 16-bytes><Variable1: 4-bytes><Variable2: 4-bytes><Variable 3: 2 bytes><Oldrbp: 8-bytes><ReturnAddress: 8-bytes>
    • There are other local variables also. We can overwrite them with whatever value we want. It is totally in our hands because those values can be totally controlled by the input we give.

  • And are SegFaults the only unintended behavior? Nope. In many cases, we can give a certain input and design the behavior. As in, the software will start behaving the way we want it to behave and not what it’s developers wanted it to actually behave.

  • That is like having complete control over the software(and infact the machine). If it is doing what you want to do, then that is gold!

  • One of the best things you can do is to overwrite the ReturnAddress with whatever address you want. We will look into it in the next article in detail.

Coming back to basics

After all these practicals, let us go back to the concepts we discussed in the beginning of the article.

Vulnerability : We saw that in these Buffer Overflows we saw, we had complete control over all the values(Can be variables, Old rbp, Return Address) after that Buffer. That is a vulnerability.

Exploit : Our inputs were very simple. Just inputting sufficiently long strings was resulting in a Segfault. So, you can think of of those long strings as exploits. Every exploit has a very specific aim. The aim of these long strings were to just SegFault the software. If we want to bring some other behavior other than SegFault, we will have to write / craft another exploit for it.

  • Unintended Behavior : We discussed about this already. SegFault is the unintended behavior we saw. Think about it. If you write software, do you want it to crash? Hell noo! But sorry, we are making it crash. With better exploits, we can bring about behavior which will be useful to us(attacker :P)

  • Reasons why this vulnerability showed up : The buffer was 10 bytes. But our inputs were way longer that 10 bytes. So, User Input is not being checked. Suppose if we check for Length of user input before copying it into the buffer, then we can necessary action against the inputs. Example: If Input length is <= 10 bytes, happily copy into the buffer. If Input Length is > 10 bytes, copy only the first 10 bytes into the buffer. Never ever leave the User Input unchecked. I hope you have got some clarity on what Sanity Check is.

  • Regarding vulnerable functions : It is sad to say, but there are many of them. A few are scanf, strcpy, gets, sprintf, strcat, strncat, memcpy etc., Most of them don’t do Length Checking. A few functions do, but under certain conditions, they can be vulnerable again. In this article, we saw 2 functions - scanf and strcpy. We will use every vulnerable function given as examples in future articles.

  • Can we do anything about this? : A big yes. Once we know the reason behind why the vulnerability exists, we have to patch it up. In the examples we saw, we could have done 2 things. We could have written code which does the Length checking or we could have used safe functions like strncpy in place of strcpy or fgets in place of scanf. These safe functions do take input of a specified length. Look at fgets :

    char *fgets(char *s, int size, FILE *stream);
    • First argument is the BufferName(say buffer or DstBuf). Second takes the size of the input to take in. It is generally the size of the Buffer. stream is stdin because we are accepting inputs from terminal.

Summary

  1. Basic concepts like Vulnerability, Exploit, Sanity Check etc., discussed with examples.

  2. Introduced the infamous Buffer Overflow vulnerability and explained those basic concepts with the help of BOF.

  3. We closely looked at the Stack before and after copy/ input, what exactly is happening that is the reason of the vulnerability.

A few interesting things

1. Regarding BOF:

This is just a very mild introduction to BOF. In the upcoming articles, we will go into depths of BOF, different exploits for BOF, we will write our own exploits to exploit a BOF and more.

2.The Security Feature in Program1:

I would like to say that it is an amazing security feature and it will take almost a complete post to discuss about it. We will definitely discuss it in one of the future articles.

3. SegFault as an unintended behavior:

This is the only unintended behavior we could bring about today. Is a SegFault something that an attacker wants to happen in a software? Absolutely. Take this example. There is a web-server which is serving pages to thousands of clients every minute. Suppose the attacker comes to know that there is a BOF and I can segfault the web-server process. Attacker would definitely go for it because the program crashes due to seg-fault. Then the web-server won’t be able to serve pages anymore. So, the genuine clients are denied of service. So, it results in a Denial of Service Attack(DoS Attack) . Of course if any of the modern servers crash, they are designed to come back again. What the attacker will do is, he keeps sending the required input to make the server crash continuously. This again is a DoS attack. Take a look at this Link. This has a list of BOF vulnerabilities which were/are present in the famous apache web-server. Notice the number of DoS Overflow vulnerabilities.

4. Why are the bytes stored in reverse order?

This is a very important concept and it is important that you understand it properly.

a. Let us take an example. Consider the number 0x1122334455667788 to be stored at the address 0x7fffffffd920. The normal / human way to store it is like this:

    0x7fffffffd920: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 

    or 

    0x7fffffffd920: 0X11 
    0x7fffffffd921: 0X22
    0x7fffffffd922: 0X33
    0x7fffffffd923: 0X44
    0x7fffffffd924: 0X55
    0x7fffffffd925: 0X66
    0x7fffffffd926: 0X77
    0x7fffffffd927: 0X88
  • Here, The Most Significant Byte - 0x11 is stored at the Lowest Address - 0x7fffffffd920 . The MSB or Big End of the 8-byte number is stored at the Lowest Address.

b. We can also store in the number like this:

    0x7fffffffd920: 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11

    or 

    0x7fffffffd920: 0x88
    0x7fffffffd921: 0x77
    0x7fffffffd922: 0x66
    0x7fffffffd923: 0x55
    0x7fffffffd924: 0x44
    0x7fffffffd925: 0x33
    0x7fffffffd926: 0x22
    0x7fffffffd927: 0x11
  • This is the reverse order. Here, the Lease Significant Byte - 0x88 is stored at the Lowest Address - 0x7fffffffd920 . The LSB or “Little End** of the 8-byte number is stored at the Lowest Address.

The Processor Architecture that follows the Big-End at Lowest Address byte order is said to be a Big-Endian Architecture. (Not Indian :P, End - ian)

The Processor Architecture that follows the Little-End at Lowest byte order is said to be a Little-Endian Architecture .

Intel Processors follow the Little-Endian Architecture. The SPARC processor follows Big-Endian Architecture.

In ARM’s Cortex-a8 processor, Instructions(Code) is stored in Little-Endian mode. The Data can be stored in either Big-Endian or Little-Endian mode - It is configurable at runtime. Read the discussion here

Wait, when we have a human-way(Big-Endian way) to store it, why do we even need this Little-Endian architecture?

There are 1 direct advantage of Little-Endian architecture over Big-Endian Architecture.

When you have a variable, the way to access it is by it’s Address. We will have it’s address and using the address, we access the memory location where the value of the variable is stored.

Consider the following C program:

    ~/rev_eng_series/post_7$ cat code3.c
    #include<stdio.h>
    int main() {

            unsigned long var = 0x1122334455667788;
            printf("Address of var = %p\n", &var);
            printf("var = 0x%lx, (unsigned)var = 0x%x, (unsigned short)var = 0x%x, (unsigned char)var = 0x%x\n", var, (unsigned)var, (unsigned short)var, (unsigned char)var);

            return 0;
    }
    ~/rev_eng_series/post_7$ gcc code3.c -o code3
    ~/rev_eng_series/post_7$ ./code3
    Address of var = 0x7fff632baf50
    var = 0x1122334455667788, (unsigned)var = 0x55667788, (unsigned short)var = 0x7788, (unsigned char)var = 0x88

Let us think about how the processor accesses it, how much time it takes to access these bytes.

1. Little-Endian Architecture:

This is how it is stored.

    0x7fff632baf50: 0x88 
    0x7fff632baf51: 0x77
    0x7fff632baf52: 0x66
    0x7fff632baf53: 0x55
    0x7fff632baf54: 0x44
    0x7fff632baf55: 0x33
    0x7fff632baf56: 0x22
    0x7fff632baf57: 0x11

  • If I want Byte 0((unsigned char)var), then I would just pick the first byte.

  • If I want Byte 0 and Byte 1((unsigned short)var), then I would pick the first byte and byte next to it.

  • If I want Byte 0, 1, 2 and 3((unsigned)var), then I would I would pick the first byte, byte next to it, byte next to it and the byte next to it.

  • Same goes with the whole number.

The point to understand is we are casting the same address into several datatypes. Whether you want to take 1 byte, 2 bytes, 4 bytes or 8 bytes, the Address always will be 0x7fff632baf50. The instructions change. For 1 byte, we know it will be BYTE PTR[address], for 2 bytes - WORD PTR[address] and so on.

So, casting takes no time.

1. Big-Endian Architecture:

This is how it is stored.

    0x7fff632baf50: 0x11 
    0x7fff632baf51: 0x22
    0x7fff632baf52: 0x33
    0x7fff632baf53: 0x44
    0x7fff632baf54: 0x55
    0x7fff632baf55: 0x66
    0x7fff632baf56: 0x77
    0x7fff632baf57: 0x88

  • Suppose I want 1 byte(the first byte), then I calculate the address of 0x88, then access it. Because what you have is 0x7fff632baf50. To access 0x88, I will have to do 0x7fff632baf50 + 0x7.

  • Suppose I want 2 bytes(0x7788), then I calculate address of 0x88, access it. Probably maintain a pointer to 0x88 which can be decremented to obtain 0x77(this is better than computing address of 0x77 ).

  • Suppose I want 4 bytes(0x55667788), then I calculate the address of 0x88, access it. Decrement pointer and access every byt till 0x55.

In this example, Little-Endian does less work to complete the same task.

One advantage of Big-Endian over Little-Endian arch is,

In a network, all Bytes travel in Big-endian fashion. So, A Little-Endian machine has to convert the bytes to Big-Endian before sending it across the network. It also has to convert back to Little-Endian when it receives the bytes. A Big-Endian machines doesn’t have to any of this. It will simply keep quiet.

These are just 2 aspects of Little-Endian and Big-Endian architecture which was discussed.

Look at this quora answer. It is really good and has links to other sites which explain the differences.

I hope you have got clarity on what Little and Big Endian architectures are and why bytes are stored in reverse order in the Intel Processors.

5. What is nop?

We encountered this instruction called nop during our analysis. nop is short form for No-OPeration . It is what it’s name says. It does nothing. nop is just a name for the instruction xchg eax, eax which does nothing. The reason why we need nop requires an indepth understanding of Processor Architecture, so probably in another post.

  • Note that nop instructions help a lot in writing good exploits. How and why of this statement will be answered in later articles. You will clearly understand it when you write your exploit.

With that, I hope I have covered almost all loose ends we had during analysis.

Conclusion

I realize that the post is a bit long, but the objective was to learn basic concepts, introduce BOF and I felt it would be better if all basics are in one article. Please go through the article slowly, understand every bit of it.

The best way to clearly understand all these concepts is to write small programs, play around with it, get segfaults etc.,

That is it for this post. We will continue from here in the next post. I really enjoyed writing this post. I hope you learn something new out of this.

Thanks you!

Go to next post: Buffer Overflow Vulnerability - Part2
Go to previous post: Program Execution Internals - Part2