从以下选项中选出gcc编译器的正确流程_Pwn基础（二）：checksec 中常见保护机制...-CSDN博客

操作系统提供了许多安全机制来尝试降低或阻止缓冲区溢出攻击带来的安全风险，包括DEP、ASLR等。在编写漏洞利用代码的时候，需要特别注意目标进程是否开启了DEP(Linux下对应NX)、ASLR(Linux下对应PIE)等机制，例如存在DEP(NX)的话就不能直接执行栈上的数据，存在ASLR的话各个系统调用的地址就是随机化的。

checksec 它是用来检查可执行文件属性，例如 PIE, RELRO, PaX, Canaries, ASLR, Fortify Source 等属性。

工具下载链接：https://github.com/slimm609/checksec.sh/

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

Canary：-fno-stack-protector /-fstack-protector / -fstack-protector-all (关闭 / 开启 / 全开启)
NX：-z execstack / -z noexecstack (关闭 / 开启)
PIE：-no-pie / -pie (关闭 / 开启)
RELRO：-z norelro / -z lazy / -z now (关闭 / 部分开启 / 完全开启)

下面我们就图中各个保护机制进行一个大致的了解。

Canary

Canary 的意思是金丝雀，来源于英国矿井工人用来探查井下气体是否有毒的金丝雀笼子。工人们每次下井都会带上一只金丝雀。如果井下的气体有毒，金丝雀由于对毒性敏感就会停止鸣叫甚至死亡，从而使工人们得到预警。

我们知道，通常栈溢出的利用方式是通过溢出存在于栈上的局部变量，从而让多出来的数据覆盖 ebp、eip 等，从而达到劫持控制流的目的。栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让 shellcode 能够得到执行。当启用栈保护后，函数开始执行的时候会先往栈底插入 cookie 信息，当函数真正返回的时候会验证 cookie 信息是否合法(栈帧销毁前测试该值是否被改变)，如果不合法就停止程序运行(栈溢出发生)。攻击者在覆盖返回地址的时候往往也会将 cookie 信息给覆盖掉，导致栈保护检查失败而阻止 shellcode 的执行，避免漏洞利用成功。在 Linux 中我们将 cookie 信息称为 Canary。

NX

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

分析缓冲区溢出攻击，其根源在于现代计算机对数据和代码没有明确区分这一先天缺陷，就目前来看重新去设计计算机体系结构基本上是不可能的，我们只能靠向前兼容的修补来减少溢出带来的损害，DEP 就是用来弥补计算机对数据和代码混淆这一天然缺陷的。

DEP 的基本原理是将数据所在内存页标识为不可执行，当程序溢出成功转入 shellcode 时，程序会尝试在数据页面上执行指令，此时 CPU 就会抛出异常，而不是去执行恶意指令。DEP 的主要作用是阻止数据页(如默认的堆页、各种堆栈页以及内存池页)执行代码。硬件 DEP 需要 CPU 的支持，AMD 和 Intel 都为此做了设计，AMD 称之为 No-Execute Page-Protection(NX)，Intel 称之为 Execute Disable Bit(XD)，Linux 称为 NX，与 DEP 原理相同。

工作原理图如下图所示：

PIE

PIE 即 Position Independent Executables，位置无关的可执行文件，也就是常说的 ASLR(Address space layout randomization) 地址随机化，程序每次启动基址都随机。

但 PIE 和 ASLR 作用却有所区别，ASLR 是系统功能选项，PIE 是编译器功能选项。ASLR 只能对堆、栈和 mmap 随机化，而不能对代码段，数据段随机化，使用PIE+ASLR 则可以对代码段和数据段随机化。

内存地址随机化机制(address space layout randomization)，有以下三种情况：

0 - 表示关闭进程地址空间随机化。1 - 表示将mmap的基址，stack和vdso页面随机化。2 - 表示在1的基础上增加栈(heap)的随机化。

可以防范基于 Ret2libc 方式的针对 DEP 的攻击。ASLR 和 DEP 配合使用，能有效阻止攻击者在堆栈上运行恶意代码。

Built as PIE：位置独立的可执行区域(position-independent executables)。这样使得在利用缓冲溢出和移动操作系统中存在的其他内存崩溃缺陷时采用面向返回的编程(return-oriented programming)方法变得难得多。

liunx下关闭PIE的命令如下：

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

gcc编译命令

gcc -o test test.c              // 默认情况下，不开启PIEgcc -fpie -pie -o test test.c       // 开启PIE，此时强度为1gcc -fPIE -pie -o test test.c       // 开启PIE，此时为最高强度2gcc -fpic -o test test.c        // 开启PIC，此时强度为1，不会开启PIEgcc -fPIC -o test test.c        // 开启PIC，此时为最高强度2，不会开启PIE

PIE最早由 RedHat 的人实现，它在链接上增加了-pie 选项，这样使用 -fPIE 编译的对象就能通过连接器得到位置无关可执行程序。fPIE 和 fPIC 有些不同。

PIC 是 Position-Independent Code 的缩写。在计算机系统中，PIC 和 PIE(Position-Independent Executable) 是可以在主存中不同位置执行的目标代码。PIC 经常被用在共享库中，这样就能将相同的库代码为每个程序映射到一个位置，不用担心覆盖掉其他程序或共享库。

要想实现位置无关，代码必须通过特定的方式编写、编译才行。比如对于固定地址的绝对跳转指令，就需要使用相对应的相对跳转指令代替，相对位置的计算通过对指令计数器的计算得到。在某些特定的体系结构上(如 AMD64),共享库就必须支持 PIC。

