在编写漏洞利用代码的时候，需要特别注意目标进程是否开启了NX、PIE等机制，例如存在NX的话就不能直接执行栈上的数据，存在PIE 的话各个系统调用的地址就是随机化的。

一：canary(栈保护)

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

gcc在4.2版本中添加了-fstack-protector和-fstack-protector-all编译参数以支持栈保护功能，

因此在编译时可以控制是否开启栈保护以及程度，例如：

1、gcc -o test test.c  // 默认情况下，不开启Canary保护

2、gcc-fno-stack-protector -o test test.c //禁用栈保护

3、gcc -fstack-protector -o test test.c //启用堆栈保护，不过只为局部变量中含有 char 数组的函数插入保护代码

4、gcc-fstack-protector-all -o test test.c //启用堆栈保护，为所有函数插入保护代码

二：NX(no execute)

NX即No-eXecute(不可执行)的意思，NX(DEP)的基本原理是将数据所在内存页标识为不可执行，当程序溢出成功转入shellcode时，程序会尝试在数据页面上执行指令，此时CPU就会抛出异常，而不是去执行恶意指令。

gcc编译器默认开启了NX选项，如果需要关闭NX选项，可以给gcc编译器添加-z execstack参数。 例如：

1、gcc -o test test.c // 默认情况下，开启NX保护

2、gcc -z execstack -o test test.c // 禁用NX保护

3、gcc -z noexecstack -o test test.c // 开启NX保护

在Windows下，类似的概念为DEP(数据执行保护)

三：PIE(position-independent executables)

位置独立的可执行区域。这样使得在利用缓冲溢出和移动操作系统中存在的其他内存崩溃缺陷时采用面向返回的编程(return-oriented programming)方法变得难得多。一般情况下NX(Windows平台上称其为DEP)和地址空间分布随机化(ASLR)会同时工作。内存地址随机化机制(address space layout randomization)，有以下三种情况：

0 - 表示关闭进程地址空间随机化。

1 - 表示将mmap的基址，stack和vdso页面随机化。

2 - 表示在1的基础上增加栈(heap)的随机化。

liunx下关闭PIE的命令如下：

sudo -s echo 0 > /proc/sys/kernel/randomize_va_space

gcc编译命令：

1、gcc -o test test.c // 默认情况下，不开启PIE

2、gcc -fpie -pie -o test test.c // 开启PIE，此时强度为1

3、gcc -fPIE -pie -o test test.c // 开启PIE，此时为最高强度2

4、gcc -fpic -o test test.c // 开启PIC，此时强度为1，不会开启PIE

5、gcc -fPIC -o test test.c // 开启PIC，此时为最高强度2，不会开启PIE

四：RELRO(read only relocation)

在Linux系统安全领域，数据可以写的存储区就会是攻击的目标，尤其是存储函数指针的区域。 所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处。GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术:。大概实现就是由linker指定binary的一块经过dynamic linker处理过 relocation之后的区域为只读.设置符号重定向表格为只读或在程序启动时就解析并绑定所有动态符号，从而减少对GOT(Global Offset Table)攻击。RELRO为” Partial RELRO”，说明我们对GOT表具有写权限。

gcc编译：

gcc -o test test.c // 默认情况下，是Partial RELRO

gcc -z norelro -o test test.c // 关闭，即No RELRO

gcc -z lazy -o test test.c // 部分开启，即Partial RELRO

gcc -z now -o test test.c // 全部开启

五 总结

各种安全选择的编译参数如下：

NX：-z execstack / -z noexecstack (关闭 / 开启)

Canary：-fno-stack-protector /-fstack-protector / -fstack-protector-all (关闭 / 开启 / 全开启)

PIE：-no-pie / -pie (关闭 / 开启)

RELRO：-z norelro / -z lazy / -z now (关闭 / 部分开启 / 完全开启)

参考资料：

我正在尝试使用带有strcpy的经典溢出使用此函数重新创建堆栈缓冲区溢出：

#include

#include

void main(int argc, char **argv) {

char buf[100];

strcpy(buf,argv[1]);

printf("Done!\n");

}

我已经尝试使用所有各种标志进行编译,以便删除堆栈保护gcc -o vuln vuln.c -fno-stack-protector -g -z execstack以及使用sudo echo 0>删除ASLR.的/ proc / SYS /内核/ randomize_va_space.

我可以让我的nop-shellcode-address覆盖保存的EIP,但它会在RET上崩溃.我想通过HANDLE SIGSEGV忽略等来禁用gdb中的SIGSEGV,但是在GDB外运行我继续得到Segmentation Fault,无论我在哪里设置返回地址.

除了获得旧版gcc之外的任何想法？目前使用gcc版本6.1.1.

解决方法:

Linux遵循W^X原则：它将内存页标记为不可执行,除非它们是代码部分的一部分.这超出了编译应用程序的范围,并且有充分的理由.操作系统承担此责任,以防止系统上执行的任何程序的缓冲区溢出攻击;尤其是那些主动尝试执行缓冲区溢出攻击的程序,就像你的程序一样.

您正尝试通过buf在堆栈上编写代码并覆盖函数的返回地址以将执行跳转到新注入的代码中.当函数返回时,程序计数器被设置为重写的返回地址,现在指向堆栈内存.由于堆栈内存页面上的已撤销执行权限,程序计数器尝试执行下一条指令时抛出SIGSEGV.

