解读Linux安全机制之栈溢出保护

最新推荐文章于 2023-03-30 10:07:32 发布
最新推荐文章于 2023-03-30 10:07:32 发布
阅读量1.2k 收藏 3
点赞数 1
文章标签： git php python
原文链接：https://my.oschina.net/macwe/blog/610357
版权

为什么80%的码农都做不了架构师？>>>   hot3.png

解读Linux安全机制之栈溢出保护

0x00 概述

栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。当启用栈保护后，函数开始执行的时候会先往栈里插入cookie信息，当函数真正返回的时候会验证cookie信息是否合法，如果不合法就停止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护检查失败而阻止shellcode的执行。在Linux中我们将cookie信息称为canary(以下统一使用canary)。

gcc在4.2版本中添加了-fstack-protector和-fstack-protector-all编译参数以支持栈保护功能，4.9新增了-fstack-protector-strong编译参数让保护的范围更广。以下是-fstack-protector和-fstack-protector-strong的区别：

参数gcc支持版本说明
-fstack-protector4.2只为局部变量中包含长度超过8-byte(含)的char数组的函数插入保护代码
-fstack-protector-strong4.9满足以下三个条件都会插入保护代码：1.局部变量的地址作为赋值语句的右值或函数参数；2.局部变量包含数组类型的局部变量，不管数组的长度；3.带register声明的局部变量

Linux系统中存在着三种类型的栈：

  1. 应用程序栈：工作在Ring3,由应用程序来维护；
  2. 内核进程上下文栈：工作在Ring0，由内核在创建线程的时候创建；
  3. 内核中断上下文栈：工作在Ring0，在内核初始化的时候给每个CPU核心创建一个。

0x01 应用程序栈保护

1. 栈保护工作原理

下面是一个包含栈溢出的例子：

/* test.c */
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
    char buf[16];

    scanf("%s", buf);
    printf("%s\n", buf);

    return 0;
}

我们先禁用栈保护功能看看执行的结果

[root@localhost stackp]# gcc -o test test.c -fno-stack-protector
[root@localhost stackp]# python -c "print 'A'*24" | ./test
AAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault   <- RIP腐败，导致异常

当返回地址被覆盖后产生了一个段错误，因为现在的返回地址已经无效了，所以现在执行的是CPU的异常处理流程。我们打开栈保护后再看看结果：

[root@localhost stackp]# gcc -o test test.c -fstack-protector
[root@localhost stackp]# python -c "print 'A'*25" | ./test
AAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: ./test terminated <- 提示检查到栈溢出

这时触发的就不是段错误了，而是栈保护的处理流程，我们反汇编看看做了哪些事情：

0000000000400610 <main>:
  400610:       55                      push   %rbp
  400611:       48 89 e5                mov    %rsp,%rbp
  400614:       48 83 ec 30             sub    $0x30,%rsp
  400618:       89 7d dc                mov    %edi,-0x24(%rbp)
  40061b:       48 89 75 d0             mov    %rsi,-0x30(%rbp)
  40061f:       64 48 8b 04 25 28 00    mov    %fs:0x28,%rax  <- 插入canary值
  400626:       00 00
  400628:       48 89 45 f8             mov    %rax,-0x8(%rbp)
  40062c:       31 c0                   xor    %eax,%eax
  40062e:       48 8d 45 e0             lea    -0x20(%rbp),%rax
  400632:       48 89 c6                mov    %rax,%rsi
  400635:       bf 00 07 40 00          mov    $0x400700,%edi
  40063a:       b8 00 00 00 00          mov    $0x0,%eax
  40063f:       e8 cc fe ff ff          callq  400510 <__isoc99_scanf@plt>
  400644:       48 8d 45 e0             lea    -0x20(%rbp),%rax
  400648:       48 89 c7                mov    %rax,%rdi
  40064b:       e8 80 fe ff ff          callq  4004d0 <puts@plt>
  400650:       b8 00 00 00 00          mov    $0x0,%eax
  400655:       48 8b 55 f8             mov    -0x8(%rbp),%rdx  <- 检查canary值
  400659:       64 48 33 14 25 28 00    xor    %fs:0x28,%rdx
  400660:       00 00
  400662:       74 05                   je     400669 <main+0x59> # 0x400669
  400664:       e8 77 fe ff ff          callq  4004e0 <__stack_chk_fail@plt>
  400669:       c9                      leaveq
  40066a:       c3                      retq