另外位置独立还需要与重分配(reallocate)区分，后者是指在计算机中将符号因引用或者库的名字用主存中的可用地址代替。虽然能在运行时通过装载器(loader)完成，但通常是在编译阶段由连接器(linker)完成。编译器或者汇编器通常会生成从 0 位置开始的可执行代码，在代码运行之前，这些相对地址将修改为正确的运行时地址。

通常 congfigure 能够检测出编译器是否支持 -fPIC，是通过编译一个小程序，并且检查stderr输出实现的。若此时编译器输出了任何的警告，就视为不支持。此时如果用户在 CFLAGS 或者 CXXFLAGS 中指定了一个错误的 flag，那编译任何程序都会出警告，于是就会被判为 -fPIC 不可用。

现在我们就可以考虑以下三种情况需要 -fPIC:

不需要动态链接库的可执行程序。因为通常可执行程序会被装载到固定的地址，并从此处开始运行，所以普通可执行程序不需要 -fPIC
静态链接库。它相当于一个大的 xxx.o 文件结合，又被称作可充分配对象。它们包含了一些可将它们在内存中改变位置的信息(使用重分配移动)，所以静态链接库也不需要 -fPIC
动态链接库。因为动态链接库就是为了实现位置无关，所以需要使用 -fPIC.

gcc中的 -fpic 选项，使用于在目标机支持时，编译共享库时使用。编译出的代码将通过全局偏移表(Global OffsetTable)中的常数地址访存，动态装载器将在程序开始执行时解析 GOT 表项(注意，动态装载器操作系统的一部分，链接器是 gcc 的一部分)。而 gcc 中的 -fPIC 选项则是针对某些特殊机型做了特殊处理，比如适合动态链接并能避免超出 GOT 大小限制之类的错误。而 Open64 仅仅支持不会导致 GOT 表溢出的 PIC 编译。

gcc 中的 -fpie 和 -fPIE 选项和 fpic 及 fPIC 很相似，但不同的是，除了生成为位置无关代码外，还能假定代码是属于本程序。通常这些选项会和 GCC 链接时的 -pie 选项一起使用。fPIE 选项仅能在编译可执行码时用，不能用于编译库。所以，如果想要 PIE 的程序，需要你除了在 gcc 增加 -fPIE 选项外，还需要在 ld 时增加 -pie 选项才能产生这种代码。即 gcc -fpie -pie 来编译程序。单独使用哪一个都无法达到效果。

RELRO

RELRO 即 Relocation Read Only，重定向只读，实现就是由 linker 指定 binary 的一块经过 dynamic linker 处理过 relocation 之后的区域为只读。

在 Linux 系统安全领域，数据可以写的存储区就会是攻击的目标，尤其是存储函数指针的区域，尽量减少可写的存储区域可使安全系数提高。GCC, GNU linker 以及 Glibc-dynamic linker 一起配合实现了一种叫做 RELRO 的技术 Relocation Read Only，重定向只读。设置符号重定向表格为只读或在程序启动时就解析并绑定所有动态符号，从而减少对 GOT(Global Offset Table)攻击。RELRO 如果为 Partial RELRO，说明我们对 GOT 表具有写权限。

FORTIFY

fority其实非常轻微的检查，用于检查是否存在缓冲区溢出的错误。适用情形是程序采用大量的字符串或者内存操作函数，如 memcpy, memset, stpcpy, strcpy, strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, gets 以及宽字符的变体。

_FORTIFY_SOURCE 设为 1，并且将编译器设置为优化 1(gcc -O1)，以及出现上述情形，那么程序编译时就会进行检查但又不会改变程序功能。

_FORTIFY_SOURCE 设为 2，有些检查功能会加入，但是这可能导致程序崩溃。

gcc -D_FORTIFY_SOURCE=1 仅仅只会在编译时进行检查 (特别像某些头文件 #include )

gcc -D_FORTIFY_SOURCE=2 程序执行时也会有检查 (如果检查到缓冲区溢出，就终止程序)

举个例子可能简单明了一些：一段简单的存在缓冲区溢出的 C 代码

void fun(char *s) {        char buf[0x100];        strcpy(buf, s);        /* Don't allow gcc to optimise away the buf */        asm volatile("" :: "m" (buf));}

用包含参数 -U_FORTIFY_SOURCE 编译

08048450 :  push   %ebp  mov    %esp,%ebp  sub    $0x118,%esp; 将0x118存储到栈上  mov    0x8(%ebp),%eax; 将目标参数载入eax  mov    %eax,0x4(%esp); 保存目标参数  lea    -0x108(%ebp),%eax; 数组buf  mov    %eax,(%esp); 保存  call   8048320 @plt>  leave  ret

用包含参数 -D_FORTIFY_SOURCE=2 编译

08048470 :  push   %ebp  mov    %esp,%ebp  sub    $0x118,%esp  movl   $0x100,0x8(%esp); 把0x100当作目标参数保存  mov    0x8(%ebp),%eax  mov    %eax,0x4(%esp)  lea    -0x108(%ebp),%eax  mov    %eax,(%esp)  call   8048370 <__strcpy_chk@plt>  leave  ret

我们可以看到 gcc 生成了一些附加代码，通过对数组大小的判断替换 strcpy, memcpy, memset 等函数名，达到防止缓冲区溢出的作用。

总结下就有:

gcc -o test test.c                          // 默认情况下，不会开这个检查gcc -D_FORTIFY_SOURCE=1 -o test test.c      // 较弱的检查gcc -D_FORTIFY_SOURCE=2 -o test test.c      // 较强的检查