1. Stack Protection Systems: (propolice, StackGuard, XP SP2)
Hiroaki Etoh
Tokyo Research Laboratory, IBM Japan

2. Contents Buffer overflow in stack What is a stack smashing attack
Stack protector landscape
StackGuard
propolice
Windows XP SP2 (/Gs option)
Comparison
Summary

3. What is a buffer overflow in the stack
A buffer overflow occurs when you try to put too many bits into an allocated buffer.
When this happens, the next contiguous chunk of memory is overwritten, such as
Return address
Function pointer
Previous frame pointer, etc.
Also an attack code is injected.
This can lead to a serious security problem.
アドレスの保管場所

4. Stack Layout and Contaminated Memory by the Attack --- when function foo is called by bar.
int bar (int val1) {
int val2;
foo (a_function_pointer); }
val1
val2
arguments (funcp)
return address
Previous Frame Pointer
pointer var (ptr)
buffer (buf)
String grows
Contaminated memory
int foo (void (*funcp)()) {
char* ptr = point_to_an_array;
char buf[128];
gets (buf);
strncpy(ptr, buf, 8);
(*funcp)(); }
Ｆｏｏが呼ばれたときのメモリ状況、スタックの伸び、保管の伸び、　関数の戻り処理ではリターンアドレスを手繰って戻ります。
Gets()関数は端末からの入力を。。。。　（今使うことはない）入力分だけメモリに保管するため、
Most popular target
Stack grows

5. Attack Scenario #1 --- by changing the return address
args (funcp)
return address
PFP
pointer var (ptr)
buffer (buf)
② set those pointers to the stack.
Attack code
“/bin/sh” ①
system()
Changes the return address to point to the attack code. After the function returns, it leads to the attack code.
The existing instructions in the code segment can be used as an attack code; such as system(), exec(), etc.

6. Jumping through code fragments in the code region
Pseudo code execution on the stack, avoiding the non-executable stack method “Avoiding Stackguard and Other Stack Protection - Proof of Concept Code”
After buffer overflow
CODE REGION
Code #3
data
Code #2
Code #1
Code #1
Pop di
ret
Store [DI], AX
Code #2
Pop ax
ret
Load AX, data
Load DI, data
Code #3
stosd
ret
Jumping through code fragments in the code region

7. Attack Scenario #2 --- by changing pointer variables
args (funcp)
return address
PFP
pointer var (ptr)
buffer (buf)
Attack code
Global Offset Table
Function pointer
Changes a function pointer to point to the attack code. The succeeding function pointer call leads to the attack code.
Any memory, even not in the stack, can be modified by the statement that stores a value into the compromised pointer. E.g. strncpy(ptr, buf, 8); *ptr = 0;
slide 6 does not contain 1, but two. i think you would benefit from splitting this up, since the mixture of the two together on
one page is quite confusing.
so it really is 3 attack scenarios (return address, arguments, and fp -> local or arguments)
i think that is a better way to explain it, especially since later when you go to your 'safe stack model' you split things into 3 similar zones.

8. Attack Scenario #3 --- by changing the previous frame pointer
args (funcp)
return address
PFP
pointer var (ptr)
buffer (buf)
return address
PFP
Attack code
modify the caller’s frame to the nearby location. The frame contains a compromised return address.

9. Stack protector Landscape
Compiler based protector
StackGuard, stack shield, propolice, XP SP2 /Gs
Runtime stack integrity checker
Libsafe
Non-executable parts of the address space
Solar Designer’s “non-exec stack patch”, Exec Shield, OpenBSD’s W^X, XP SP2 NX
There is no single solution!!!
Exec shield:　　　
Compiler based protection: 攻撃源に最も近いところを扱える。