我们看到函数开头(地址：0x40061f)处gcc编译时在栈帧的返回地址和临时变量之间插入了一个canary值，该值是从%fs:0x28里取的，栈帧的布局如下：

stack:
| ......          |
| orig_return     |
| orig_rbp        |  <- %rbp
| canary          |  <- -0x8(%rpb), 既 %fs:0x28
| local variables |
|                 |  <- %rsp

在函数即将返回时(地址：0x400655)检查栈中的值是否和原来的相等，如果不相等就调用glibc的__stack_chk_fail函数，并终止进程。

2. canary值的产生

这里以x64平台为例，canary是从%fs:0x28偏移位置获取的，%fs寄存器被glibc定义为存放tls信息的，我们需要查看glibc的源代码：

typedef struct
{
  void *tcb;		/* Pointer to the TCB.  Not necessarily the
			   thread descriptor used by libpthread.  */
  dtv_t *dtv;
  void *self;		/* Pointer to the thread descriptor.  */
  int multiple_threads;
  int gscope_flag;
  uintptr_t sysinfo;
  uintptr_t stack_guard;   <- canary值，偏移位置0x28处
  uintptr_t pointer_guard;
  ......
} tcbhead_t;

结构体tcbhead_t就是用来描述tls的也就是%fs寄存器指向的位置，其中+0x28偏移位置的成员变量stack_guard就是canary值。另外通过strace ./test看到在进程加载的过程中会调用arch_prctl系统调用来设置%fs的值，

root@localhost stackp]# strace ./test
execve("./test", ["./test"], [/* 24 vars */]) = 0
......
arch_prctl(ARCH_SET_FS, 0x7f985a041740) = 0
......

产生canary值的代码在glibc的_dl_main和__libc_start_main函数中：

  /* Set up the stack checker's canary.  */
  uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (_dl_random);
# ifdef THREAD_SET_STACK_GUARD
  THREAD_SET_STACK_GUARD (stack_chk_guard);
# else
  __stack_chk_guard = stack_chk_guard;
# endif

_dl_random是一个随机数，它由_dl_sysdep_start函数从内核获取的。_dl_setup_stack_chk_guard函数负责生成canary值，THREAD_SET_STACK_GUARD宏将canary设置到%fs:0x28位置。

在应用程序栈保护中，进程的%fs寄存器是由glibc来管理的，并不涉及到内核提供的功能。

3. x32应用程序栈保护

解读完了x64的实现，我们来看看x32下面的情况，我们还是使用上面例子的代码在x32的机器上编译，得到下面的代码：

08048464 <main>:
 ......
 8048474:    65 a1 14 00 00 00      mov   %gs:0x14,%eax  # 插入canary值
 804847a:    89 44 24 3c            mov   %eax,0x3c(%esp)
 ......
 80484aa:    65 33 15 14 00 00 00   xor   %gs:0x14,%edx  # 检查canary值
 80484b1:    74 05                  je    80484b8 <main+0x54> # 0x80484b8
 80484b3:    e8 c0 fe ff ff         call  8048378 <__stack_chk_fail@plt>
 80484b8:    c9                     leave
 80484b9:    c3                     ret

在x32下的实现和x64是一样的，只不过canary值保存在%gs:0x14中，glibc使用%gs寄存器来保存TLS信息。

0x02 内核态栈保护

Linux的CC_STACKPROTECTOR补丁提供了对内核栈溢出保护功能，该补丁是Tejun Heo在09年给主线kernel提交的。

  • 2.6.24：首次出现CONFIG_CC_STACKPROTECTOR编译选项并实现了x64平台的进程上下文栈保护支持；
  • 2.6.30：新增对内核中断上下文的栈保护和对x32平台进程上下文的栈保护支持;
  • 3.14：对该功能进行了一次升级以支持gcc的-fstack-protector-strong参数，提供更大范围的栈保护。

