Buffer Overflow Attack and Vulnerable Programs

 
Buffer Overflow Attack
 
Outline
 
Understanding of Stack Layout
Vulnerable code
Challenges in exploitation
Shellcode
Countermeasures
 
Program Memory Stack
 
ptr
 points to
the memory
here
 
a,b, ptr
 
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
 
T
h
e
r
e
f
o
r
e
,
 
t
h
e
 
d
i
s
t
a
n
c
e
 
i
s
 
1
0
8
 
+
 
4
 
=
 
1
1
2
 
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
 
C
o
n
s
i
d
e
r
a
t
i
o
n
s
 
:
 
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
 
A
i
m
 
o
f
 
t
h
e
 
m
a
l
i
c
i
o
u
s
 
c
o
d
e
 
:
 
A
l
l
o
w
 
t
o
 
r
u
n
 
m
o
r
e
 
c
o
m
m
a
n
d
s
 
(
i
.
e
)
 
t
o
g
a
i
n
 
a
c
c
e
s
s
 
o
f
 
t
h
e
 
s
y
s
t
e
m
.
 
S
o
l
u
t
i
o
n
 
:
 
S
h
e
l
l
 
P
r
o
g
r
a
m
 
 
 
 
 
 
C
h
a
l
l
e
n
g
e
s
 
:
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
 
%
e
a
x
 
=
 
0
 
(
a
v
o
i
d
 
0
 
i
n
 
c
o
d
e
)
 
s
e
t
 
e
n
d
 
o
f
 
s
t
r
i
n
g
 
/
b
i
n
/
s
h
 
Shellcode
 
Countermeasures
 
D
e
v
e
l
o
p
e
r
 
a
p
p
r
o
a
c
h
e
s
:
Use of safer functions like strncpy(), strncat() etc, safer dynamic link
libraries that check the length of the data before copying.
O
S
 
a
p
p
r
o
a
c
h
e
s
:
ASLR (Address Space Layout Randomization)
C
o
m
p
i
l
e
r
 
a
p
p
r
o
a
c
h
e
s
:
Stack-Guard
H
a
r
d
w
a
r
e
 
a
p
p
r
o
a
c
h
e
s
:
Non-Executable Stack
 
Principle of ASLR
Difficult to guess %ebp address and address of the malicious code
Difficult to guess the stack address in the memory.
To randomize the start location of the stack that is every time the code
is loaded in  the memory, the stack address changes.
 
Address Space Layout Randomization
 
 
Address Space Layout Randomization :
Working
 
1
3
2
 
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.
 
T
h
i
s
 
c
o
u
n
t
e
r
m
e
a
s
u
r
e
 
c
a
n
 
b
e
 
d
e
f
e
a
t
e
d
 
u
s
i
n
g
 
a
 
d
i
f
f
e
r
e
n
t
t
e
c
h
n
i
q
u
e
 
c
a
l
l
e
d
 
R
e
t
u
r
n
-
t
o
-
l
i
b
c
 
a
t
t
a
c
k
 
(
t
h
e
r
e
 
i
s
 
a
 
s
e
p
a
r
a
t
e
c
h
a
p
t
e
r
 
o
n
 
t
h
i
s
 
a
t
t
a
c
k
)
 
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
Slide Note
Embed
Share

Understanding buffer overflow attacks and vulnerable programs, the consequences of such attacks, how to run malicious code, and the setup required for exploiting vulnerabilities in program memory stack layouts. Learn about creating malicious inputs (bad files), finding offsets, and addressing shellcode placement.

  • Buffer Overflow
  • Vulnerable Programs
  • Exploitation
  • Shellcode
  • Security

Uploaded on Oct 03, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Buffer Overflow Attack

  2. Outline Understanding of Stack Layout Vulnerable code Challenges in exploitation Shellcode Countermeasures

  3. Program Memory Stack a,b, ptr ptr points to the memory here y x

  4. Order of the function arguments in stack

  5. Function Call Stack void f(int a, int b) { int x; } void main() { f(1,2); printf("hello world"); }

  6. Stack Layout for Function Call Chain main() foo() bar()

  7. 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.

  8. Vulnerable Program

  9. 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

  10. How to Run Malicious Code

  11. Environment Setup

  12. 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

  13. Task A : Distance Between Buffer Base Address and Return Address Therefore, the distance is 108 + 4 = 112

  14. 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.

  15. 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.

  16. The Structure of badfile

  17. Badfile Construction

  18. 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.

  19. Execution Results Compiling the vulnerable code with all the countermeasures disabled. Executing the exploit code and stack code.

  20. 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

  21. 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

  22. 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()

  23. Shellcode %eax = 0 (avoid 0 in code) set end of string /bin/sh

  24. Shellcode

  25. 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

  26. 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

  27. Address Space Layout Randomization

  28. Address Space Layout Randomization : Working 1 2 3

  29. 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

  30. ASLR : Defeat It 3. Defeat it by running the vulnerable code in an infinite loop.

  31. 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).

  32. Stack guard

  33. Execution with StackGuard Canary check done by compiler.

  34. 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

  35. 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)

  36. 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

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#