要从堆栈执行,必须禁用OS堆栈保护.

幸运的是,Linux提供了execstack用于由用户自行决定使用的这种情况.

见this Unix& Linux Stack Exchange发布更多一般信息.

调试注入数据

如果您在gdb中获得SIGSEGV,则可能意味着缓冲区溢出尝试中存在一些错误.为了避免在main结束时搞乱清理,我建议你创建一个从main调用的函数来执行缓冲区溢出：

#include

#include

char injection_code[] = ""; // buffer overrun data here

void foo () {

char buf[100];

// memcpy used to copy the full injection string, including any nested 0s

memcpy(buf, injection_code, 108); // +8 here to handle 64-bit system RAs

}

int main (int argc, char** argv) {

foo();

printf("Done!\n");

return 0;

}

使用GDB进行调试.我建议在foo结尾处设置一个断点,并检查寄存器是否符合您对信息寄存器的期望.您可能最感兴趣的是指令指针,您可以使用信息寄存器rip(64位)或info寄存器eip(32位)进行检查.

您可以通过在GDB中使用print或x/x来探索堆栈的外观.例如,您可以检查$rbp 8以查看堆栈上的返回地址(RA).

如果RA指向无效位置,GDB将对ret指令进行SIGSEGV：

Program received signal SIGSEGV, Segmentation fault.

0x00000000004005bc in foo () at bufferoverflow.c:27

您可以通过检查故障时的指令指针地址(在上面的例子中,它将是0x00000000004005bc)对程序的程序集(在GDB中使用disassemble function_name)来检查它是否在ret指令上出现故障.

如果返回地址指向堆栈中,它可能会抛出一个非法指令的SIGILL,这意味着您的返回地址可能无法正确对齐,或者您注入的指令格式不正确：

Program received signal SIGILL, Illegal instruction.

0x00007fffffffdc13 in ?? ()

同样,您可以使用GDB来探索堆栈以了解原因.

GDB对于使缓冲区溢出的结构正确非常有用.

但是,一旦按预期工作,请记住在GDB外部执行时可能会移位内存地址,尤其是在没有调试标志(-g)的情况下进行编译时.您将不得不稍微使用返回地址,以便在“实时”环境中将其放置到您想要的位置.

一个旁白

通常,直接运行注入代码的缓冲区溢出攻击通常不适用于当今的堆栈保护机制.通常需要存在额外的漏洞才能执行任意代码.

标签：c-3,buffer-overflow,linux,gcc,stack-overflow

来源： https://codeday.me/bug/20190828/1755935.html

8种机械键盘轴体对比

本人程序员，要买一个写代码的键盘，请问红轴和茶轴怎么选？

由于内核栈的大小是有限的，就会有发生溢出的可能，比如调用嵌套太多、参数太多都会导致内核栈的使用超出设定的大小。本文分析内核栈溢出。

Linux 系统进程运行分为 用户态 和 内核态，进入内核态之后使用的是内核栈，作为基本的安全机制，用户程序不能直接访问内核栈，所以尽管内核栈属于进程的地址空间，但与用户栈是分开的。内核栈需要方便快捷的访问用户态进程信息 thread_info，这部分数据就压在内核栈的底部，大小默认为 16Kb。如下图所示：

内核栈溢出的结果往往是系统崩溃，因为溢出会覆盖掉本不该触碰的数据，首当其冲的就是 thread_info — 它就在内核栈的底部，内核栈是从高地址往低地址生长的，一旦溢出首先就破坏了 thread_info，thread_info 里存放着指向进程的指针等关键数据，迟早会被访问到，那时系统崩溃就是必然的事。

内核栈溢出导致的系统崩溃有时会被直接报出来，比如你可能会看到：...

Call Trace:

[] ? warn_slowpath_common+0x87/0xc0

BUG: unable to handle kernel NULL pointer dereference at 00000000000009e8

IP: [] print_context_stack+0xad/0x140

PGD 5fdb8ae067 PUD 5fdbee9067 PMD 0

Thread overran stack, or stack corrupted

Oops: 0000 [#1] SMP

...

但更多的情况是不直接报错，而是各种奇怪的 panic。在分析 vmcore 的时候，它们的共同点是 thread_info 被破坏了。

以下是一个实例，注意在 task_struct 中 stack 字段直接指向内核栈底部也就是 thread_info 的位置，我们看到 thread_info 显然被破坏了：cpu 的值大得离谱，而且指向 task 的指针与 task_struct 的实际地址不匹配：crash64> struct task_struct ffff8800374cb540

struct task_struct {

state = 2,

stack = 0xffff8800bae2a000,

...

crash64> thread_info 0xffff8800bae2a000

struct thread_info {

task = 0xffff8800458efba0,

exec_domain = 0xffffffff,

flags = 0,

status = 0,

cpu = 91904,

preempt_count = 0,

...

作为一种分析故障的手段，可以监控内核栈的大小和深度，方法如下：# mount -t debugfs nodev /sys/kernel/debug

# echo 1 > /proc/sys/kernel/stack_tracer_enabled

然后检查下列数值，可以看到迄今为止内核栈使用的峰值和对应的 backtrace：# cat /sys/kernel/debug/tracing/stack_max_size

# cat /sys/kernel/debug/tracing/stack_trace