1. 栈保护工作原理

我们参照前面的代码写了一个可加载模块并反汇编来看看是怎么样的：

[root@localhost stackpk]# objdump -r test.ko
RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE
0000000000000061 R_X86_64_PC32     __stack_chk_fail-0x0000000000000004
......

[root@localhost stackpk]# objdump -d test.ko
0000000000000000 <foo>:
  ......
  # 函数开头，往栈里插入canary
  24:   65 48 8b 04 25 28 00    mov    %gs:0x28,%rax
  2d:   48 89 45 f8             mov    %rax,-0x8(%rbp)
  ......
  # 函数返回，检查canary
  4a:   48 8b 45 f8             mov    -0x8(%rbp),%rax
  4e:   65 48 33 04 25 28 00    xor    %gs:0x28,%rax
  57:   75 02                   jne    5b <foo+0x5b>
  59:   c9                      leaveq
  5a:   c3                      retq
  5b:   0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
  60:   e8 00 00 00 00          callq  65 <foo+0x65>  # __stack_chk_fail

内核函数的栈保护工作原理和应用程序的栈保护是一样的，只不过canary是从内核%gs:0x28位置取的，并且检查失败时调用内核的__stack_chk_fail函数并且产生panic。

2. 中断上下文canary值的产生

x64平台

硬件中断(hardware interrupt)和软中断(softirq)都使用中断栈(Interrupt stack)。

当内核刚进入64位模式的时候，startup_64函数为内核的初始化工作设置好了%gs寄存器和分配栈空间，代码在arch/x86/kernel/head_64.S中，下面是startup_64函数片段：

/* Setup a boot time stack */
movq stack_start(%rip), %rsp

/* Set up %gs */
movl	$MSR_GS_BASE,%ecx
movl	initial_gs(%rip),%eax
movl	initial_gs+4(%rip),%edx
wrmsr	

GLOBAL(initial_gs)
.quad	INIT_PER_CPU_VAR(irq_stack_union)
GLOBAL(stack_start)
.quad  init_thread_union+THREAD_SIZE-8
.word  0

其中%gs被定义为percpu变量，可用irq_stack_union联合体表示：

union irq_stack_union {
	char irq_stack[IRQ_STACK_SIZE];
	struct {
		char gs_base[40];
		unsigned long stack_canary; <- GS+40偏移位置
	};
};

startup_64的末尾会跳转到start_kernel函数，该函数也是canary产生的地方。start_kernel调用了boot_init_stack_canary，它的作用就是产生一个随机的canary并且应用到当前%gs:0x28位置：

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
	
	/* 同时使用随机数和TSC，让随机性更强 */
	get_random_bytes(&canary, sizeof(canary));
	tsc = rdtsc();
	canary += tsc + (tsc << 32UL);

	/* PID为0, 此时的进程名叫swapper,之后成为idle进程  */
	current->stack_canary = canary; <- canary信息保存在这里
#ifdef CONFIG_X86_64
	this_cpu_write(irq_stack_union.stack_canary, canary);
#else
	this_cpu_write(stack_canary.canary, canary);
#endif
}

start_kernel函数是由boot CPU执行的，在多核心的情况下还会在每个CPU核心初始化的时候分别调用boot_init_stack_canary来产生canary值。我们发现中断上下文的canary值保存在每个核心的idle进程task_struct->stack_canary中，这样当上下文切换的时候就不会丢失了。

x32平台

在x32平台上的percpu区域是保存在%fs中的，内核初始化的时候会为每个cpu核心产生canary值存放在percpu区域的stack_canary成员中备用。

struct stack_canary {
	char __pad[20];		/* canary at %gs:20 */
	unsigned long canary;
};
DECLARE_PER_CPU_ALIGNED(struct stack_canary, stack_canary);

但是gcc要求canary值必须从%gs:0x14偏移的位置获取，因此必须让%gs:0x14指向percpu变量stack_canary.canary才行。首先内核选用GDT第28项描述的数据段来存放canary信息：

