checksec介绍

使用截图：

checksec源代码分析

Checksec是一个bash脚本，用于检查可执行文件的属性（例如PIE，RELRO，PaX，Canaries，ASLR，Fortify Source）。

通过阅读源码可以知道，脚本只要调用了readelf来检测二进制文件的特征；所以执行环境中要可以执行readelf，不然会报错。

然后再者bin包不是elf文件，需要解包之后，对解开的二进制文件进行扫描。

结果相关说明：

RELRO

表示对是否有对数据区域的读写进行限制。

在Linux系统安全领域数据可以写的存储区就会是攻击的目标，尤其是存储函数指针的区域。所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处.

GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术: read only relocation。大概实现就是由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                                // 全部开启，即Full RELRO

STACK CANARY

表示栈保护功能有没有开启。

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

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

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


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

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

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

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

表示是否对内存有进行保护。

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

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

例如：


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

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

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

在Windows下，类似的概念为DEP（数据执行保护），在最新版的Visual Studio中默认开启了DEP编译选项。

PIE

表示虚地址

一般情况下NX（Windows平台上称其为DEP）和地址空间分布随机化（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                        // 默认情况下，不开启PIE

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

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

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

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

RPATH/RUNPATH

程序运行时的环境变量，运行时所需要的共享库文件优先从该目录寻找，可以fake lib造成攻击。

Linux Privilege Escalation via Dynamically Linked Shared Object Library | Context Information Security

新增：

FORTIFY

用于检查是否存在缓冲区溢出的错误。适用情形是程序采用大量的字符串或者内存操作函数，如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 <string.h>)

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



gcc -D_FORTIFY_SOURCE=1 -o test test.c                // 较弱的检查

gcc -D_FORTIFY_SOURCE=2 -o test test.c                // 较强的检查

参考：

checksec及其包含的保护机制 | YungGong

PWN-最新checksec的安装和使用_GitCloud的博客-CSDN博客_checksec