374
CC_STACKPROTECTOR防內核堆棧溢出補丁分析
作者：王智通
CC_STACKPROTECT補丁是Tejun Heo在09年給主線kernel提交的一個用來防止內核堆棧溢出的補丁。默認的config是將這個選項關閉的，可以在編譯內核的時候， 修改.config文件為CONFIG_CC_STACKPROTECTOR=y來啟用。未來飛天內核可以將這個選項開啟來防止利用內核stack溢出的0day攻擊。這個補丁的防溢出原理是： 在進程啟動的時候， 在每個buffer的後麵放置一個預先設置好的stack canary，你可以把它理解成一個哨兵， 當buffer發生緩衝區溢出的時候， 肯定會破壞stack canary的值， 當stack canary的值被破壞的時候， 內核就會直接當機。那麼是怎麼判斷stack canary被覆蓋了呢？ 其實這個事情是gcc來做的，內核在編譯的時候給gcc加了個-fstack-protector參數， 我們先來研究下這個參數是做什麼用的。
先寫個簡單的有溢出的程序：
[wzt@localhost csaw]$ cat test.c
#include <stdio.h>
#include <stdlib.h>
void test(void)
{
char buff[64];
memset(buff, 0x41, 128); //向64大小的buffer拷貝128字節， 肯定會發生緩衝區溢出。
}
int main(void)
{
test();
return 0;
}
[wzt@localhost csaw]$ gcc -o test test.c [wzt@localhost csaw]$ ./test
段錯誤
反匯編看看：
[wzt@localhost csaw]$ objdump -d test > hex 08048384 <test>: 8048384: 55 push %ebp 8048385: 89 e5 mov %esp,%ebp 8048387: 83 ec 58 sub $0x58,%esp 804838a: c7 44 24 08 80 00 00 movl $0x80,0x8(%esp) 8048391: 00 8048392: c7 44 24 04 41 00 00 movl $0x41,0x4(%esp) 8048399: 00 804839a: 8d 45 c0 lea 0xffffffc0(%ebp),%eax 804839d: 89 04 24 mov %eax,(%esp) 80483a0: e8 e3 fe ff ff call 8048288 <memset@plt> 80483a5: c9 leave 80483a6: c3 ret
沒什麼特別的，我們在加上-fstack-protector參數看看：
[wzt@localhost csaw]$ gcc -o test test.c -fstack-protector [wzt@localhost csaw]$ ./test *** stack smashing detected ***: ./test terminated 已放棄
這次程序打印了一條堆棧被溢出的信息，然後就自動退出了。
在反匯編看下：
[wzt@localhost csaw]$ objdump -d test > hex1 080483d4 <test>: 80483d4: 55 push %ebp 80483d5: 89 e5 mov %esp,%ebp 80483d7: 83 ec 68 sub $0x68,%esp 80483da: 65 a1 14 00 00 00 mov %gs:0x14,%eax 80483e0: 89 45 fc mov %eax,0xfffffffc(%ebp) 80483e3: 31 c0 xor %eax,%eax 80483e5: c7 44 24 08 80 00 00 movl $0x80,0x8(%esp) 80483ec: 00 80483ed: c7 44 24 04 41 00 00 movl $0x41,0x4(%esp) 80483f4: 00 80483f5: 8d 45 bc lea 0xffffffbc(%ebp),%eax 80483f8: 89 04 24 mov %eax,(%esp) 80483fb: e8 cc fe ff ff call 80482cc <memset@plt> 8048400: 8b 45 fc mov 0xfffffffc(%ebp),%eax 8048403: 65 33 05 14 00 00 00 xor %gs:0x14,%eax 804840a: 74 05 je 8048411 <test+0x3d> 804840c: e8 db fe ff ff call 80482ec <__stack_chk_fail@plt> 8048411: c9 leave 8048412: c3 ret
使用-fstack-protector參數後， gcc在函數的開頭放置了幾條匯編代碼：
!sh 80483d7: 83 ec 68 sub $0x68,%esp 80483da: 65 a1 14 00 00 00 mov %gs:0x14,%eax 80483e0: 89 45 fc mov %eax,0xfffffffc(%ebp)
將代碼段gs偏移0×14內存處的值賦值給了ebp-4， 也就是第一個變量值的後麵。
在call完memeset後，有如下匯編代碼：
!sh 80483fb: e8 cc fe ff ff call 80482cc <memset@plt> 8048400: 8b 45 fc mov 0xfffffffc(%ebp),%eax 8048403: 65 33 05 14 00 00 00 xor %gs:0x14,%eax 804840a: 74 05 je 8048411 <test+0x3d> 804840c: e8 db fe ff ff call 80482ec <__stack_chk_fail@plt>
在memset後，gcc要檢查這個操作是否發生了堆棧溢出, 將保存在ebp-4的這個值與原來的值對比一下，如果不相同， 說明堆棧發生了溢出，那麼就會執行stack_chk_fail這個函數， 這個函數是glibc實現的，打印出上麵看到的信息， 然後進程退出。
從這個例子中我們可以看出gcc使用了-fstack-protector參數後，會自動檢查堆棧是否發生了溢出， 但是有一個前提就是內核要給每個進程提前設置好一個檢測值放置在%gs:0×14位置處，這個值稱之為stack canary。所以我們可以看到防止堆棧溢出是由內核和gcc共同來完成的。
gcc的任務就是放置幾條匯編代碼， 然後和%gs:0×14位置處的值進行對比即可。 主要任務還是內核如何來設置stack canary， 也是CC_STACKPROTECTOR補丁要實現的目的， 下麵我們仔細來看下這個補丁是如何實現的。
既然gcc硬性規定了stack canary必須在%gs的某個偏移位置處， 那麼內核也必須按著這個規定來設置。
對於32位和64位內核， gs寄存器有著不同的功能。
64位內核gcc要求stack canary是放置在gs段的40偏移處， 並且gs寄存器在每cpu變量中是共享的，每cpu變量irq_stack_union的結構如下：
arch/x86/include/asm/processor.h
union irq_stack_union {
char irq_stack[IRQ_STACK_SIZE];
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
struct {
char gs_base[40];
unsigned long stack_canary;
};
};
DECLARE_PER_CPU_FIRST(union irq_stack_union, irq_stack_union);
gs_base隻是一個40字節的站位空間， stack_canary就緊挨其後。並且在應用程序進出內核的時候，內核會使用swapgs指令自動更換gs寄存器的內容。
32位下就稍微有點複雜了。由於某些處理器在加載不同的段寄存器時很慢， 所以內核使用fs段寄存器替換了gs寄存器。 但是gcc在使用-fstack-protector的時候， 還要用到gs段寄存器， 所以內核還要管理gs寄存器，我們要把CONFIG_X86_32_LAZY_GS選項關閉， gs也隻在進程切換的時候才改變。 32位用每cpu變量stack_canary保存stack canary。
struct stack_canary {
char __pad[20]; /* canary at %gs:20 */
unsigned long canary;
};
DECLARE_PER_CPU_ALIGNED(struct stack_canary, stack_canary);
內核是處於保護模式的， 因此gs寄存器就變成了保護模式下的段選子，在GDT表中也要有相應的設置：
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h index 1dc1b51..14e0ed8 100644 (file) --- a/arch/x86/include/asm/segment.h +++ b/arch/x86/include/asm/segment.h @@ -61,7 +61,7 @@ * * 26 - ESPFIX small SS * 27 - per-cpu [ offset to per-cpu data area ] - * 28 - unused + * 28 - stack_canary-20 [ for stack protector ] * 29 - unused * 30 - unused * 31 - TSS for double fault handler @@ -95,6 +95,13 @@ #define __KERNEL_PERCPU 0 #endif +#define GDT_ENTRY_STACK_CANARY (GDT_ENTRY_KERNEL_BASE + 16) +#ifdef CONFIG_CC_STACKPROTECTOR +#define __KERNEL_STACK_CANARY (GDT_ENTRY_STACK_CANARY * 8) +#else +#define __KERNEL_STACK_CANARY 0 +#endif + #define GDT_ENTRY_DOUBLEFAULT_TSS 31
GDT表中的第28個表項用來定為stack canary所在的段。
#define GDT_STACK_CANARY_INIT \
[GDT_ENTRY_STACK_CANARY] = GDT_ENTRY_INIT(0x4090, 0, 0x18),
GDT_STACK_CANARY_INIT在剛進入保護模式的時候被調用， 這個段描述符項被設置為基地址為0， 段大小設為24，因為隻在基地址為0， 偏移為0×14處放置一個4bytes的stack canary， 所以24字節正好。不理解的同學可以看看intel保護模式的手冊， 對著段描述符結構一個個看就行了。
在進入保護模式後， start_kernel()會調用boot_init_stack_canary()來初始話一個stack canary。
/*
* Initialize the stackprotector canary value.
*
* NOTE: this must only be called from functions that never return,
* and it must always be inlined.
*/
static __always_inline void boot_init_stack_canary(void)
{
u64 canary;
u64 tsc;
#ifdef CONFIG_X86_64
BUILD_BUG_ON(offsetof(union irq_stack_union, stack_canary) != 40);
#endif
/*
* We both use the random pool and the current TSC as a source
* of randomness. The TSC only matters for very early init,
* there it already has some randomness on most systems. Later
* on during the bootup the random pool has true entropy too.
*/
get_random_bytes(&canary, sizeof(canary));
tsc = __native_read_tsc();
canary += tsc + (tsc << 32UL);
current->stack_canary = canary;
#ifdef CONFIG_X86_64
percpu_write(irq_stack_union.stack_canary, canary);
#else
percpu_write(stack_canary.canary, canary);
#endif
}
隨機出了一個值賦值給每cpu變量， 32位是stack_canary, 64位是irq_stack_union。
內核在進一步初始化cpu的時候，會調用setup_stack_canary_segment()來設置每個cpu的GDT的stack canary描述符項：
start_kernel()->setup_per_cpu_areas()->setup_stack_canary_segment：
static inline void setup_stack_canary_segment(int cpu)
{
#ifdef CONFIG_X86_32
unsigned long canary = (unsigned long)&per_cpu(stack_canary, cpu);
struct desc_struct *gdt_table = get_cpu_gdt_table(cpu);
struct desc_struct desc;
desc = gdt_table[GDT_ENTRY_STACK_CANARY];
set_desc_base(&desc, canary);
write_gdt_entry(gdt_table, GDT_ENTRY_STACK_CANARY, &desc, DESCTYPE_S);
#endif
}
在內核剛進入保護模式的時候, stack canary描述符的基地址被初始化為0， 現在在cpu初始化的時候要重新設置為每cpu變量stack_canary的地址， 而不是變量保存的值。通過這些設置當內核代碼在訪問%gs:0×14的時候， 就會訪問stack canry保存的值。注意：setup_stack_canary_segment是針對32位內核做設置， 因為64位內核中的irq_stack_union是每cpu共享的， 不用針對每個cpu單獨設置。 然後就可以調用switch_to_new_gdt(cpu);來加載GDT表和加載gs寄存器。
經過上述初始化過程，在內核代碼裏訪問%gs:0×14就可以定位stack canary的值了， 那麼每個進程的stack canary是什麼時候設置的呢？
在內核啟動一個進程的時候， 會把gs寄存器的值設為KERNEL_STACK_CANARY
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -212,6 +212,7 @@ int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
regs.ds = __USER_DS;
regs.es = __USER_DS;
regs.fs = __KERNEL_PERCPU;
+ regs.gs = __KERNEL_STACK_CANARY;
regs.orig_ax = -1;
regs.ip = (unsigned long) kernel_thread_helper;
regs.cs = __KERNEL_CS | get_kernel_rpl();
內核在fork一個進程的時候， 有如下操作：
static struct task_struct *dup_task_struct(struct task_struct *orig)
{
#ifdef CONFIG_CC_STACKPROTECTOR
tsk->stack_canary = get_random_int();
#endif
}
隨機初始化了一個stack_canary保存在task_struct結構中的stack_canary變量中。當進程在切換的時候， 通過switch宏把新進程的stack canary保存在每cpu變量stack_canary中， 當前進程的stack_canary也保存在一個每cpu變量中，完成stack canary的切換。
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index 79b98e5..2692ee8 100644 (file)
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -23,6 +23,22 @@ struct task_struct *__switch_to(struct task_struct *prev,
#ifdef CONFIG_X86_32
+#ifdef CONFIG_CC_STACKPROTECTOR
+#define __switch_canary \
+ "movl "__percpu_arg([current_task])",%%ebx\n\t" \
+ "movl %P[task_canary](%%ebx),%%ebx\n\t" \
+ "movl %%ebx,"__percpu_arg([stack_canary])"\n\t"
+#define __switch_canary_oparam \
+ , [stack_canary] "=m" (per_cpu_var(stack_canary))
+#define __switch_canary_iparam \
+ , [current_task] "m" (per_cpu_var(current_task)) \
+ , [task_canary] "i" (offsetof(struct task_struct, stack_canary))
+#else /* CC_STACKPROTECTOR */
+#define __switch_canary
+#define __switch_canary_oparam
+#define __switch_canary_iparam
+#endif /* CC_STACKPROTECTOR */
+
/*
* Saving eflags is important. It switches not only IOPL between tasks,
* it also protects other tasks from NT leaking through sysenter etc.
@@ -46,6 +62,7 @@ do { \
"pushl %[next_ip]\n\t" /* restore EIP */ \
"jmp __switch_to\n" /* regparm call */ \
"1:\t" \
+ __switch_canary \
"popl %%ebp\n\t" /* restore EBP */ \
"popfl\n" /* restore flags */ \
\
@@ -58,6 +75,8 @@ do { \
"=b" (ebx), "=c" (ecx), "=d" (edx), \
"=S" (esi), "=D" (edi) \
\
+ __switch_canary_oparam \
+ \
/* input parameters: */ \
: [next_sp] "m" (next->thread.sp), \
[next_ip] "m" (next->thread.ip), \
@@ -66,6 +85,8 @@ do { \
[prev] "a" (prev), \
[next] "d" (next) \
\
+ __switch_canary_iparam \
+ \
: /* reloaded segment registers */ \
"memory"); \
} while (0)
前麵講過當gcc檢測到堆棧溢出的時候， 會調用glibc的stack_chk_fail函數， 但是當內核堆棧發生溢出的時候，
不能調用glibc的函數，所以內核自己實現了一個stack_chk_fail函數：
kernel/panic.c
#ifdef CONFIG_CC_STACKPROTECTOR
/*
* Called when gcc's -fstack-protector feature is used, and
* gcc detects corruption of the on-stack canary value
*/
void __stack_chk_fail(void)
{
panic("stack-protector: Kernel stack is corrupted in: %p\n",
__builtin_return_address(0));
}
EXPORT_SYMBOL(__stack_chk_fail);
#endif
當內核堆棧發生溢出的時候，就會執行stack_chk_fail函數， 內核當機。
這就是這個補丁的原理，不懂的同學請參考： https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=60a5317ff0f42dd313094b88f809f63041568b08
最後更新：2017-04-03 07:57:06