/* ./arch/x86/include/asm/segment.h */
#define GDT_ENTRY_STACK_CANARY		28   <- canary数据段索引

#ifdef CONFIG_CC_STACKPROTECTOR
# define __KERNEL_STACK_CANARY		(GDT_ENTRY_STACK_CANARY*8)
#else
# define __KERNEL_STACK_CANARY		0
#endif

/* ./arch/x86/include/asm/stackprotector.h */
#define GDT_ENTRY_INIT(flags, base, limit) { { { \
		.a = ((limit) & 0xffff) | (((base) & 0xffff) << 16), \
		.b = (((base) & 0xff0000) >> 16) | (((flags) & 0xf0ff) << 8) | \
			((limit) & 0xf0000) | ((base) & 0xff000000), \
	} } }
	
/* 段描述符 limit=0x18,s=1,dpl=0,p=1,avl=0,l=0,d=1,g=0 */
#define GDT_STACK_CANARY_INIT						\
	[GDT_ENTRY_STACK_CANARY] = GDT_ENTRY_INIT(0x4090, 0, 0x18),
	
/* 将percpu变量stack_canary的地址设置到段描述符base */
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
}

接下来只要设置%gs寄存器来索引该段描述符就可以了：

/* ./arch/x86/include/asm/stackprotector.h */
static inline void load_stack_canary_segment(void)
{
#ifdef CONFIG_X86_32
	asm("mov %0, %%gs" : : "r" (__KERNEL_STACK_CANARY) : "memory");
#endif
}

/* ./arch/x86/kernel/cpu/common.c */
void load_percpu_segment(int cpu)
{
#ifdef CONFIG_X86_32
    loadsegment(fs, __KERNEL_PERCPU);
#else
    loadsegment(gs, 0);
    wrmsrl(MSR_GS_BASE, (unsigned long)per_cpu(irq_stack_union.gs_base, cpu));
#endif
    load_stack_canary_segment();
}

到这里x32平台的%gs:0x14偏移的canary值已经初始化完成了。

2. 进程上下文canary值的产生

无论是内核线程还是用户线程，当一个线程创建的时候，内核给线程生成一个canary值存放在task_struct结构体的stack_canary成员变量中，见dup_task_struct函数：

/* ./kernel/fork.c */

 static struct task_struct *dup_task_struct(struct task_struct *orig)
 {
     ......
 #ifdef CONFIG_CC_STACKPROTECTOR
     tsk->stack_canary = get_random_int();
 #endif
     ......
 }

接下来内核要做的事情就是当发生线程切换的时候让该canary值设置到%gs:0x28偏移处，这个是在switch_to宏中完成的：

/* ./arch/x86/include/asm/switch_to.h */

#define __switch_canary                                   \
    "movq %P[task_canary](%%rsi),%%r8\n\t"                \
    "movq %%r8,"__percpu_arg([gs_canary])"\n\t"
#define __switch_canary_oparam                            \
    , [gs_canary] "=m" (irq_stack_union.stack_canary)
#define __switch_canary_iparam                            \
    , [task_canary] "i" (offsetof(struct task_struct, stack_canary))

#define switch_to(prev, next, last)                   \
	asm volatile(SAVE_CONTEXT                         \
		 ......
		 __switch_canary                              \
		 ......
         : "=a" (last)                                \
           __switch_canary_oparam                     \
         : [next] "S" (next), [prev] "D" (prev),      \
		 ......
		 __switch_canary_iparam                       \
         : "memory", "cc" __EXTRA_CLOBBER)

上面是x64平台上的代码并且忽略了与canary值切换无关的部分，它把task_struct->stack_canary赋值到percpu变量irq_stack_union.stack_canary，这样我们代码中找到的canary值就是当前上下文的了。在x32平台上也是类似的只不过percpu变量是stack_canary.canary。