10. Stack Guard
StackGuard places a “canary” word next to (prior) the return address on the stack.
Once the function is done, the protection instrument checks to make sure that the canary word is unmodified before jumping to the return address.
If the integrity of canary word is compromised, the program will terminate.
Vulnerability report
“BYPASSING STACKGUARD AND STACKSHIELD”, Phrack 56
“Four different tricks to bypass StackShield and StackGuard protection”
“Four different tricks to bypass StackShield and StackGuard protection”

11. Local variables including arrays
Stack Guard 2.1
Canary value variations
Terminator canary 0x000aff0d
Random canary random
XOR canary: random ^ return address
You choose a canary method when building the compiler.
mprotect prohibits write access to this data.
args
return address
canary
PFP
Local variables including arrays
String grows
Random value in data
Terminator canary is selected by difficulty to copy via standard library
slide 9
does not make it clear where/when each canary is used by them
should this be shown somehow on the slide
ie. compiler chooses which canary is suitable for each function:
... list
or ..?
Stack grows

12. Stack Guard under development
Move the canary to eliminate the frame pointer problem
Broad range of integrity check for return address, frame pointer, and local variables.
args
return address
PFP
canary
Local variables including arrays
String grows
Random value in data
slide 10
instead of 'change the canary location .." a native english speaker
would say something like 'move the canary to eliminate the frame
pointer problem'. but it is good :)
XOR
Stack grows

13. propolice: design goal
Introduce “Safe Stack Usage Model”
This is a combination of an ideal stack layout and a way to check the stack integrity.
Transform a program to meet the ideal stack layout as much as possible.
A patch for GNU gcc compiler adds a compilation stage to transform the program.
A sort of programs can not be changed to the layout. (e.g. data structure with pointers and arrays)

14. Not compromised by an overflow.
Safe Stack Usage Model
Stack integrity check:
Assigns unpredictable value into the guard at the function prologue.
Confirms the integrity of the guard value at the function epilogue, or aborts the program execution.
Ideal stack layout:
A doesn’t have arrays nor pointer variables.
B has only arrays
C has no array, but has pointer variables.
args
return address
PFP
guard
arrays
Local variables
String grows A
Not compromised by an overflow. B C
Stack grows

15. Why caller function is safe from a stack smashing attack.
There are no pointer variables from args to guard, which is the function’s accessible range. So any memory can’t be compromised by a pointer attack.
When a function successfully return to the caller function, it means that contiguous chunk of memory of caller function’s stack is not compromised by buffer overflows.
args
return address
PFP
guard
arrays
Local variables
String grows A
Function’s accessible range B C
Stack grows

16. Intuitive explanation: how to make a guard instrument between PFP and arrays.
foo () {
char *p;
char buf[128];
gets (buf); }
Int32 random_number;
foo () {
volatile int32 guard;
char buf[128];
char *p;
guard = random_number;
gets (buf);
if (guard != random_number)
/* program halts */ }
Insert guard instrument
Relocate local variables
+ The optimizer may eliminate the second access for random_number.
- The buffer alloca allocated can not be relocate next to the guard.
The Stack-Smashing Protector (SSP, formerly ProPolice) is perhaps one of the most sophisticated yet simplistic protective compiler technologies to date which makes use of canary values by rearranging local variables and function pointers. When (ssp) is enabled it can prevent many forms of the common return-to-libc attack. It is implemented as a patch to GCC which will automatically insert protection code into your programs at compile time. It is developed by Hiroaki Etoh at IBM. For more information visit the official (ssp) website.
Overall this is an excellent security measure. We know that the applications we use have yet to be discovered bugs, and this protection helps minimize the possibility of an exploit due to these bugs. The flawed application may well still crash, but privileges will not be escalated, and your system will not be compromised. Best of all, we'll get some information on where in the program code the overflow occurred, which will allow us to quickly track down the problem and fix it.
However, ProPolice does not catch all possible overflows, and there are still some cases that will get through the stack-smashing protection code. This is not an end all, be all solution to security, it is merely a step in the right direction.
This patch was recently implemented in OpenBSD 3.3 and later, and looks like an excellent addition to proactive security.

