Buffer. This time. Security. overflows. Software. By investigating. We will begin. our 1st section: History. Memory layouts
|
|
- Alexandra Thornton
- 6 years ago
- Views:
Transcription
1 This time We will begin our 1st section: Software Security By investigating Buffer overflows and other memory safety vulnerabilities History Memory layouts Buffer overflow fundamentals
2 Software security Security is a form of dependability Does the code do what it should To this end, we follow the software lifecycle Distinguishing factor: an active, malicious attacker Attack model The developer is trusted But the attacker can provide any inputs - Malformed strings - Malformed packets - etc. What harm could an attacker possibly cause?
3 screensaver --prompt= Don t unlock plz Don't unlock plz Locked by dml press ctrl-c to logout
4 screensaver --prompt= Don t unlock pretty plz Don't unlock pretty plz Locked by dml press ctrl-c to logout
5 screensaver --prompt= Don t unlock plz \ Don't unlock plz Locked by dml press ctrl-c to logout
6 screensaver prompt= Under maintenance;\ Do not interrupt \ Under maintenance; Do not interrupt Locked by dml press ctrl-c to logout
7 We re going to focus on C C is still very popular
8 We re going to focus on C Many mission critical systems are written in C Most kernels & OS utilities fingerd X windows server Many high-performance servers Microsoft IIS Microsoft SQL server Many embedded systems Mars rover But the techniques apply more broadly Wiibrew: Twilight Hack exploits buffer overflow when saving the name of Link s horse, Epona
9 We re going to focus on C The harm can be substantial Morris worm Propagated across machines (too aggressively, thanks to a bug) One way it propagated was a buffer overflow attack against a vulnerable version of fingerd on VAXes Sent a special string to the finger daemon, which caused it to execute code that created a new worm copy Didn t check OS: caused Suns running BSD to crash End result: $10-100M in damages, probation, community service
10 We re going to focus on C The harm can be substantial Morris worm Propagated across machines (too aggressively, thanks to a bug) One way it propagated was a buffer overflow attack against a vulnerable version of fingerd on VAXes Sent a special string to the finger daemon, which caused it to execute code that created a new worm copy Didn t check OS: caused Suns running BSD to crash End result: $10-100M in damages, probation, community service Robert Morris is now a professor at MIT
11 We re going to focus on C The harm can be substantial CodeRed Exploited an overflow in the MS-IIS server 300,000 machines infected in 14 hours
12 We re going to focus on C The harm can be substantial CodeRed Exploited an overflow in the MS-IIS server 300,000 machines infected in 14 hours
13 We re going to focus on C The harm can be substantial SQL Slammer Exploited an overflow in the MS-SQL server 75,000 machines infected in 10 minutes
14
15
16 GHOST: glibc vulnerability introduced in 2000, only just announced two days ago
17 Buffer overflows are prevalent 24 Percent of all vulnerabilities
18 Buffer overflows are prevalent 900 Total number of buffer overflow vulnerabilities
19 This class
20 This class E-voting
21 Later This class Later E-voting Later
22 Our goals Understand how these attacks work, and how to defend against them These require knowledge about: The compiler The OS The architecture Analyzing security requires a whole-systems view
23 Memory layout
24 Refresher How is program data laid out in memory? What does the stack look like? What effect does calling (and returning from) a function have on memory? We are focusing on the Linux process model Similar to other operating systems
25 All programs are stored in memory 4G 0
26 All programs are stored in memory 4G 0xffffffff 0 0x
27 All programs are stored in memory 4G 0xffffffff The process s view of memory is that it owns all of it 0 0x
28 All programs are stored in memory 4G 0xffffffff The process s view of memory is that it owns all of it In reality, these are virtual addresses; the OS/CPU map them to physical addresses 0 0x
29 The instructions themselves are in memory 4G 0xffffffff Text 0 0x
30 The instructions themselves are in memory 4G 0xffffffff Text 0x4c2 sub $0x224,%esp 0x4c1 push %ecx 0x4bf mov %esp, 0x4be push 0 0x
31 Data s location depends on how it s created 4G 0xffffffff Text 0 0x
32 Data s location depends on how it s created 4G 0xffffffff Init d data static const int y=10; Text 0 0x
33 Data s location depends on how it s created 4G 0xffffffff Uninit d data static int x; Init d data static const int y=10; Text 0 0x
34 Data s location depends on how it s created 4G 0xffffffff Known at compile time 0 Uninit d data static int x; Init d data Text static const int y=10; 0x
35 Data s location depends on how it s created 4G cmdline & env 0xffffffff Known at compile time Uninit d data static int x; Init d data Text static const int y=10; 0 0x
36 Data s location depends on how it s created Set when process starts 4G cmdline & env 0xffffffff Known at compile time Uninit d data static int x; Init d data Text static const int y=10; 0 0x
37 Data s location depends on how it s created Set when process starts 4G cmdline & env Stack 0xffffffff int f() { int x; Known at compile time Uninit d data static int x; Init d data Text static const int y=10; 0 0x
38 Data s location depends on how it s created Set when process starts 4G cmdline & env Stack 0xffffffff int f() { int x; Heap malloc(sizeof(long)); Known at compile time Uninit d data static int x; Init d data Text static const int y=10; 0 0x
39 Data s location depends on how it s created 4G Set when process starts Runtime cmdline & env Stack Heap 0xffffffff int f() { int x; malloc(sizeof(long)); Known at compile time Uninit d data static int x; Init d data Text static const int y=10; 0 0x
40 We are going to focus on runtime attacks Stack and heap grow in opposite directions 0x xffffffff Heap Stack
41 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack
42 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer
43 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer push 1 push 2 push 3
44 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer push 1 push 2 push 3
45 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer push 1 push 2 push 3
46 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap 1 Stack Stack pointer push 1 push 2 push 3
47 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap 1 Stack Stack pointer push 1 push 2 push 3
48 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap 2 1 Stack Stack pointer push 1 push 2 push 3
49 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap 2 1 Stack Stack pointer push 1 push 2 push 3
50 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer push 1 push 2 push 3
51 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer push 1 push 2 push 3 return
52 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack Stack pointer push 1 push 2 push 3 return
53 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack { apportioned by the OS; managed in-process by malloc Stack pointer push 1 push 2 push 3 return
54 We are going to focus on runtime attacks Stack and heap grow in opposite directions Compiler provides instructions that adjusts the size of the stack at runtime 0x xffffffff Heap Stack { apportioned by the OS; managed in-process by malloc Stack pointer push 1 push 2 push 3 return Focusing on the stack for now
55 Stack layout when calling functions What do we do when we call a function? What data need to be stored? Where do they go? How do we return from a function? What data need to be restored? Where do they come from? Code examples
56 Stack layout when calling functions void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; } 0x xffffffff caller s data
57 Stack layout when calling functions void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; } 0x xffffffff arg1 arg2 arg3 caller s data Arguments pushed in reverse order of code
58 Stack layout when calling functions void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; } 0x xffffffff loc2 loc1 arg1 arg2 arg3 caller s data Local variables pushed in the same order as they appear in the code Arguments pushed in reverse order of code
59 Stack layout when calling functions void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Local variables pushed in the same order as they appear in the code Arguments pushed in reverse order of code
60 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data
61 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data
62 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data 0xbffff323
63 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data 0xbffff323 Undecidable at compile time
64 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data 0xbffff323 Undecidable at compile time - I don t know where loc2 is,
65 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data 0xbffff323 Undecidable at compile time - I don t know where loc2 is, - and I don t know how many args
66 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data 0xbffff323 Undecidable at compile time - I don t know where loc2 is, - and I don t know how many args - but loc2 is always 8B before??? s
67 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data - I don t know where loc2 is, - and I don t know how many args - but loc2 is always 8B before??? s
68 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Stack frame for this call to func - I don t know where loc2 is, - and I don t know how many args - but loc2 is always 8B before??? s
69 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Frame pointer Stack frame for this call to func - I don t know where loc2 is, - and I don t know how many args - but loc2 is always 8B before??? s
70 Accessing variables void func(char *arg1, int arg2, int arg3) { char loc1[4] int loc2; int loc3; loc2++; Q: Where is (this) loc2? A: -8() } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Frame pointer Stack frame for this call to func - I don t know where loc2 is, - and I don t know how many args - but loc2 is always 8B before??? s
71 Notation A memory address () The value at memory address (like dereferencing a pointer)
72 Notation A memory address () The value at memory address (like dereferencing a pointer) x xffffffff
73 Notation 0xbfff03b8 A memory address () The value at memory address (like dereferencing a pointer) x xffffffff
74 Notation 0xbfff03b8 A memory address () The value at memory address (like dereferencing a pointer) 0xbfff03b8 x xffffffff
75 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) x xbfff03b8 0xbfff0720 0xffffffff
76 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl x xbfff03b8 0xbfff0720 0xffffffff
77 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl %esp 0xbfff03b8 x xbfff0720 0xffffffff
78 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl %esp 0xbfff03b8 x xbfff0720 0xffffffff
79 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl %esp 0xbfff03b8 x xbfff0720 0xffffffff
80 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl x %esp 0xbfff03b8 0xbfff03b8 0xbfff0720 0xffffffff
81 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl movl %esp /* = %esp */ x %esp 0xbfff03b8 0xbfff03b8 0xbfff0720 0xffffffff
82 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl movl %esp /* = %esp */ x %esp 0xbfff03b8 0xbfff03b8 0xbfff0720 0xffffffff
83 Notation 0xbfff03b8 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl movl %esp /* = %esp */ 0xbfff0200 %esp 0xbfff03b8 x xbfff03b8 0xbfff0720 0xffffffff
84 Notation 0xbfff03b8 0xbfff0200 A memory address 0xbfff0720 () The value at memory address (like dereferencing a pointer) pushl movl %esp /* = %esp */ 0xbfff0200 x %esp 0xbfff03b8 0xbfff03b8 0xbfff0720 0xffffffff
85 Notation 0xbfff03b8 0xbfff0200 A memory address 0xbfff0720 0xbfff03b8 () The value at memory address (like dereferencing a pointer) pushl movl %esp /* = %esp */ 0xbfff0200 x %esp 0xbfff03b8 0xbfff03b8 0xbfff0720 0xffffffff
86 Returning from functions int main() { func( Hey, 10, -3); } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Stack frame for this call to func
87 Returning from functions int main() { func( Hey, 10, -3); } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Stack frame for this call to func
88 Returning from functions int main() { func( Hey, 10, -3); } 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Stack frame for this call to func
89 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we restore? 0x xffffffff loc2 loc1?????? arg1 arg2 arg3 caller s data Stack frame for this call to func
90 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we restore? 0x xffffffff??? arg1 arg2 arg3 caller s data Stack frame for this call to func
91 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we restore? 0x %esp 0xffffffff??? arg1 arg2 arg3 caller s data Stack frame for this call to func
92 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we restore? 0x %esp 0xffffffff??? arg1 arg2 arg3 caller s data 1. Push before locals Stack frame for this call to func
93 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we restore? 0x %esp 0xffffffff??? arg1 arg2 arg3 caller s data 1. Push before locals 2. Set to current %esp Stack frame for this call to func
94 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we restore? 0x %esp 0xffffffff??? arg1 arg2 arg3 caller s data 1. Push before locals 2. Set to current %esp Stack frame for this call to func 3. Set to() at return
95 Returning from functions int main() { func( Hey, 10, -3); } 0x xffffffff loc2 loc1??? arg1 arg2 arg3 caller s data Stack frame for this call to func
96 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we resume here? 0x xffffffff loc2 loc1??? arg1 arg2 arg3 caller s data Stack frame for this call to func
97 The instructions themselves are in memory 4G 0xffffffff Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) 0 0x
98 The instructions themselves are in memory 4G 0xffffffff Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) %eip 0 0x
99 The instructions themselves are in memory 4G 0xffffffff Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) %eip 0 0x
100 The instructions themselves are in memory 4G 0xffffffff Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) %eip 0 0x
101 The instructions themselves are in memory 4G 0xffffffff 0x5bf mov %esp, 0x5be push Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) %eip 0 0x
102 The instructions themselves are in memory 4G 0xffffffff 0x5bf mov %esp, 0x5be push %eip Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) 0 0x
103 The instructions themselves are in memory 4G 0xffffffff 0x5bf mov %esp, 0x5be push %eip Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) 0 0x
104 The instructions themselves are in memory 4G 0xffffffff 0x5bf mov %esp, 0x5be push Text 0x4a7 mov $0x0,%eax 0x4a2 call <func> 0x49b movl $0x804..,(%esp) 0x493 movl $0xa,0x4(%esp) %eip 0 0x
105 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we resume here? 0x xffffffff loc2 loc1??? arg1 arg2 arg3 caller s data Stack frame for this call to func
106 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we resume here? 0x xffffffff loc2 loc1??? arg1 arg2 arg3 caller s data Stack frame for this call to func Push next %eip before call
107 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we resume here? 0x xffffffff loc2 loc1 %eip??? arg1 arg2 arg3 caller s data Stack frame for this call to func Push next %eip before call
108 Returning from functions int main() { func( Hey, 10, -3); } Q: How do we resume here? 0x xffffffff loc2 loc1 %eip??? arg1 arg2 arg3 caller s data Stack frame for this call to func Set %eip to 4() at return Push next %eip before call
109 Stack and functions: Summary
110 Stack and functions: Summary Calling function: 1.Push arguments onto the stack (in reverse) 2.Push the return address, i.e., the address of the instruction you want run after control returns to you: %eip+something 3.Jump to the function s address
111 Stack and functions: Summary Calling function: 1.Push arguments onto the stack (in reverse) 2.Push the return address, i.e., the address of the instruction you want run after control returns to you: %eip+something 3.Jump to the function s address Called function: 4.Push the old frame pointer onto the stack: 5.Set frame pointer to where the end of the stack is right now: %esp 6.Push local variables onto the stack; access them as offsets from
112 Stack and functions: Summary Calling function: 1.Push arguments onto the stack (in reverse) 2.Push the return address, i.e., the address of the instruction you want run after control returns to you: %eip+something 3.Jump to the function s address Called function: 4.Push the old frame pointer onto the stack: 5.Set frame pointer to where the end of the stack is right now: %esp 6.Push local variables onto the stack; access them as offsets from Returning function: 7.Reset the previous stack frame: = () 8.Jump back to return address: %eip = 4()
113 Buffer overflows
114 Buffer overflows from 10,000 ft Buffer = Contiguous set of a given data type Common in C - All strings are buffers of char s Overflow = Put more into the buffer than it can hold Where does the extra data go? Well now that you re experts in memory layouts
115 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); }
116 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); }
117 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } &arg1
118 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1
119 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1
120 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1 buffer
121 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } A u t h %eip &arg1 buffer
122 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } M e! \0 00 A 00 u 00 t 00 h 4d %eip &arg1 buffer
123 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } Upon return, sets to 0x d M e! \0 00 A 00 u 00 t 00 h 4d %eip &arg1 buffer
124 A buffer overflow example void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } int main() { char *mystr = AuthMe! ; func(mystr); } Upon return, sets to 0x d M e! \0 00 A 00 u 00 t 00 h 4d %eip &arg1 buffer SEGFAULT (0x )
125 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); }
126 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); }
127 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } &arg1
128 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1
129 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1
130 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1 authenticated
131 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } %eip &arg1 buffer authenticated
132 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } 00 A 00 u 00 t 00 h %eip &arg1 buffer authenticated
133 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } M e! \0 00 A 00 u 00 t 00 h 4d %eip &arg1 buffer authenticated
134 A buffer overflow example void func(char *arg1) { int authenticated = 0; char buffer[4]; strcpy(buffer, arg1); if(authenticated) { } int main() { char *mystr = AuthMe! ; func(mystr); } Code still runs; user now authenticated M e! \0 00 A 00 u 00 t 00 h 4d %eip &arg1 buffer authenticated
135 void vulnerable() { char buf[80]; gets(buf); }
136 void vulnerable() { char buf[80]; gets(buf); } void still_vulnerable() { char *buf = malloc(80); gets(buf); }
137 void safe() { char buf[80]; fgets(buf, 64, stdin); }
138 void safe() { char buf[80]; fgets(buf, 64, stdin); } void safer() { char buf[80]; fgets(buf, sizeof(buf), stdin); }
139
140 User-supplied strings In these examples, we were providing our own strings But they come from users in myriad aways Text input Packets Environment variables File input
141 What s the worst that could happen? void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } %eip &mystr buffer
142 What s the worst that could happen? void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } %eip &mystr buffer strcpy will let you write as much as you want (til a \0 )
143 What s the worst that could happen? void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } All ours! %eip &mystr buffer strcpy will let you write as much as you want (til a \0 )
144 What s the worst that could happen? void func(char *arg1) { char buffer[4]; strcpy(buffer, arg1); } All ours! %eip &mystr buffer strcpy will let you write as much as you want (til a \0 ) What could you write to memory to wreak havoc?
145 Code injection
146 High-level idea void func(char *arg1) { char buffer[4]; sprintf(buffer, arg1); } %eip &arg buffer
147 High-level idea void func(char *arg1) { char buffer[4]; sprintf(buffer, arg1); } %eip &arg Haxx0r c0d3 buffer (1) Load my own code into memory
148 High-level idea void func(char *arg1) { char buffer[4]; sprintf(buffer, arg1); } %eip Text %eip &arg buffer Haxx0r c0d3 (1) Load my own code into memory (2) Somehow get %eip to point to it
149 High-level idea void func(char *arg1) { char buffer[4]; sprintf(buffer, arg1); } %eip Text %eip &arg buffer Haxx0r c0d3 (1) Load my own code into memory (2) Somehow get %eip to point to it
150 High-level idea void func(char *arg1) { char buffer[4]; sprintf(buffer, arg1); } %eip Text %eip &arg buffer Haxx0r c0d3 (1) Load my own code into memory (2) Somehow get %eip to point to it
151 This is nontrivial Pulling off this attack requires getting a few things really right (and some things sorta right) Think about what is tricky about the attack The key to defending it will be to make the hard parts really hard
152 Challenge 1 Loading code into memory It must be the machine code instructions (i.e., already compiled and ready to run) We have to be careful in how we construct it: It can t contain any all-zero bytes - Otherwise, sprintf / gets / scanf / will stop copying - How could you write assembly to never contain a full zero byte? It can t make use of the loader (we re injecting) It can t use the stack (we re going to smash it)
153 What kind of code would we want to run? Goal: full-purpose shell The code to launch a shell is called shell code It is nontrivial to it in a way that works as injected code - No zeroes, can t use the stack, no loader dependence There are many out there - And competitions to see who can write the smallest Goal: privilege escalation Ideally, they go from guest (or non-user) to root
154 Shellcode #include <stdio.h> int main( ) { char *name[2]; name[0] = /bin/sh ; name[1] = NULL; execve(name[0], name, NULL); }
155 Shellcode #include <stdio.h> int main( ) { char *name[2]; name[0] = /bin/sh ; name[1] = NULL; execve(name[0], name, NULL); } Assembly xorl %eax, %eax pushl %eax pushl $0x68732f2f pushl $0x6e69622f movl %esp,%ebx pushl %eax
156 Shellcode #include <stdio.h> int main( ) { char *name[2]; name[0] = /bin/sh ; name[1] = NULL; execve(name[0], name, NULL); } Assembly xorl %eax, %eax pushl %eax pushl $0x68732f2f pushl $0x6e69622f movl %esp,%ebx pushl %eax
157 Shellcode #include <stdio.h> int main( ) { char *name[2]; name[0] = /bin/sh ; name[1] = NULL; execve(name[0], name, NULL); } Assembly xorl %eax, %eax pushl %eax pushl $0x68732f2f pushl $0x6e69622f movl %esp,%ebx pushl %eax \x31\xc0 \x50 \x68 //sh \x68 /bin \x89\xe3 \x50 Machine code
158 Shellcode #include <stdio.h> int main( ) { char *name[2]; name[0] = /bin/sh ; name[1] = NULL; execve(name[0], name, NULL); } Assembly xorl %eax, %eax pushl %eax pushl $0x68732f2f pushl $0x6e69622f movl %esp,%ebx pushl %eax \x31\xc0 \x50 \x68 //sh \x68 /bin \x89\xe3 \x50 Machine code (Part of) your input
159 Privilege escalation Permissions later, but for now Recall that each file has: Permissions: read / write / execute For each of: owner / group / everyone else Consider a service like passwd Owned by root (and needs to do root-y things) But you want any user to be able to run it
160 Effective userid Userid = the user who ran the process Effective userid = what is used to determine what access the process has Consider passwd: getuid() will return you (real userid) seteuid(0) to set the effective userid to root - It s allowed to because root is the owner What is the potential attack?
161 Effective userid Userid = the user who ran the process Effective userid = what is used to determine what access the process has Consider passwd: getuid() will return you (real userid) seteuid(0) to set the effective userid to root - It s allowed to because root is the owner What is the potential attack? If you can get a root-owned process to run setuid(0)/seteuid(0), then you get root permissions
162 Challenge 2 Getting our injected code to run We can t insert a jump into my code instruction We have to use whatever code is already running %eip &arg \x0f \x3c \x2f buffer Thoughts?
163 Challenge 2 Getting our injected code to run We can t insert a jump into my code instruction We have to use whatever code is already running %eip Text %eip &arg \x0f \x3c \x2f buffer Thoughts?
164 Challenge 2 Getting our injected code to run We can t insert a jump into my code instruction We have to use whatever code is already running %eip Text %eip &arg \x0f \x3c \x2f buffer Thoughts?
165 Challenge 2 Getting our injected code to run We can t insert a jump into my code instruction We have to use whatever code is already running %eip Text %eip &arg \x0f \x3c \x2f buffer Thoughts?
166 Stack and functions: Summary Calling function: 1.Push arguments onto the stack (in reverse) 2.Push the return address, i.e., the address of the instruction you want run after control returns to you: %eip+something 3.Jump to the function s address Called function: 4.Push the old frame pointer onto the stack: 5.Set frame pointer to where the end of the stack is right now: %esp 6.Push local variables onto the stack; access them as offsets from Returning function: 7.Reset the previous stack frame: = () 8.Jump back to return address: %eip = 4()
167 Hijacking the saved %eip %eip Text %eip &arg1 \x0f \x3c \x2f buffer 0xbff
168 Hijacking the saved %eip %eip Text %eip 0xbff &arg1 \x0f \x3c \x2f buffer 0xbff
169 Hijacking the saved %eip %eip Text %eip 0xbff &arg1 \x0f \x3c \x2f buffer 0xbff
170 Hijacking the saved %eip %eip Text %eip 0xbff &arg1 \x0f \x3c \x2f buffer 0xbff But how do we know the address?
171 Hijacking the saved %eip What if we are wrong? %eip Text %eip 0xbff &arg1 \x0f \x3c \x2f buffer 0xbff
172 Hijacking the saved %eip What if we are wrong? %eip Text %eip 0xbff &arg1 0xbdf \x0f \x3c \x2f buffer 0xbff
173 Hijacking the saved %eip What if we are wrong? %eip Text %eip 0xbff &arg1 0xbdf \x0f \x3c \x2f buffer 0xbff
174 Hijacking the saved %eip What if we are wrong? %eip Text %eip 0xbff 0xbdf &arg1 \x0f \x3c \x2f buffer 0xbff This is most likely data, so the CPU will panic (Invalid Instruction)
175 Challenge 3 Finding the return address
176 Challenge 3 Finding the return address If we don t have access to the code, we don t know how far the buffer is from the saved
177 Challenge 3 Finding the return address If we don t have access to the code, we don t know how far the buffer is from the saved One approach: just try a lot of different values!
178 Challenge 3 Finding the return address If we don t have access to the code, we don t know how far the buffer is from the saved One approach: just try a lot of different values! Worst case scenario: it s a 32 (or 64) bit memory space, which means 2 32 (2 64 ) possible answers
179 Challenge 3 Finding the return address If we don t have access to the code, we don t know how far the buffer is from the saved One approach: just try a lot of different values! Worst case scenario: it s a 32 (or 64) bit memory space, which means 2 32 (2 64 ) possible answers But without address randomization: The stack always starts from the same, fixed address The stack will grow, but usually it doesn t grow very deeply (unless the code is heavily recursive)
180 gdb tutorial
181 Improving our chances: nop sleds nop is a single-byte instruction (just moves to the next instruction) %eip Text %eip 0xbff 0xbdf &arg1 \x0f \x3c \x2f buffer 0xbff
182 Improving our chances: nop sleds nop is a single-byte instruction (just moves to the next instruction) %eip Text %eip 0xbff 0xbdf &arg1 nop nop nop \x0f \x3c \x2f buffer 0xbff
183 Improving our chances: nop sleds nop is a single-byte instruction (just moves to the next instruction) %eip Jumping anywhere here will work Text %eip 0xbff 0xbdf &arg1 nop nop nop \x0f \x3c \x2f buffer 0xbff
184 Improving our chances: nop sleds nop is a single-byte instruction (just moves to the next instruction) %eip Jumping anywhere here will work Text %eip 0xbdf xbff &arg1 nop nop nop \x0f \x3c \x2f buffer
185 Improving our chances: nop sleds nop is a single-byte instruction (just moves to the next instruction) %eip Jumping anywhere here will work Text %eip 0xbdf xbff &arg1 nop nop nop \x0f \x3c \x2f buffer Now we improve our chances of guessing by a factor of #nops
186 Putting it all together %eip padding good guess Text %eip 0xbdf &arg xbff nop nop nop buffer nop sled \x0f \x3c \x2f malicious code
187 Putting it all together But it has to be something; we have to start writing wherever the input to gets/etc. begins. %eip padding good guess Text %eip 0xbdf &arg xbff nop nop nop buffer nop sled \x0f \x3c \x2f malicious code
188 Putting it all together But it has to be something; we have to start writing wherever the input to gets/etc. begins. padding good guess %eip Text %eip 0xbdf &arg xbff nop nop nop buffer nop sled \x0f \x3c \x2f malicious code
189 Putting it all together But it has to be something; we have to start writing wherever the input to gets/etc. begins. padding good guess %eip Text %eip 0xbdf &arg xbff nop nop nop buffer nop sled \x0f \x3c \x2f malicious code
190 Next time Continuing with Software Security More attacks, and Defenses Required reading: StackGuard: Simple Stack Smash Protection for GCC
BUFFER OVERFLOW DEFENSES & COUNTERMEASURES
BUFFER OVERFLOW DEFENSES & COUNTERMEASURES CMSC 414 FEB 01 2018 RECALL OUR CHALLENGES How can we make these even more difficult? Putting code into the memory (no zeroes) Finding the return address (guess
More informationThis time. Defenses and other memory safety vulnerabilities. Everything you ve always wanted to know about gdb but were too afraid to ask
This time We will continue Buffer overflows By looking at Overflow Defenses and other memory safety vulnerabilities Everything you ve always wanted to know about gdb but were too afraid to ask Overflow
More informationBUFFER OVERFLOW. Jo, Heeseung
BUFFER OVERFLOW Jo, Heeseung IA-32/LINUX MEMORY LAYOUT Heap Runtime stack (8MB limit) Dynamically allocated storage When call malloc(), calloc(), new() DLLs (shared libraries) Data Text Dynamically linked
More informationBuffer Overflow. Jo, Heeseung
Buffer Overflow Jo, Heeseung IA-32/Linux Memory Layout Heap Runtime stack (8MB limit) Dynamically allocated storage When call malloc(), calloc(), new() DLLs (shared libraries) Data Text Dynamically linked
More informationBuffer Overflow Vulnerability
Buffer Overflow Vulnerability 1 Buffer Overflow Vulnerability Copyright c 2006 2014 Wenliang Du, Syracuse University. The development of this document is/was funded by three grants from the US National
More information20: Exploits and Containment
20: Exploits and Containment Mark Handley Andrea Bittau What is an exploit? Programs contain bugs. These bugs could have security implications (vulnerabilities) An exploit is a tool which exploits a vulnerability
More informationBuffer Overflow. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University
Buffer Overflow Jin-Soo Kim (jinsookim@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu IA-32/Linux Memory Layout Runtime stack (8MB limit) Heap Dynamically allocated storage
More informationCS 645: Lecture 3 Software Vulnerabilities. Rachel Greenstadt July 3, 2013
CS 645: Lecture 3 Software Vulnerabilities Rachel Greenstadt July 3, 2013 Project 1: Software exploits Individual project - done in virtual machine environment This assignment is hard. Don t leave it until
More informationLinux Memory Layout. Lecture 6B Machine-Level Programming V: Miscellaneous Topics. Linux Memory Allocation. Text & Stack Example. Topics.
Lecture 6B Machine-Level Programming V: Miscellaneous Topics Topics Linux Memory Layout Understanding Pointers Buffer Overflow Upper 2 hex digits of address Red Hat v. 6.2 ~1920MB memory limit FF C0 Used
More informationBuffer Overflow Attack
Chapter 4 This is a sample chapter in the book titled "Computer Security: A Hands-on Approach" authored by Wenliang Du. Buffer Overflow Attack From Morris worm in 1988, Code Red worm in 2001, SQL Slammer
More informationCMPSC 497 Buffer Overflow Vulnerabilities
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA CMPSC 497 Buffer Overflow
More informationBetriebssysteme und Sicherheit Sicherheit. Buffer Overflows
Betriebssysteme und Sicherheit Sicherheit Buffer Overflows Software Vulnerabilities Implementation error Input validation Attacker-supplied input can lead to Corruption Code execution... Even remote exploitation
More informationBuffer Overflow Vulnerability Lab Due: September 06, 2018, Thursday (Noon) Submit your lab report through to
CPSC 8810 Fall 2018 Lab 1 1 Buffer Overflow Vulnerability Lab Due: September 06, 2018, Thursday (Noon) Submit your lab report through email to lcheng2@clemson.edu Copyright c 2006-2014 Wenliang Du, Syracuse
More informationIntroduction to Computer Systems , fall th Lecture, Sep. 28 th
Introduction to Computer Systems 15 213, fall 2009 9 th Lecture, Sep. 28 th Instructors: Majd Sakr and Khaled Harras Last Time: Structures struct rec { int i; int a[3]; int *p; }; Memory Layout i a p 0
More informationBuffer Overflow & Format Strings
& Seminar on Computer Security Threats and Counter Measures Dominik Zindel 19.01.2007 Content 1 Technical Basics 2 3 4 Discussion References Goals Technical Basics Common goal of attacks using a buffer
More information1 Recommended Readings
CSC 482/582 Assignment #5 Buffer Overflow Due: November 14, 2013 The learning objective of this assignment is for students to gain first-hand experience with a buffer overflow vulnerability, applying what
More informationIs stack overflow still a problem?
Morris Worm (1998) Code Red (2001) Secure Programming Lecture 4: Memory Corruption II (Stack Overflows) David Aspinall, Informatics @ Edinburgh 31st January 2017 Memory corruption Buffer overflow remains
More informationBuffer Overflow. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University
Buffer Overflow Jin-Soo Kim (jinsookim@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu x86-64/linux Memory Layout Stack Runtime stack (8MB limit) Heap Dynamically allocated
More informationBuffer Overflow. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University
Buffer Overflow Jinkyu Jeong (jinkyu@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu SSE2030: Introduction to Computer Systems, Spring 2018, Jinkyu Jeong (jinkyu@skku.edu)
More informationBuffer overflow is still one of the most common vulnerabilities being discovered and exploited in commodity software.
Outline Morris Worm (1998) Infamous attacks Secure Programming Lecture 4: Memory Corruption II (Stack Overflows) David Aspinall, Informatics @ Edinburgh 23rd January 2014 Recap Simple overflow exploit
More information1 Lab Overview. 2 Resources Required. CSC 666 Lab #11 Buffer Overflow November 29, 2012
CSC 666 Lab #11 Buffer Overflow November 29, 2012 Copyright c 2012 James Walden, Northern Kentucky University. Original document version c 2006-2012 Wenliang Du, Syracuse University. The development of
More informationCIS 551 / TCOM 401 Computer and Network Security. Spring 2007 Lecture 2
CIS 551 / TCOM 401 Computer and Network Security Spring 2007 Lecture 2 Announcements First project is on the web Due: Feb. 1st at midnight Form groups of 2 or 3 people If you need help finding a group,
More informationISA564 SECURITY LAB. Shellcode. George Mason University
ISA564 SECURITY LAB Shellcode George Mason University Outline Shellcode Basics Advanced Shellcode What is shellcode? Machine code used as the payload in the exploitation of a software bug Whenever altering
More informationSungkyunkwan University
November, 1988 Internet Worm attacks thousands of Internet hosts. How did it happen? November, 1988 Internet Worm attacks thousands of Internet hosts. How did it happen? July, 1999 Microsoft launches MSN
More informationBuffer Overflow Vulnerability Lab
SEED Labs Buffer Overflow Vulnerability Lab 1 Buffer Overflow Vulnerability Lab Copyright c 2006-2013 Wenliang Du, Syracuse University. The development of this document is/was funded by three grants from
More informationProgram Security and Vulnerabilities Class 2
Program Security and Vulnerabilities Class 2 CEN-5079: 28.August.2017 1 Secure Programs Programs Operating System Device Drivers Network Software (TCP stack, web servers ) Database Management Systems Integrity
More informationLecture 9: Buffer Overflow* CS 392/6813: Computer Security Fall Nitesh Saxena
Lecture 9: Buffer Overflow* CS 392/6813: Computer Security Fall 2007 Nitesh Saxena *Adopted from a previous lecture by Aleph One (Smashing the Stack for Fun and Profit) and Stanislav Nurilov Course Admin
More informationBuffer Overflow Attacks
Buffer Overflow Attacks 1. Smashing the Stack 2. Other Buffer Overflow Attacks 3. Work on Preventing Buffer Overflow Attacks Smashing the Stack An Evil Function void func(char* inp){ } char buffer[16];
More informationCSE 565 Computer Security Fall 2018
CSE 565 Computer Security Fall 2018 Lecture 14: Software Security Department of Computer Science and Engineering University at Buffalo 1 Software Security Exploiting software vulnerabilities is paramount
More information2 Resources Required. 3 Assignment Tasks. 3.1 Initial setup
CSC 482/582 Assignment #3 Buffer Overflow Due: October 15, 2015 The learning objective of this assignment is for students to gain first-hand experience with a buffer overflow vulnerability, applying what
More informationCSE 509: Computer Security
CSE 509: Computer Security Date: 2.16.2009 BUFFER OVERFLOWS: input data Server running a daemon Attacker Code The attacker sends data to the daemon process running at the server side and could thus trigger
More informationCS4264 Programming Assignment 1 Buffer Overflow Vulnerability Due 02/21/2018 at 5:00 PM EST Submit through CANVAS
Laboratory for Computer Security Education 1 CS4264 Programming Assignment 1 Buffer Overflow Vulnerability Due 02/21/2018 at 5:00 PM EST Submit through CANVAS Copyright c Wenliang Du, Syracuse University.
More informationLecture 08 Control-flow Hijacking Defenses
Lecture 08 Control-flow Hijacking Defenses Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Slides adapted from Miller, Bailey, and Brumley Control Flow Hijack: Always control + computation
More informationCPSC 213. Introduction to Computer Systems. Procedures and the Stack. Unit 1e
CPSC 213 Introduction to Computer Systems Unit 1e Procedures and the Stack 1 Readings for Next 3 Lectures Textbook Procedures - 3.7 Out-of-Bounds Memory References and Buffer Overflow - 3.12 2 Local Variables
More information2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks
Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include injection of malicious code Reasons for runtime attacks
More informationBiography. Background
From Over ow to Shell An Introduction to low-level exploitation Carl Svensson @ KTH, January 2019 1 / 28 Biography MSc in Computer Science, KTH Head of Security, KRY/LIVI CTF: HackingForSoju E-mail: calle.svensson@zeta-two.com
More informationAdvanced Buffer Overflow
Pattern Recognition and Applications Lab Advanced Buffer Overflow Ing. Davide Maiorca, Ph.D. davide.maiorca@diee.unica.it Computer Security A.Y. 2016/2017 Department of Electrical and Electronic Engineering
More informationArchitecture-level Security Vulnerabilities
Architecture-level Security Vulnerabilities Björn Döbel Outline How stacks work Smashing the stack for fun and profit Preventing stack smashing attacks Circumventing stack smashing prevention The Battlefield:
More informationBeyond Stack Smashing: Recent Advances in Exploiting. Jonathan Pincus(MSR) and Brandon Baker (MS)
Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns Jonathan Pincus(MSR) and Brandon Baker (MS) Buffer Overflows and How they Occur Buffer is a contiguous segment of memory of a fixed
More informationBuffer overflows (a security interlude) Address space layout the stack discipline + C's lack of bounds-checking HUGE PROBLEM
Buffer overflows (a security interlude) Address space layout the stack discipline + C's lack of bounds-checking HUGE PROBLEM x86-64 Linux Memory Layout 0x00007fffffffffff not drawn to scale Stack... Caller
More informationFrom Over ow to Shell
From Over ow to Shell An Introduction to low-level exploitation Carl Svensson @ Google, December 2018 1 / 25 Biography MSc in Computer Science, KTH Head of Security, KRY/LIVI CTF: HackingForSoju E-mail:
More informationBuffer overflows & friends CS642: Computer Security
Buffer overflows & friends CS642: Computer Security Professor Ristenpart h9p://www.cs.wisc.edu/~rist/ rist at cs dot wisc dot edu University of Wisconsin CS 642 Homework 1 will be up tonight Low- level
More informationFundamentals of Computer Security
Fundamentals of Computer Security Spring 2015 Radu Sion Software Errors Buffer Overflow TOCTTOU 2005-15 Portions copyright by Bogdan Carbunar and Wikipedia. Used with permission Why Security Vulnerabilities?
More informationArchitecture-level Security Vulnerabilities. Julian Stecklina
Architecture-level Security Vulnerabilities Julian Stecklina Outline How stacks work Smashing the stack for fun and profit Preventing stack smashing attacks Circumventing stack smashing prevention The
More informationX86 Review Process Layout, ISA, etc. CS642: Computer Security. Drew Davidson
X86 Review Process Layout, ISA, etc. CS642: Computer Security Drew Davidson davidson@cs.wisc.edu From Last Time ACL-based permissions (UNIX style) Read, Write, execute can be restricted on users and groups
More informationCPSC 213. Introduction to Computer Systems. Procedures and the Stack. Unit 1e
CPSC 213 Introduction to Computer Systems Unit 1e Procedures and the Stack Readings for Next 3 Lectures Textbook Procedures - 3.7 Out-of-Bounds Memory References and Buffer Overflow - 3.12 Local Variables
More informationSandwiches for everyone
Inf2C :: Computer Systems Today s menu ( And finally, monsieur, a wafer-thin mint ) Notes on security Or, why safety is an illusion, why ignorance is bliss, and why knowledge is power Stack overflows Or,
More informationLecture 4 September Required reading materials for this class
EECS 261: Computer Security Fall 2007 Lecture 4 September 6 Lecturer: David Wagner Scribe: DK Moon 4.1 Required reading materials for this class Beyond Stack Smashing: Recent Advances in Exploiting Buffer
More informationBuffer Overflow Attack
Buffer Overflow Attack What every applicant for the hacker should know about the foundation of buffer overflow attacks By (Dalgona@wowhacker.org) Email: zinwon@gmail.com 2005 9 5 Abstract Buffer overflow.
More informationBuffer Overflows. Buffer Overflow. Many of the following slides are based on those from
s Many of the following slides are based on those from 1 Complete Powerpoint Lecture Notes for Computer Systems: A Programmer's Perspective (CS:APP) Randal E. Bryant and David R. O'Hallaron http://csapp.cs.cmu.edu/public/lectures.html
More informationSecure Programming I. Steven M. Bellovin September 28,
Secure Programming I Steven M. Bellovin September 28, 2014 1 If our software is buggy, what does that say about its security? Robert H. Morris Steven M. Bellovin September 28, 2014 2 The Heart of the Problem
More informationCPSC 213. Introduction to Computer Systems. Procedures and the Stack. Unit 1e Feb 11, 13, 15, and 25. Winter Session 2018, Term 2
CPSC 213 Introduction to Computer Systems Winter Session 2018, Term 2 Unit 1e Feb 11, 13, 15, and 25 Procedures and the Stack Overview Reading Companion: 2.8 Textbook: 3.7, 3.12 Learning Goals explain
More informationBuffer overflows & friends CS642: Computer Security
Buffer overflows & friends CS642: Computer Security Professor Ristenpart h9p://www.cs.wisc.edu/~rist/ rist at cs dot wisc dot edu University of Wisconsin CS 642 Announcements Project proposals: Due Oct
More informationbuffer overflow exploitation
buffer overflow exploitation Samuele Andreoli, Nicolò Fornari, Giuseppe Vitto May 11, 2016 University of Trento Introduction 1 introduction A Buffer Overflow is an anomaly where a program, while writing
More informationCMSC 414 Computer and Network Security
CMSC 414 Computer and Network Security Buffer Overflows Dr. Michael Marsh August 30, 2017 Trust and Trustworthiness You read: Reflections on Trusting Trust (Ken Thompson), 1984 Smashing the Stack for Fun
More informationMachine Programming 5: Buffer Overruns and Stack Exploits
Machine Programming 5: Buffer Overruns and Stack Exploits CS61, Lecture 6 Prof. Stephen Chong September 22, 2011 Thinking about grad school in Computer Science? Panel discussion Tuesday September 27th,
More informationSecure Software Development: Theory and Practice
Secure Software Development: Theory and Practice Suman Jana MW 2:40-3:55pm 415 Schapiro [SCEP] *Some slides are borrowed from Dan Boneh and John Mitchell Software Security is a major problem! Why writing
More informationCSc 466/566. Computer Security. 20 : Operating Systems Application Security
1/68 CSc 466/566 Computer Security 20 : Operating Systems Application Security Version: 2014/11/20 13:07:28 Department of Computer Science University of Arizona collberg@gmail.com Copyright c 2014 Christian
More informationBasic Buffer Overflows
Operating Systems Security Basic Buffer Overflows (Stack Smashing) Computer Security & OS lab. Cho, Seong-je ( 조성제 ) Fall, 2018 sjcho at dankook.ac.kr Chapter 10 Buffer Overflow 2 Contents Virtual Memory
More informationSecurity and Privacy in Computer Systems. Lecture 5: Application Program Security
CS 645 Security and Privacy in Computer Systems Lecture 5: Application Program Security Buffer overflow exploits More effective buffer overflow attacks Preventing buffer overflow attacks Announcement Project
More informationlogistics LEX assignment out exam in on week come with questions on Monday (review)
Stack Smashing 1 logistics 2 LEX assignment out exam in on week come with questions on Monday (review) last few times encrypted code changing code polymorphic, metamorphic anti-vm/emulation anti-debugging
More informationBuffer overflows. Specific topics:
Buffer overflows Buffer overflows are possible because C does not check array boundaries Buffer overflows are dangerous because buffers for user input are often stored on the stack Specific topics: Address
More informationLab 2: Buffer Overflows
Department of Computer Science: Cyber Security Practice Lab 2: Buffer Overflows Introduction In this lab, you will learn how buffer overflows and other memory vulnerabilities are used to takeover vulnerable
More informationControl Hijacking Attacks
Control Hijacking Attacks Alexandros Kapravelos kapravelos@ncsu.edu (Derived from slides from Chris Kruegel) Attacker s mindset Take control of the victim s machine Hijack the execution flow of a running
More informationBuffer Overflows Defending against arbitrary code insertion and execution
www.harmonysecurity.com info@harmonysecurity.com Buffer Overflows Defending against arbitrary code insertion and execution By Stephen Fewer Contents 1 Introduction 2 1.1 Where does the problem lie? 2 1.1.1
More informationputting m bytes into a buffer of size n, for m>n corrupts the surrounding memory check size of data before/when writing
Secure Programming Lecture 4: Memory Corruption II (Stack & Heap Overflows) David Aspinall, Informatics @ Edinburgh 25th January 2018 Memory corruption Buffer overflow is a common vulnerability Simple
More informationSecure Programming Lecture 3: Memory Corruption I (Stack Overflows)
Secure Programming Lecture 3: Memory Corruption I (Stack Overflows) David Aspinall, Informatics @ Edinburgh 24th January 2017 Outline Roadmap Memory corruption vulnerabilities Instant Languages and Runtimes
More informationCPSC 213. Introduction to Computer Systems. Procedures and the Stack. Unit 1e
CPSC 213 Introduction to Computer Systems Unit 1e Procedures and the Stack 1 Reading Companion 2.8 Textbook Procedures, Out-of-Bounds Memory References and Buffer Overflows 3.7, 3.12 2 Local Variables
More informationCNIT 127: Exploit Development. Ch 1: Before you begin. Updated
CNIT 127: Exploit Development Ch 1: Before you begin Updated 1-14-16 Basic Concepts Vulnerability A flaw in a system that allows an attacker to do something the designer did not intend, such as Denial
More informationLecture 6: Buffer Overflow. CS 436/636/736 Spring Nitesh Saxena
Lecture 6: Buffer Overflow CS 436/636/736 Spring 2016 Nitesh Saxena *Adopted from a previous lecture by Aleph One (Smashing the Stack for Fun and Profit) HW3 submitted Course Admin Being graded Solution
More informationAdvanced Buffer Overflow
Pattern Recognition and Applications Lab Advanced Buffer Overflow Ing. Davide Maiorca, Ph.D. davide.maiorca@diee.unica.it Computer Security A.Y. 2017/2018 Department of Electrical and Electronic Engineering
More informationBuffer Overflow Vulnerability Lab
SEED Labs Buffer Overflow Vulnerability Lab 1 Buffer Overflow Vulnerability Lab Copyright 2006-2016 Wenliang Du, Syracuse University. The development of this document was partially funded by the National
More informationHands-on Ethical Hacking: Preventing & Writing Buffer Overflow Exploits
Hands-on Ethical Hacking: Preventing & Writing Buffer Overflow Exploits OWASP AppSec 2013 Rochester OWASP Chapter Lead Ralph Durkee - Durkee Consulting, Inc. info@rd1.net Hands-on Ethical Hacking: Preventing
More informationBuffer overflow background
and heap buffer background Comp Sci 3600 Security Heap Outline and heap buffer Heap 1 and heap 2 3 buffer 4 5 Heap Outline and heap buffer Heap 1 and heap 2 3 buffer 4 5 Heap Address Space and heap buffer
More informationSoftware Security II: Memory Errors - Attacks & Defenses
1 Software Security II: Memory Errors - Attacks & Defenses Chengyu Song Slides modified from Dawn Song 2 Administrivia Lab1 Writeup 3 Buffer overflow Out-of-bound memory writes (mostly sequential) Allow
More informationThe first Secure Programming Laboratory will be today! 3pm-6pm in Forrest Hill labs 1.B31, 1.B32.
Lab session this afternoon Memory corruption attacks Secure Programming Lecture 6: Memory Corruption IV (Countermeasures) David Aspinall, Informatics @ Edinburgh 2nd February 2016 The first Secure Programming
More informationTopics. What is a Buffer Overflow? Buffer Overflows
Buffer Overflows CSC 482/582: Computer Security Slide #1 Topics 1. What is a Buffer Overflow? 2. The Most Common Implementation Flaw. 3. Process Memory Layout. 4. The Stack and C s Calling Convention.
More informationEthical Hacking: Preventing & Writing Buffer Overflow Exploits
Ethical Hacking: Preventing & Writing Buffer Overflow Exploits Rochester Security Summit 2014 Rochester OWASP Chapter Lead Ralph Durkee - Durkee Consulting, Inc. info@rd1.net Ralph Durkee Background Founder
More informationSecure Programming Lecture 6: Memory Corruption IV (Countermeasures)
Secure Programming Lecture 6: Memory Corruption IV (Countermeasures) David Aspinall, Informatics @ Edinburgh 2nd February 2016 Outline Announcement Recap Containment and curtailment Tamper detection Memory
More informationISA564 SECURITY LAB. Code Injection Attacks
ISA564 SECURITY LAB Code Injection Attacks Outline Anatomy of Code-Injection Attacks Lab 3: Buffer Overflow Anatomy of Code-Injection Attacks Background About 60% of CERT/CC advisories deal with unauthorized
More informationSoftware Vulnerabilities. Jeff Foster University of Maryland, College Park
Software Vulnerabilities Jeff Foster University of Maryland, College Park When is a Program Secure? When it does exactly what it should! But what is it supposed to do? - Someone tells us (do we trust them?)
More informationCS 161 Computer Security
Paxson Spring 2017 CS 161 Computer Security Discussion 2 Question 1 Software Vulnerabilities (15 min) For the following code, assume an attacker can control the value of basket passed into eval basket.
More informationCSC 405 Computer Security Stack Canaries & ASLR
CSC 405 Computer Security Stack Canaries & ASLR Alexandros Kapravelos akaprav@ncsu.edu How can we prevent a buffer overflow? Check bounds Programmer Language Stack canaries [...more ] Buffer overflow defenses
More informationSoftware Vulnerabilities August 31, 2011 / CS261 Computer Security
Software Vulnerabilities August 31, 2011 / CS261 Computer Security Software Vulnerabilities...1 Review paper discussion...2 Trampolining...2 Heap smashing...2 malloc/free...2 Double freeing...4 Defenses...5
More informationECS 153 Discussion Section. April 6, 2015
ECS 153 Discussion Section April 6, 2015 1 What We ll Cover Goal: To discuss buffer overflows in detail Stack- based buffer overflows Smashing the stack : execution from the stack ARC (or return- to- libc)
More informationCPEG421/621 Tutorial
CPEG421/621 Tutorial Compiler data representation system call interface calling convention Assembler object file format object code model Linker program initialization exception handling relocation model
More informationANITA S SUPER AWESOME RECITATION SLIDES
ANITA S SUPER AWESOME RECITATION SLIDES 15/18-213: Introduction to Computer Systems Stacks and Buflab, 11 Jun 2013 Anita Zhang, Section M WHAT S NEW (OR NOT) Bomblab is due tonight, 11:59 PM EDT Your late
More informationThis is an example C code used to try out our codes, there several ways to write this but they works out all the same.
...._ _... _.;_/ [_) (_]\_ [ )(_](_. \.net._ "LINUX SHELLCODING REFERENCE" Author: Nexus Email: nexus.hack@gmail.com Website: http://www.playhack.net Introduction ------------- One of the most important
More informationSecure Programming Lecture 4: Memory Corruption II (Stack & Heap Overflows)
Secure Programming Lecture 4: Memory Corruption II (Stack & Heap Overflows) David Aspinall, Informatics @ Edinburgh 25th January 2018 Memory corruption Buffer overflow is a common vulnerability. Simple
More information18-600: Recitation #4 Exploits
18-600: Recitation #4 Exploits 20th September 2016 Agenda More x86-64 assembly Buffer Overflow Attack Return Oriented Programming Attack 3 Recap: x86-64: Register Conventions Arguments passed in registers:
More informationCS 33 (Week 4) Section 1G, Spring 2015 Professor Eggert (TA: Eric Kim) v1.0
CS 33 (Week 4) Section 1G, Spring 2015 Professor Eggert (TA: Eric Kim) v1.0 Announcements Midterm 1 was yesterday. It's over! Don't stress out too much. We'll go over the midterm next week Homework 3 due
More informationROP It Like It s Hot!
Wednesday, December 3, 14 2014 Red Canari, Inc. All rights reserved. 1 I N F O R M AT I O N S E C U R I T Y ROP It Like It s Hot! A 101 on Buffer Overflows, Return Oriented Programming, & Shell- code Development
More informationCSC 591 Systems Attacks and Defenses Return-into-libc & ROP
CSC 591 Systems Attacks and Defenses Return-into-libc & ROP Alexandros Kapravelos akaprav@ncsu.edu NOEXEC (W^X) 0xFFFFFF Stack Heap BSS Data 0x000000 Code RW RX Deployment Linux (via PaX patches) OpenBSD
More informationCS 161 Computer Security
Paxson Spring 2011 CS 161 Computer Security Discussion 1 January 26, 2011 Question 1 Buffer Overflow Mitigations Buffer overflow mitigations generally fall into two categories: (i) eliminating the cause
More informationU23 - Binary Exploitation
U23 - Binary Exploitation Stratum Auhuur robbje@aachen.ccc.de November 21, 2016 Context OS: Linux Context OS: Linux CPU: x86 (32 bit) Context OS: Linux CPU: x86 (32 bit) Address Space Layout Randomization:
More informationReturn-orientated Programming
Return-orientated Programming or The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86) Hovav Shacham, CCS '07 Return-Oriented oriented Programming programming
More informationProject 1 Notes and Demo
Project 1 Notes and Demo Overview You ll be given the source code for 7 short buggy programs (target[1-7].c). These programs will be installed with setuid root Your job is to write exploits (sploit[1-7].c)
More informationOverflows, Injection, & Memory Safety
Overflows, Injection, & Memory Safety 1 Announcements... Computer Science 161 Fall 2018 Project 1 is now live! Due Friday September 14th Start it early: The add/drop deadline got reduced to September 12th
More informationRoadmap: Security in the software lifecycle. Memory corruption vulnerabilities
Secure Programming Lecture 3: Memory Corruption I (introduction) David Aspinall, Informatics @ Edinburgh 24th January 2019 Roadmap: Security in the software lifecycle Security is considered at different
More informationCSE 361S Intro to Systems Software Lab Assignment #4
Due: Thursday, October 23, 2008. CSE 361S Intro to Systems Software Lab Assignment #4 In this lab, you will mount a buffer overflow attack on your own program. As stated in class, we do not condone using
More information