总结： 在gcc、glibc和内核的共同支持下，Linux对所有的可能发生缓冲区溢出的栈返回地址都进行了保护：

  1. 在应用进程上下文，canary值由glibc产生并保存在tcbhead_t中，当canary检查失败时执行glibc的__stack_chk_fail，并终止进程；
  2. 在内核进程上下文，canary值在内核copy_process时产生并保存在task_struct中，当canary检查失败时执行内核的__stack_chk_fail，并产生panic；
  3. 在内核中断上下文，canary值在start_kernel以及每个CPU核心初始化的时候产生并保存在每个CPU核心的idle进程task_struct中，当canary检查失败时执行内核的__stack_chk_fail，并产生panic。

0x03 参考资料

转载于:https://my.oschina.net/macwe/blog/610357

weixin_33922672
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
栈溢出基础知识、栈溢出保护机制、栈溢出利用方法.docx
01-10
总结来说，理解栈溢出的基本原理、保护机制以及利用方法对于提升系统的安全性至关重要。在开发过程中，应遵循良好的编程实践，避免栈溢出的发生，而在防御方面，了解攻击手段有助于设计更有效的防护策略。
linux内核堆栈保护浅析
whuzm08的专栏
05-25 9249
一 启用方式 打开配置CONFIG_CC_STACKPROTECTOR，重新编译内核即可。 二 工作原理 搜索配置CONFIG_CC_STACKPROTECTOR产生的影响，可得到如下结果： 1.include/linux/stackprotector.h #ifdef CONFIG_CC_STACKPROTECTOR # include #else static inl
__stack_chk_fail之栈帧溢出检测技术
03-01 1073
一.参考文章 (52条消息) canary介绍与绕过技巧_0pt1mus-CSDN博客_canary绕过https://blog.csdn.net/weixin_43713800/article/details/105273284 (52条消息) 【GDB】__stack_chk_fail 栈溢出问题定位_pcj_888的博客-CSDN博客___stack_chk_fail定位手段https://blog.csdn.net/pcj_888/article/details/111305718#:~:te.
Linux内核启动及文件系统加载过程
ffmxnjm的博客
07-14 6986
ooooooooooooo
Linux进程内核栈
GetnextWindow的专栏
09-18 1375
进程创建的时候Linux内核会创建内核栈（arm手册也要求内核态有单独的栈），如应用进程在用户态通过系统调用陷入内核态的时候，上下文信息（如cpu寄存器）需要有个地方保存，如此，从内核态切换回用户态时候，能继续从系统调用之后的代码开始执行，这个保存的地方就是进程的内核栈，本文主要描述arm32下内核栈的生成过程和结构。
Linux编译x86架构内核出现_stack_chk_guard未定义错误
yanxiangyfg的专栏
07-18 6474
背景android模拟器运行于virtualbox中，而virtualbox运行于x86架构的pc端，所以android及其Linux内核都编译成x86架构。当virtualbox的vt未开启的情况下android系统会出现各种问题，如arm库游戏不能运行，桌面平凡挂死重启。通过查看日志，都奔溃在了#00 pc 000183c6 /system/lib/libc.so (__get_thread
Linux下基本栈溢出攻击
01-30
下面首先了解一下现有的用于保护堆栈的机制以及关闭相应保护机制的方法，为进一步分析基本栈溢出提供了良好的实验环境。在Ubuntu和其他基于Linux内核的系统中，目前都采用内存地址随机化的机制来初始化堆栈，这将会...
基于Linux的栈溢出攻击防护系统.pdf
09-07
本文档主要介绍了一种基于Linux的栈溢出攻击防护系统，该系统可以有效地阻止栈溢出攻击，保护Linux系统免受恶意攻击或病毒的影响。 FuncFence系统是该防护系统的核心组件，可以提供高效的安全机制，避免程序在防止...
64位Linux下的栈溢出
10-05
0x01 x86和x86_64的区别 0x02 漏洞代码片段 0x03 触发溢出 0x04 控制RIP 0x05 跳入用户控制的缓冲区 0x06 执行shellcode 0x07 GDB vs 现实 0x08 结语
栈溢出攻击技术
03-13
缓冲区溢出攻击技术－栈溢出攻击技术。网络安全相关。
linux程序的常用保护机制
weixin_42072280的博客
12-11 2796
linux NX PIE windows DEP ASLR NX：-z execstack/-z noexecstack(关闭 / 开启) Canary：-fno-stack-protector/-fstack-protector/-fstack-protector-all(关闭 / 开启 / 全开启) P...
栈溢出保护测试（非GS保护机制）
weixin_30817749的博客
03-26 146
今天做了一个栈溢出实验，主要目的是弹出一个对话框。还是用老办法，利用strcpy拷贝字符串时的漏洞，输入较长的字符串产生溢出，覆盖返回地址，从而劫持进程。 产生对话框部分字符串的是：33DB5368 7765737468 6661696C68 6661696C8BC453505053B8 71EAD677FFD0 对应汇编是： 33DB xor ebx...
GCC栈溢出保护
weixin_30794851的博客
10-28 298
逆向过elf程序都知道，GCC的canary，x86_64下从fs:0x28偏移处获取，32位下从gs:0x14偏移处获取。但知道canary如何产生，为什么在这里取的人比较少。下面以x86_64平台为例，通过glibc源码分析一下。看第一个问题：为什么从%fs:0x28处取。%fs寄存器被glibc定义为存放tls信息，查看tls结构：typedef struct{ void *t...
CTF使人变傻——3
最新发布
tas的博客
03-30 137
more。
Linux日志保护机制,解读Linux安全机制之栈溢出保护
weixin_42407606的博客
05-06 1282
解读Linux安全机制之栈溢出保护0x00 概述栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。当启用栈保护后，函数开始执行的时候会先往栈里插入cookie信息，当函数真正返回的时候会验证cookie信息是否合法，如果不合法就停止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护...
linux 内核裁剪不当 死机,Linux編譯x86架構內核出現_stack_chk_guard未定義錯誤
weixin_39755853的博客
05-02 349
背景android模擬器運行於virtualbox中，而virtualbox運行於x86架構的pc端，所以android及其Linux內核都編譯成x86架構。當virtualbox的vt未開啟的情況下android系統會出現各種問題，如arm庫游戲不能運行，桌面平凡掛死重啟。通過查看日志，都奔潰在了#00 pc 000183c6 /system/lib/libc.so (__get_thread+...
mips-openwrt交叉编译 undefined reference to `__stack_chk_guard 错误
热门推荐
好记性不如赖笔头
12-02 1万+
最近在mips-openwrt的工具链中交叉编译可执行程序时，出现了以下的错误：     undefined reference to `__stack_chk_guard'     undefined reference to `__stack_chk_fail'     百度一下，得知这个错误的引起是因为启用了Stack Guard堆栈保护，什么是堆栈保护呢？如下：
【ARM Linux 系统稳定性分析入门及渐进 3 -- 栈溢出】
CodingCos的博客
12-01 1221
是一块分配在栈之下的一块内存空间（假设栈stack是向下生长的），如图 2 所示，这样当栈 stack下溢时，就能在保护区留下痕迹 trace。，当子函数调用过程中，并不会去改变这些值的时候，就不需要压栈，说白了，压栈的目的就是为了在使用完的时候能恢复原来的状态。每个进程都会有自己的栈空间，而进程中的各个函数也会维护自己本身的一个栈的区域，这个区域就是。一般栈向下生长，即从高地址到低地址，如果栈空间不足，发生下溢，则栈之下的内存空间被写入。把栈空间填充成固定的值可以检测栈空间的下溢，如在程序开始前填充。
多线程运行递归函数导致堆栈溢出的问题
dave_hu的专栏
09-11 2708
目前linux mips 项目，中有DLNA server 在发现有U disk 插入时，创建一个新线程build mata data list，这其中会采用递归函数；而这时如果这时WMP 12 刷新媒体库，会在老线程（主线程）中进行 search / browse mata data list 的动作，这其中也采用了递归函数，为了省事啊 ，往往会造成进程crash。 因而涉及的内容
二进制漏洞挖掘-栈溢出-开启RELRO1
08-04
"本文档主要探讨了二进制漏洞挖掘中的栈溢出问题，特别是在Linux环境下。文章介绍了栈溢出的原理、测试环境以及开启RELRO（Read-Only Relocation）技术来增强二进制安全性的方法。" 在二进制漏洞挖掘中，栈溢出是一...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值