17. Intuitive explanation: how to treat function arguments if any of them has a pointer type.
foo (int a, void (*fn)()) {
char buf[128];
gets (buf);
(*fn)(); }
Int32 random_number;
foo (int a, void (*fn)()) {
volatile int32 guard;
char buf[128];
(void *safefn)() = fn;
guard = random_number;
gets (buf);
(*safefn)();
if (guard != random_number)
/* program halts */ }
Copy the pointer to a variable assigned from the region C. In fact, it try to assign the register for that variable.
Rename the function call with the assigned variable.
The Stack-Smashing Protector (SSP, formerly ProPolice) is perhaps one of the most sophisticated yet simplistic protective compiler technologies to date which makes use of canary values by rearranging local variables and function pointers. When (ssp) is enabled it can prevent many forms of the common return-to-libc attack. It is implemented as a patch to GCC which will automatically insert protection code into your programs at compile time. It is developed by Hiroaki Etoh at IBM. For more information visit the official (ssp) website.
Overall this is an excellent security measure. We know that the applications we use have yet to be discovered bugs, and this protection helps minimize the possibility of an exploit due to these bugs. The flawed application may well still crash, but privileges will not be escalated, and your system will not be compromised. Best of all, we'll get some information on where in the program code the overflow occurred, which will allow us to quickly track down the problem and fix it.
However, ProPolice does not catch all possible overflows, and there are still some cases that will get through the stack-smashing protection code. This is not an end all, be all solution to security, it is merely a step in the right direction.
This patch was recently implemented in OpenBSD 3.3 and later, and looks like an excellent addition to proactive security.

18. propolice: stack protector options
-fstack-protector
Stack protection instruments are generated only when the function has a byte array.
-fstack-protector-all
Always generate the guard instrument.
If a byte array is used, it is allocated next to the guard.
Otherwise, any array is allocated next to the guard.
Integer overflow can’t be protected if any byte array isn’t used in the same function.

19. propolice status http://www. research. ibm
Actual usage
Laser5, trusted debian, openbsd, gentoo, etc
Supported architectures
Ix86, powerpc, alpha, sparc, mips, vax, m68k, amd64
Gcc versions
gcc – gcc3.4.1
gcc HEAD cvs under development

20. Microsoft XP SP2 --- Windows 2003 stack protection
Non executable stack
Compiler /Gs option
Combination method of xor canary and propolice
Far from ideal stack layout
Vulnerability report
David Litchfield, “Defeating the stack based buffer overflow prevention mechanism of Microsoft Windows 2003 server”

21. How Gs option works
Canary is inserted prior to the first occurrence of byte array allocated
Local variables except arrays seems to be assigned alphabetical order in the stack.
args
return address
PFP
Local variables
including arrays
String grows
Stack point register
Random value in data
XOR
canary
First byte array
Stack grows

22. Comparison of protection techniques --- protection level
StackGuard
2.1/3
MS /Gs
propolice
propolice stack-protector-all
Any buffer overflow
applicable no
Return address
detect
PFP
no/detect
Pointers in local variable
protect
Pointers in args
Function pointer
Modifications by pointer
Detect:
Protect:
detect: The modification is found at the end of the function.
protect: The modification can’t be done.

23. Performance considerations
SG/tc
SG/rc
SG/xc
SG/3
MS/Gs
propolice
propolice/all
Protect all funcs
yes no
Number of extra instructions executed at no overflow detection
Mem load 1 3 5
5 -
2 – 3
Mem save
Other 2 4
4 -
Experimental benchmark (execution overhead: %)
Ctag -
Perl 8
The overhead percentages shown make it sufficient to enable this by default in all operating systems.

24. Summary Introduced stack overflow problem.
Explained the variety of stack smashing attacks.
Provided characteristics for StackGuard, propolice, and MS/Gs.
Compared each protection methods from various aspects.