Binary Exploitation 1

Buffer Overflows

(return-to-libc, ROP, Canaries, W^X, ASLR)

Chester Rebeiro

Indian Institute of Technology Madras

 Parts of Malware
• Two parts
Subvert execu+on:
change the normal execu6on behavior of the
program

Payload:
the code which the a;acker wants to execute

2
 Subvert Execu6on
• In applica6on so@ware
– SQL Injec6on

• In system so@ware
– Buffers overflows and overreads
– Heap: double free, use a@er free
– Integer overflows
– Format string
– Control Flow

• In peripherials
– USB drives; Printers

• In Hardware
– Hardware Trojans
These do not really subvert execu6on,
• Covert Channels but can lead to confiden6ality a;acks.
– Can exist in hardware or so@ware

3
 Buffer Overflows in the Stack
• We need to first know how a stack is managed

h;p://insecure.org/sR/smashstack.html 4
 Stack in a Program
(when function is executing)
Stack
ESP
ESP Parameters
for func6on
ESP
ESP return Address
ESP prev frame pointer EBP

Locals of func6on
ESP
In main In function
push $3 push %ebp
push $2 movl %esp, %ebp %ebp: Frame Pointer
push $1 sub $20, %esp %esp : Stack Pointer
call function

5
 Stack Usage (example)
Stack (top to bottom):
address stored data
1000 to 997 3

996 to 993 2

992 to 989 1
Parameters
for func6on 988 to 985 return address

984 to 981 %ebp (stored

Return Address frame pointer)
frame pointer prev frame pointer (%ebp)980 to 976 buffer1

Locals of func6on 975 to 966 buffer2

(%sp) 964
stack pointer
6
 Stack Usage Contd.
Stack (top to bottom):
address stored data
1000 to 997 3

996 to 993 2

992 to 989 1
What is the output of the following?
988 to 985 return address
• prinR(“%x”, buffer2) : 966
• prinR(“%x”, &buffer2[10]) 984 to 981 %ebp (stored
frame pointer)
976 à buffer1
(%ebp)980 to 976 buffer1
Therefore buffer2[10] = buffer1[0]
A BUFFER OVERFLOW 975 to 966 buffer2
(%sp) 964

7
 Modifying the Return Address
Stack (top to bottom):
buffer2[19] =
address stored data
&arbitrary memory location
1000 to 997 3

This causes execution of an 996 to 993 2

arbitrary memory location
instead of the standard return 992 to 989 1

988 to 985 Return Address

Arbitrary Loca6on

19 984 to 981 %ebp (stored

frame pointer)
(%ebp)980 to 976 buffer1

976 to 966 buffer2

(%sp) 964

8
 Stack (top to bottom):
address stored data
1000 to 997 3 Now that we seen how buffer
overflows can skip an instruction,
996 to 993 2

992 to 989 1 We will see how an attacker can use

it to execute his own code (exploit
988 to 985 ATTACKER’S code)
code pointer
984 to 981 %ebp (stored
frame pointer)
(%ebp)980 to 976 buffer1

976 to 966 buffer2

(%sp) 964

9
 Big Picture of the exploit
Fill the stack as follows
(where BA is buffer address) BA
BA
Parameters BA
for func6on BA
BA
Return Address
BA
frame pointer prev frame pointer
BA
buffer BA
stack pointer Exploit code BA
buffer Address

10
 Payload
• Lets say the attacker wants to spawn a shell
• ie. do as follows:

• How does he put this code onto the stack?

11
Step 1 : Get machine codes

• objdump –disassemble-all shellcode.o

• Get machine code : “eb 1e 5e 89 76 08 c6
46 07 00 c7 46 0c 00 00 00 00 b8 0b 00 00
00 89 f3 8d 4e 08 8d 56 0c cd 80 cd 80”
• If there are 00s replace it with other
instruc6ons

12
Step 2: Find Buffer overflow in an
application

Defined on stack

O
O
O
O
o

13
 Step 3 :
Put Machine Code in Large String

large_string
shellcode

14
 Step 3 (contd) :
Fill up Large String with BA

Address of buffer is BA

large_string
shellcode BA BA BA BA BA BA BA BA

15
 Final state of Stack
BA
BA
• Copy large string into buffer
BA
BA
BA
• When strcpy returns the BA
exploit code would be executed BA
BA
buffer
shellcode

large_string
shellcode BA BA BA BA BA BA BA BA BA
buffer Address
BA

16
Putting it all together

