标签：des style http color io os ar strong for
In recent years Linux distributions started treating security more seriously. Out of many security features two are directly affecting C programmers:?-fstack-protector?and?-D_FORTIFY_SOURCE=2. These GCC options are now enabled by default on?Ubuntu?and?Fedora.
What do these options do?
-fstack-protector
Consider the following C function:
void fun() {
char *buf = alloca(0x100);
/* Don‘t allow gcc to optimise away the buf */
asm volatile("" :: "m" (buf));
}
Compiled without the?stack protector, with?-fno-stack-protector?option, GCC produces the following assembly:
08048404 <fun>:
push %ebp ; prologue
mov %esp,%ebp
?
sub $0x128,%esp ; reserve 0x128B on the stack
lea 0xf(%esp),%eax ; eax = esp + 0xf
and $0xfffffff0,%eax ; align eax
mov %eax,-0xc(%ebp) ; save eax in the stack frame
?
leave ; epilogue
ret
On the other hand with?-fstack-protector?option GCC adds protection code to your functions that use?alloca?or have buffers larger than 8 bytes. Additional code ensures the stack did not overflow. Here‘s the generated assembly:
08048464 <fun>:
push %ebp ; prologue
mov %esp,%ebp
?
sub $0x128,%esp ; reserve 0x128B on the stack
?
mov %gs:0x14,%eax ; load stack canary using gs
mov %eax,-0xc(%ebp) ; save it in the stack frame
xor %eax,%eax ; clear the register
?
lea 0xf(%esp),%eax ; eax = esp + 0xf
and $0xfffffff0,%eax ; align eax
mov %eax,-0x10(%ebp) ; save eax in the stack frame
?
mov -0xc(%ebp),%eax ; load canary
xor %gs:0x14,%eax ; compare against one in gs
je 8048493 <fun+0x2f>
call 8048340 <__stack_chk_fail@plt>
?
leave ; epilogue
ret
After a function prologue a canary is loaded and saved into the stack. Later, just before the epilogue the canary is verified against the original. If the values don‘t match the program exits with an appropriate message. This can protect against some buffer overflow attacks. It incurs some?performance penalty?but it seems to be worth the benefit.
When the stack is overwritten and?__stack_chk_fail?branch is taken the program crashes with a message like this:
*** stack smashing detected ***: ./protected terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xf76da0e5]
/lib/i386-linux-gnu/libc.so.6(+0x10409a)[0xf76da09a]
./protected[0x80484de]
./protected[0x80483d7]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf75ef4d3]
./protected[0x8048411]
======= Memory map: ========
08048000-08049000 r-xp 00000000 00:13 4058 ./protected
08049000-0804a000 r--p 00000000 00:13 4058 ./protected
0804a000-0804b000 rw-p 00001000 00:13 4058 ./protected
092e5000-09306000 rw-p 00000000 00:00 0 [heap]
f759e000-f75ba000 r-xp 00000000 08:01 161528 /lib/i386-linux-gnu/libgcc_s.so.1
f75ba000-f75bb000 r--p 0001b000 08:01 161528 /lib/i386-linux-gnu/libgcc_s.so.1
f75bb000-f75bc000 rw-p 0001c000 08:01 161528 /lib/i386-linux-gnu/libgcc_s.so.1
f75d5000-f75d6000 rw-p 00000000 00:00 0
f75d6000-f7779000 r-xp 00000000 08:01 161530 /lib/i386-linux-gnu/libc-2.15.so
f7779000-f777b000 r--p 001a3000 08:01 161530 /lib/i386-linux-gnu/libc-2.15.so
f777b000-f777c000 rw-p 001a5000 08:01 161530 /lib/i386-linux-gnu/libc-2.15.so
f777c000-f777f000 rw-p 00000000 00:00 0
f7796000-f779a000 rw-p 00000000 00:00 0
f779a000-f779b000 r-xp 00000000 00:00 0 [vdso]
f779b000-f77bb000 r-xp 00000000 08:01 161542 /lib/i386-linux-gnu/ld-2.15.so
f77bb000-f77bc000 r--p 0001f000 08:01 161542 /lib/i386-linux-gnu/ld-2.15.so
f77bc000-f77bd000 rw-p 00020000 08:01 161542 /lib/i386-linux-gnu/ld-2.15.so
ffeb2000-ffed3000 rw-p 00000000 00:00 0 [stack]
Aborted
-D_FORTIFY_SOURCE=2
Sample C code:
void fun(char *s) {
char buf[0x100];
strcpy(buf, s);
/* Don‘t allow gcc to optimise away the buf */
asm volatile("" :: "m" (buf));
}
Compiled without the code fortified, with?-U_FORTIFY_SOURCE?option:
08048450 <fun>:
push %ebp ; prologue
mov %esp,%ebp
?
sub $0x118,%esp ; reserve 0x118B on the stack
mov 0x8(%ebp),%eax ; load parameter `s` to eax
mov %eax,0x4(%esp) ; save parameter for strcpy
lea -0x108(%ebp),%eax ; count `buf` in eax
mov %eax,(%esp) ; save parameter for strcpy
call 8048320 <strcpy@plt>
?
leave ; epilogue
ret
With?-D_FORTIFY_SOURCE=2:
08048470 <fun>:
push %ebp ; prologue
mov %esp,%ebp
?
sub $0x118,%esp ; reserve 0x118B on the stack
movl $0x100,0x8(%esp) ; save value 0x100 as parameter
mov 0x8(%ebp),%eax ; load parameter `s` to eax
mov %eax,0x4(%esp) ; save parameter for strcpy
lea -0x108(%ebp),%eax ; count `buf` in eax
mov %eax,(%esp) ; save parameter for strcpy
call 8048370 <__strcpy_chk@plt>
?
leave ; epilogue
ret
You can see GCC generated some additional code. This time instead of calling?strcpy(dst, src)?GCC automatically calls?__strcpy_chk(dst, src, dstlen). With?FORTIFY_SOURCE?whenever possible GCC tries to uses buffer-length aware replacements for functions like?strcpy,?memcpy,?memset, etc.
Again, this prevents some buffer overflow attacks. Of course you should avoidstrcpy?and always use?strncpy, but it‘s worth noting that FORTIFY_SOURCE can also help with?strncpy?when GCC knows the destination buffer size. For example:
void fun(char *s, int l) {
char buf[0x100];
strncpy(buf, s, l);
asm volatile("" :: "m" (buf[0]));
}
Here GCC instead of calling?strncpy(dst, src, l)?will call__strncpy_chk(dst, src, l, 0x100)?as GCC is aware of the size of the destination buffer.
When the buffer is overrun the program fails with a message very similar to the one seen previously. Instead of "stack smashing detected" you‘ll see "buffer overflow detected" headline:
*** buffer overflow detected ***: ./fortified terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xf76d30e5]
/lib/i386-linux-gnu/libc.so.6(+0x102eba)[0xf76d1eba]
/lib/i386-linux-gnu/libc.so.6(+0x1021ed)[0xf76d11ed]
./fortified[0x8048488]
./fortified[0x80483a7]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf75e84d3]
./fortified[0x80483e1]
======= Memory map: ========
08048000-08049000 r-xp 00000000 00:13 4208 ./fortified
08049000-0804a000 r--p 00000000 00:13 4208 ./fortified
0804a000-0804b000 rw-p 00001000 00:13 4208 ./fortified
08d6b000-08d8c000 rw-p 00000000 00:00 0 [heap]
f7597000-f75b3000 r-xp 00000000 08:01 161528 /lib/i386-linux-gnu/libgcc_s.so.1
f75b3000-f75b4000 r--p 0001b000 08:01 161528 /lib/i386-linux-gnu/libgcc_s.so.1
f75b4000-f75b5000 rw-p 0001c000 08:01 161528 /lib/i386-linux-gnu/libgcc_s.so.1
f75ce000-f75cf000 rw-p 00000000 00:00 0
f75cf000-f7772000 r-xp 00000000 08:01 161530 /lib/i386-linux-gnu/libc-2.15.so
f7772000-f7774000 r--p 001a3000 08:01 161530 /lib/i386-linux-gnu/libc-2.15.so
f7774000-f7775000 rw-p 001a5000 08:01 161530 /lib/i386-linux-gnu/libc-2.15.so
f7775000-f7778000 rw-p 00000000 00:00 0
f778f000-f7793000 rw-p 00000000 00:00 0
f7793000-f7794000 r-xp 00000000 00:00 0 [vdso]
f7794000-f77b4000 r-xp 00000000 08:01 161542 /lib/i386-linux-gnu/ld-2.15.so
f77b4000-f77b5000 r--p 0001f000 08:01 161542 /lib/i386-linux-gnu/ld-2.15.so
f77b5000-f77b6000 rw-p 00020000 08:01 161542 /lib/i386-linux-gnu/ld-2.15.so
fff8d000-fffae000 rw-p 00000000 00:00 0 [stack]
Aborted
?
SRC=https://idea.popcount.org/2013-08-15-fortify_source/
标签：des style http color io os ar strong for
原文地址：http://www.cnblogs.com/coryxie/p/3979094.html
