04 Buffer Overflow

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 36
At a glance
Powered by AI
The key takeaways are that buffer overflow is a common security flaw that can be exploited to inject and execute malicious code by overwriting memory, such as the return address on the stack. The document discusses stack-based buffer overflows in depth, including the steps to create an exploit, various countermeasures, and how ASLR works to defend against these attacks.

The main steps involved in creating a buffer overflow exploit are: finding the offset to overwrite the return address, placing shellcode in the buffer, constructing a malicious file containing the shellcode and offset, and executing the exploit to divert program flow to the shellcode.

Some common countermeasures against buffer overflow attacks discussed are: using safer string functions, Address Space Layout Randomization (ASLR), stack canaries, non-executable stacks, and privilege dropping in shells like bash.

Buffer Overflow Attack

Outline
● Understanding of Stack Layout
● Vulnerable code
● Challenges in exploitation
● Shellcode
● Countermeasures
Program Memory Stack

a,b, ptr

ptr points to
the memory
here
y
x
Order of the function arguments in stack
Function Call Stack
void f(int a, int b)
{
int x;
}
void main()
{
f(1,2);
printf("hello world");
}
Stack Layout for Function Call Chain

main()

foo()

bar()
Vulnerable Program
 Reading 300 bytes of data from
badfile.

 Storing the file contents into a str


variable of size 400 bytes.

 Calling foo function with str as an


argument.

Note : Badfile is created by the user


and hence the contents are in control
of the user.
Vulnerable Program
Consequences of Buffer Overflow
Overwriting return address with some random address can point to :

• Invalid instruction
• Non-existing address
• Access violation
• Attacker’s code Malicious code to gain access
How to Run Malicious Code
Environment Setup
Creation of The Malicious Input (badfile)
Task A : Find the offset distance between the base of the buffer and return address.
Task B : Find the address to place the shellcode
Task A : Distance Between Buffer Base
Address and Return Address

Therefore, the distance is 108 + 4 = 112


Task B : Address of Malicious Code
• Investigation using gdb

• Malicious code is written


in the badfile which is
passed as an argument to
the vulnerable function.

• Using gdb, we can find


the address of the
function argument.
Task B : Address of Malicious Code

• To increase the chances of jumping


to the correct address, of the
malicious code, we can fill the
badfile with NOP instructions and
place the malicious code at the end
of the buffer.

Note : NOP- Instruction that does


nothing.
The Structure of badfile
Badfile Construction
New Address in Return Address
Considerations :

The new address in the return address of function stack


[0xbffff188 + nnn] should not contain zero in any of its
byte, or the badfile will have a zero causing strcpy() to end
copying.

e.g., 0xbffff188 + 0x78 = 0xbffff200, the last byte


contains zero leading to end copy.
Execution Results
• Compiling the vulnerable code with all the countermeasures
disabled.

• Executing the exploit code and stack code.


A Note on Countermeasure
• On Ubuntu16.04, /bin/sh points to /bin/dash, which has a
countermeasure
• It drops privileges when being executed inside a setuid process
• Point /bin/sh to another shell (simplify the attack)

• Change the shellcode (defeat this countermeasure)

• Other methods to defeat the countermeasure will be discussed later


Shellcode
Aim of the malicious code : Allow to run more commands (i.e) to
gain access of the system.

Solution : Shell Program

Challenges :
• Loader Issue
• Zeros in the code
Shelllcode
• Assembly code (machine instructions) for launching a shell.

• Goal: Use execve(“/bin/sh”, argv, 0) to run shell

• Registers used:
eax = 0x0000000b (11) : Value of system call execve()
ebx = address to “/bin/sh”
ecx = address of the argument array.
• argv[0] = the address of “/bin/sh”
• argv[1] = 0 (i.e., no more arguments)
edx = zero (no environment variables are passed).
int 0x80: invoke execve()
Shellcode

%eax = 0 (avoid 0 in code)


set end of string “/bin/sh”
Shellcode
Countermeasures
Developer approaches:
• Use of safer functions like strncpy(), strncat() etc, safer dynamic link
libraries that check the length of the data before copying.
OS approaches:
• ASLR (Address Space Layout Randomization)
Compiler approaches:
• Stack-Guard
Hardware approaches:
• Non-Executable Stack
Principle of ASLR

To randomize the start location of the stack that is every time the code
is loaded in the memory, the stack address changes.

Difficult to guess the stack address in the memory.

Difficult to guess %ebp address and address of the malicious code


Address Space Layout Randomization
Address Space Layout Randomization :
Working

1
2

3
ASLR : Defeat It
1. Turn on address randomization (countermeasure)
% sudo sysctl -w kernel.randomize_va_space=2

2. Compile set-uid root version of stack.c


% gcc -o stack -z execstack -fno-stack-protector stack.c
% sudo chown root stack
% sudo chmod 4755 stack
ASLR : Defeat It
3. Defeat it by running the vulnerable code in an infinite loop.
ASLR : Defeat it
On running the script for about 19 minutes on a 32-bit Linux
machine, we got the access to the shell (malicious code got
executed).
Stack guard
Execution with StackGuard

Canary check done by compiler.


Defeating Countermeasures in bash & dash
• They turn the setuid process into a non-setuid process
• They set the effective user ID to the real user ID, dropping the privilege
• Idea: before running them, we set the real user ID to 0
• Invoke setuid(0)
• We can do this at the beginning of the shellcode
Non-executable stack
• NX bit, standing for No-eXecute feature in CPU separates
code from data which marks certain areas of the memory as
non-executable.

• This countermeasure can be defeated using a different


technique called Return-to-libc attack (there is a separate
chapter on this attack)
Summary
• Buffer overflow is a common security flaw
• We only focused on stack-based buffer overflow
• Heap-based buffer overflow can also lead to code injection
• Exploit buffer overflow to run injected code
• Defend against the attack

You might also like