bash$ gcc overflow1.c

bash$ ./a.out
$sh

17
 Buffer overflow in the Wild
• Worm CODERED … released on 13th July 2001
• Infected 3,59,000 computers by 19th July.

18
 CODERED Worm
• Targeted a bug in Microsoft’s IIS web
server
• CODERED’s string
GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNN
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u909
0%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b
00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0

19
 Defenses
• Eliminate program flaws that could lead to subverting of execution
Safer programming languages; Safer libraries; hardware enhancements;
static analysis
• If can’t eliminate, make it more difficult for malware to subvert
execution
W^X , ASLR, canaries
• If malware still manages to execute, try to detect its execution at
runtime
malware run-time detection techniques using learning techniques, ANN and malware signatures
• If can’t detect at runtime, try to restrict what the malware can do..
– Sandbox system
so that malware affects only part of the system; access control; virtualization; trustzone; SGX
– Track information flow
DIFT; ensure malware does not steal sensitive information

20
Preven6ng Buffer Overflows
with Canaries and W^X

21
 Canaries
• Known (pseudo random) values placed Stack (top to bottom):
on stack to monitor buffer overflows. stored data
• A change in the value of the canary
3
indicates a buffer overflow.
• Will cause a ‘stack smashing’ to be 2
detected
1
ret addr

Insert a canary here

sfp (%ebp)
Insert canary here
buffer1
check if the canary value
has got modified buffer2

22
 Canaries and gcc
• As on gcc 4.4.5, canaries are not added to func6ons by default
o Could cause overheads as they are executed for every func6on
that gets executed
• Canaries can be added into the code by –fstack-protector op6on
o If -fstack-protector is specified, canaries will get added based on
a gcc heuris6c
• For example, buffer of size at-least 8 bytes is allocated
• Use of string opera6ons such as strcpy, scanf, etc.

o Canaries can be evaded quite easily by not altering the contents of

the canary

23
 Canaries Example
Without canaries, the return address on stack gets overwri;en resul6ng in a
segmenta6on fault. With canaries, the program gets aborted due to stack smashing.

24
 Canaries Example
Without canaries, the return address on stack gets overwri;en resul6ng in a
segmenta6on fault. With canaries, the program gets aborted due to stack smashing.

25
 Canary Internals

Store canary onto stack

Verify if the canary has Without canaries

changed

With canaries

gs is a segment that shows thread local data; in this case it is used

for picking out canaries

26
 Non Executable Stacks (W^X)
• In Intel/AMD processors, ND/NX bit present to mark non code
regions as non-executable.
– Exception raised when code in a page marked W^X executes
• Works for most programs
– Supported by Linux kernel from 2004
– Supported by Windows XP service pack 1 and Windows Server 2003
• Called DEP – Data Execution Prevention
• Does not work for some programs that NEED to execute from the
stack.
– Eg. JIT Compiler, constructs assembly code from external data and then
executes it.
(Need to disable the W^X bit, to get this to work)

27
27
 Will non executable
stack prevent buffer
overflow attacks ?

Return – to – LibC Attacks

(Bypassing non-executable stack
during exploitation using return-
to-libc attacks)

h;ps://css.csail.mit.edu/6.858/2010/readings/return-to-libc.pdf 28
28
 Return to Libc
(big picture)
BA
BA
BA
BA
Return Address BA
This will not work if ND bit is set
BA
BA
BA
buffer
Exploit code

29
29
 Return to Libc
(replace return address to point to a function within libc)

F1 Addr
F1 Addr Stack

F1 Addr
F1 Addr
Heap
Return Address F1 Addr
F1 Addr
F1 Addr Data
F1 Addr
buffer
F1 Addr

Text

Bypasses W^X since F1 is in the code segment,

And can be legally executed.
30
30
 F1 = system()
• One option is function system present in libc
system(“/bin/bash”);
would create a bash shell

(there could be other options as well)

So we need to
1. Find the address of system in the program
(does not have to be a user specified function, could be a function
present in one of the linked libraries)
2. Supply an address that points to the string
/bin/sh

31
31
 The return-to-libc attack
F1ptr
F1 ptr /bin/bash
Shell ptr
F1ptr
Return Address F1ptr
F1ptr
F1ptr system()
F1ptr In libc
buffer
F1ptr

32
32
Find address of system in the
executable

33
33
 Find address of /bin/sh
• Every process stores the enviroment variables at
the bottom of the stack
• We need to find this and extract the string /bin/sh
from it

34
34
Finding the address of the string
/bin/sh

35
 The final Exploit Stack
xxx
xxx /bin/sh
0xbwffe25
dead
Return Address 0x28085260
xxx
xxx system()
xxx In libc
buffer
xxx

36
 A clean exit
xxx
xxx /bin/bash
0xbwffe25
0x281130d0 exit()
Return Address 0x28085260 In libc
xxx
xxx system()
xxx In libc
buffer
xxx

37
 Limitation of ret2libc

Limita6on on what the a;acker can do

(only restricted to certain func6ons in the library)

These func6ons could be removed from the library

38
38
Return Oriented Programming
(ROP)

39
 Return Oriented Programming Attacks

• Discovered by Hovav Shacham of Stanford University

• Subverts execution to libc
– As with the regular ret-2-libc, can be used with non executable stacks since the
instructions can be legally execute
– Unlike ret-2-libc does not require to execute functions in libc (can execute any
arbitrary code)

The Geometry of Innocent Flesh on the Bone: Return-into-libc without Func6on Calls
(on the x86
40
 Target Payload
Lets say this is the payload needed to be executed by an attacker.

Suppose there is a function in libc, which has exactly this sequence of

instructions … then we are done.. we just need to subvert execution
to the function

What if such a function does not exist?

If you can’t find it then build it

41
 Step 1: Find Gadgets
• Find gadgets
• A gadget is a short sequence of instructions followed by a return
useful instruction(s)
ret
• Useful instructions : should not transfer control outside the gadget

• This is a pre-processing step by statically analyzing the libc library

42
 Step 2: Stitching
• Stitch gadgets so that the payload is built

movb $0x0, 0x7(%esi)

ret G2

movl $0xb, %eax G4

ret

movb $0x0, 0xc(%esi)

ret G3

Ret instruc6on has 2 steps: movl %esi, 0x8(%esi)

G1
ret
• Pops the contents pointed to by ESP into EIP
• Increment ESP by 4 (32bit machine)
Program Binary 43
 Step 3: Construct the Stack

xxx
AG4 movb $0x0, 0x7(%esi)
ret G2
AG3
movl $0xb, %eax G4
AG2 ret
Return Address AG1 movb $0x0, 0xc(%esi)
ret G3
xxx
xxx
xxx movl %esi, 0x8(%esi)
buffer G1
ret
xxx

Program Binary

Program Stack
AGi: Address of Gadget i 44
 Finding Gadgets
• Sta6c analysis of libc
• To find
1. A set of instruc6ons that end in a ret (0xc3)
The instruc6ons can be intended (put in by the compiler) or unintended
2. Besides ret, none of the instruc6ons transfer control out of the
gadget

45
 Intended vs Unintended Instruc6ons
• Intended : machine code inten6onally put in by the compiler
• Unintended : interpret machine code differently in order to build new
instruc6ons
Machine Code : F7 C7 07 00 00 00 0F 95 45 C3
What the compiler intended..

What was not ntended

Highly likely to find many diverse instruc6ons of this form in x86; not so likely to
have such diverse instruc6ons in RISC processors 46
 Geometry
• Given an arbitrary string of machine code, what is the
probability that the code can be interpreted as useful
instruc6ons.
– x86 code is highly dense
– RISC processors like (SPARC, ARM, etc.) have low geometry
• Thus finding gadgets in x86 code is considerably more easier
than that of ARM or SPARC
• Fixed length instruc6on set reduces geometry

47
 Finding Gadgets
• Sta6c analysis of libc
• Find any memory loca6on with 0xc3 (RETurn instruc6on)
• Build a trie data structure with 0xc3 as a root
• Every path (star6ng from any node, not just the leaf) to the root is a
possible gadget

C3
child of

00 46

24 89
24 43

94
37 16

48
 Finding Gadgets
33 b2 23 12 a0 31 a5 67 22 ab ba 4a 3c c3 ff ee ab 31 11 09

• Scan libc from the beginning toward the end

• If 0xc3 is found
– Start scanning backward
– With each byte, ask the ques6on if the subsequence forms a valid
instruc6on
– If yes, add as child
– If no, go backwards un6l we reach the maximum instruc6on length (20
bytes)
– Repeat this 6ll (a predefined) length W, which is the max instruc6ons in
the gadget

49
Finding Gadgets Algorithm

50
Finding Gadgets Algorithm

Found 15,121 nodes in

~1MB of libc binary

is this sequence of instruc6ons valid x86 instruc6on?

Boring: not interes6ng to look further;

Eg. pop %ebp; ret;;;; leave; ret (these are boring if we want to ignore intended instruc6ons)
Jump out of the gadget instruc6ons
51
 More about Gadgets
• Example Gadgets
– Loading a constant into a register (edx ß deadbeef)

pop %edx
deadbeef ret
esp GadgetAdd

• A previous return will pop the gadget address int %eip

• %esp will also be incremented to point to deadbeef
stack (4 bytes on 32 bit plaRorm)
• The pop %edx will pop deadbeef onto the stack and increment
%esp to point to the next 4 bytes on the stack

52
 S6tch
G1
pop %edx
G2
ret
addr G2
esp G1 mov 64(%edx), %eax
ret
+64

Load arbitrary data into eax register using

Gadgets G1 and G2
deadbeef

stack

53
 Store Gadget
• Store the contents of a register to a memory loca6on in the
stack
mov %eax, 24(%edx)
ret
GadgetAddr 2
0
esp GadgetAddr 1 pop %edx
ret
24

stack

54
 Gadget for addi6on
Add the memory pointed
to by %edx to %eax.
The result is stored in %eax

addl (%edx), %eax

push %edi pushes %edi.. onto the stack
Modified
GadgetAddr2 why is this present?
ret …. This is unnecessary, but
esp GadgetAddr
this is best gadget that we can
find for addi6on
But can create problems!!

stack We need work arounds!

55
 Gadget for addi6on
(put 0xc3 into %edi)
1. First put gadget ptr for 0xC3 into
%edi
2. 0xC3 corresponds to NOP in
addl (%edx), %eax ROP
GadgetAddr3 push %edi 3. Push %edi in gadget 2 just pushes
Gadget_RET
ret 0xc3 back into the stack
GadgetAddr2
Therefore not disturbing the stack
Gadget_RET
0xc3 contents
esp GadgetAddr1
4. Gadget 3 executes as planned
stack pop %edi
ret

0xc3 is ret ; in ROP ret is equivalent to NOP v

56
 Adding into %eax

addl (%edx), %eax

push %edi
ret
GadgetAddr3
X
GadgetAddr2
Gadget_RET
esp GadgetAddr1
pop %edi
ret

pop %edi
X deadbeef ret

stack

57
 Uncondi6onal Branch
in ROP
• Changing the %esp causes uncondi6onal
jumps

pop %esp
ret
esp GA

stack

58
 Condi6onal Branches
In x86 instruc+ons condi+onal branches have 2 parts

1. An instruc6on which modifies a condi6on flag (eg CF, OF, ZF)

eg. CMP %eax, %ebx (will set ZF if %eax = %ebx)
2. A branch instruc6on (eg. JZ, JCC, JNZ, etc)
which internally checks the condi6onal flag and
changes the EIP accordingly

In ROP, we need flags to modify %esp register instead of EIP

Needs to be explicitly handled

In ROP condi+onal branches have 3 parts

1. An ROP which modifies a condi6on flag (eg CF, OF, ZF)

eg. CMP %eax, %ebx (will set ZF if %eax = %ebx)
2. Transfer flags to a register or memory
3. Perturb %esp based on flags stored in memory

59
 Step 1 : Set the flags
Find suitable ROPs that set appropriate flags
CMP %eax, %ebx subtrac6on
RET Affects flags CF, OF, SF, ZF, AF, PF

NEG %eax 2s complement nega6on

RET Affects flags CF

60
 Step 2: Transfer flags to
memory or register
• Using lahf instruc6on
stores 5 flags (ZF, SF, AF, PF, CF) in the %ah register

• Using pushf instruc6on where would one

pushes the eflags into the stack use this
instruc6on?

ROPs for these two not easily found.

A third way – perform an opera6on whose result depends on the flag
contents.

61
Step 2: Indirect way to transfer flags to
memory
Several instruc6ons operate using the contents of the flags

ADC %eax, %ebx : add with carry; performs eax <- eax + ebx + CF

(if eax and ebx are 0 ini6ally, then the result will be either 1 or 0 depending on the CF)

RCL : rotate le@ with carry;

RCL %eax, 1
(if eax = 0. then the result is either 0 or 1 depending on CF)

62
Gadget to transfer flags to memory

%edx will have value A

%ecx will contain 0x0

63
 Step 3: Perturb %esp depending
on flag
What we hope to achieve
If (CF is set){
perturb %esp What we have One way of achieving …
}else{ CF stored in a memory loca6on (say X) negate X
leave %esp as it is Current %esp offset = delta & X
} delta, how much to perturb %esp %esp = %esp + offset

1. Negate X (eg. Using instruc6on negl)

finds the 2’s complement of X
if (X = 1) 2’s complement is 111111111…
if (X = 0) 2’s complement is 000000000...
2. offset = delta if X = 1
offset = 0 if X = 0
3. %esp = %esp + offset if X = 1
%esp = %esp if X = 0

64
 Turing Complete
• Gadgets can do much more…
invoke libc func6ons,
invoke system calls, ...
• For x86, gadgets are said to be turning complete
– Can program just about anything with gadgets
• For RISC processors, more difficult to find gadgets
– Instruc6ons are fixed width
– Therefore can’t find uninten6onal instruc6ons
• Tools available to find gadgets automa6cally
Eg. ROPGadget (h;ps://github.com/JonathanSalwan/ROPgadget)
Ropper (h;ps://github.com/sashs/Ropper)

65
Address Space Layout Randomiza+on
(ASLR)

66
 The A;acker’s Plan
• Find the bug in the source code (for eg. Kernel) that can be
exploited
– Eyeballing
– No6cing something in the patches
– Following CVE
• Use that bug to insert malicious code to perform something
nefarious
– Such as ge„ng root privileges in the kernel

ATacker depends upon knowning where these func+ons reside in

memory. Assumes that many systems use the same address mapping.
Therefore one exploit may spread easily

67
 Address Space Randomization
• Address space layout
randomization (ASLR)
randomizes the address space
layout of the process
• Each execution would have a
different memory map, thus
making it difficult for the attacker
to run exploits
• Initiated by Linux PaX project in
2001
• Now a default in many operating
systems

Memory layout across boots for a Windows box

68
 ASLR in the Linux Kernel
• Loca6ons of the base, libraries, heap, and stack can be randomized in a
process’ address space

• Built into the Linux kernel and controlled by

/proc/sys/kernel/randomize_va_space

• randomize_va_space can take 3 values

0 : disable ASLR
1 : posi6ons of stack, VDSO, shared memory regions are randomized
the data segment is immediately a@er the executable code
2 : (default se„ng) se„ng 1 as well as the data segment loca6on is
randomized

69
ASLR in Ac6on

First Run

Another Run

70
 ASLR in the Linux Kernel
• Permanent changes can be made by edi6ng the /etc/sysctl.conf file
/etc/sysctl.conf, for example:
kernel.randomize_va_space = value
sysctl -p

71
Internals : Making code relocatable
• Load +me relocatable
– where the loader modifies a program executable so
that all addresses are adjusted properly
– Relocatable code
• Slow load 6me since executable code needs to be modified.
• Requires a writeable code segment, which could pose
problems
• PIE : posi+on independent executable
– a.k.a PIC (posi6on independent code)
– code that executes properly irrespec6ve of its absolute address
– Used extensively in shared libraries
• Easy to find a loca6on where to load them without overlapping with
other modules

72
 Load Time Relocatable
1

73
Load Time Relocatable

note the 0x0 here…

the actual address of mylib_int is not filled in

74
Load Time Relocatable

Relocatable table present in the executable

that contains all references of mylib_int

75
Load Time Relocatable

The loader fills in the actual address of mylib_int

at run 6me.

76
 Load Time Relocatable
Limita+ons
• Slow load 6me since executable code needs to be modified

• Requires a writeable code segment, which could pose problems.

• Since executable code of each program needs to be customized, it

would prevent sharing of code sec6ons

77
 PIC Internals
• An addi6onal level of indirec6on for all global data and
func6on references
• Uses a lot of rela6ve addressing schemes and a global offset
table (GOT)
• For rela6ve addressing,
– data loads and stores should not be at absolute addresses but must be
rela6ve

Details about PIC and GOT taken from …

h;p://eli.thegreenplace.net/2011/11/03/posi6on-independent-code-pic-in-shared-libraries/ 78
 Global Offset Table (GOT)
• Table at a fixed (known) loca6on in memory
space and known to the linker
• Has the loca6on of the absolute address of
variables and func6ons
Without GOT

With GOT

79
Enforcing Rela6ve Addressing
(example)
With load +me relocatable

With PIC

80
 Enforcing Rela6ve Addressing
(example)
With load +me relocatable

With PIC
Get address of next instruc6on

Index into GOT and get the

actual address of mylib_int into
eax

Now work with the actual

address.

81
 Advantage of the GOT
• With relocatable code, every variable reference would need to be
changed
– Requires writeable code segments
– Huge overheads during load 6me
– Code pages cannot be shared
• With GOT, the GOT table needs to be constructed just once during the
execu6on
– GOT is in the data segment, which is writeable
– Data pages are not shared anyway
– Drawback : run6me overheads due to mul6ple loads

82
 An Example of working with GOT

$gcc –m32 –shared –fpic –S got.c

Besides a.out, this compila6on also generates got.s

The assembly code for the program

83
Data sec6on

Text sec6on

The macro for the GOT is known by the linker.

%ecx will now contain the offset to GOT

Load the absolute address of myglob from the

GOT into %eax

Fills %ecx with the eip of the next

instruc6on.
Why do we need this indirect way of doing this?
In this case what will %ecx contain?
84
More

85
 Deep Within the Kernel
loading the executable
(randomizing the data sec6on)

Check if randomize_va_space
is > 1 (it can be 1 or 2)

Compute the end of the data

segment (m->brk + 0x20

Finally Randomize

86
 Func6on Calls in PIC
• Theore6cally could be done similar with the data…
– call instruc6on gets loca6on from GOT entry that is filled in during
load 6me (this process is called binding)
– In prac6ce, this is 6me consuming. Much more func6ons than global
variables. Most func6ons in libraries are unused
• Lazy binding scheme
– Delay binding 6ll invoca6on of the func6on
– Uses a double indirec6on – PLT – procedure linkage table in addi6on
to GOT

87
The PLT
• Instead of directly calling func, invoke an offset in the
PLT instead.
• PLT is part of the executable text sec6on, and
consists of one entry for each external func6on the
shared library calls.
1 • Each PLT entry has
a jump loca6on to a specific GOT entry
Prepara6on of arguments for a ‘resolver’
Call to resolver func6on

88
 First Invoca6on of Func
First Invoca6on of fun (steps 2 and 3)
On first invoca6on of func, PLT[n]
jumps to GOT[n], which simply jumps
back to PLT[n]
1

89
 First Invoca6on of Func
(step 4). Invoke resolver, which resolves
the actual of func,
places this actual address into GOT
and then invokes func

The arguments passed to resolver, that

1 helps to do symbol resolu6on

Note that the contents of GOT is now

changed to point to the actual address
of func

4 3

90
Subsequent invoca6ons of Func

3
2

91
 Advantages
• Func6ons are relocatable, therefore good for ASLR
• Func6ons resolved only on need, therefore saves
6me during the load phase

92
 Bypassing ASLR
• Brute force
• Return-to-PLT
• Overwri6ng the GOT
• Timing A;acks

93
Safer Programming Languages,
and Compiler Techniques

94
 Other Precautions for buffer overflows
• Enforce memory safety in programming language
– Example java, C# (slow and not feasible for system programming)
• Cannot replace C and C++.
(Too much software already developed in C / C++)

– Newer languages like Rust seem promising

• Use securer libraries. For example C11 annex K, gets_s, strcpy_s,

strncpy_s, etc.
(_s is for secure)

95
 Compile Bounds Checking
• Check accesses to each buffer so that it cannot be beyond the
bounds
• In C and C++, bound checking performed at pointer calculation time
or dereference time.
• Requires run-time bound information for each allocated block.
• Two methodologies
– Object based techniques
– Pointer based techniques

So@bound : Highly Compa6ble and Complete Spa6al Memory Safety for C

Santosh Nagaraka;e, Jianzhou Zhao, Milo M. K. Mar6n, and Steve Zdancewic 96
 So@bound
• Every pointer in the program is associated with a base and bound
• Before every pointer dereference to verify to verify if the dereference is
legally permi;ed

These checks are automa6cally inserted at compile 6me for all pointer
variables. For non-pointers, this check is not required.

97
 So@bound – more details
• pointer arithme+c and assignment
The new pointer inherits the base and bound of the original
pointer

No specific checks are required, un6l dereferencing is done

98
 Storing Metadata
• Table maintained for metadata

99
 So@bound – more details
• Pointers passed to func6ons
– If pointers are passed by the stack
no issues. The compiler can put informa6on related to metadata onto
the stack
– If pointers passed by registers.
Compiler modifies every func6on declara6on to
add more arguments related to metadata
For each func6on parameter that is a pointer, the corresponding base
and bound values are also sent to the func6on

100