linux程序的常用保护机制

linux程序的常用保护机制

来源 https://www.cnblogs.com/Spider-spiders/p/8798628.html

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

一、checksec

checksec是一个脚本软件，也就是用脚本写的一个文件，不到2000行，可用来学习shell。

源码参见

http://www.trapkit.de/tools/checksec.html

https://github.com/slimm609/checksec.sh/

下载方法之一为

wget https://github.com/slimm609/checksec.sh/archive/1.6.tar.gz

checksec到底是用来干什么的？

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

checksec的使用方法： 

checksec –file /usr/sbin/sshd 

一般来说，如果是学习二进制漏洞利用的朋友，建议大家使用gdb里peda插件里自带的checksec功能，如下：

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

二、CANNARY(栈保护)

这个选项表示栈保护功能有没有开启。

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

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

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


1

2

3

4


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 //启用堆栈保护，为所有函数插入保护代码

三、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 <string.h>)

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

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


1

2

3

4

5

6


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编译


1

2

3

4

5

6

7

8

9

10

11

12

13


08048450 <fun>:

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 <[email protected]>

leave ;

ret

用包含参数-D_FORTIFY_SOURCE=2编译


1

2

3

4

5

6

7

8

9

10

11

12

13

14


08048470 <fun>:

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 <[email protected]>

leave ;

ret

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

总结下就有:


1

2

3


gcc -o test test.c // 默认情况下，不会开这个检查

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

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

四、NX（DEP）

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

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


1

2

3


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（ASLR）

一般情况下NX（Windows平台上称其为DEP）和地址空间分布随机化（ASLR）会同时工作。

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


1

2

3


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

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

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

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

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

liunx下关闭PIE的命令如下：


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

gcc编译命令


1

2

3

4

5


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

说明：

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

gcc中的-fpic选项，使用于在目标机支持时，编译共享库时使用。编译出的代码将通过全局偏移表(Global Offset Table)中的常数地址访存，动态装载器将在程序开始执行时解析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

在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编译：


1

2

3

4


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 (关闭 / 部分开启 / 完全开启)

参考链接：上善若水

原文地址：https://www.cnblogs.com/lsgxeva/p/11697612.html

时间： 2024-10-14 20:59:21

linux程序的常用保护机制的相关文章

linux程序调试常用命令

1 调用跟踪     跟踪系统调用 strace ls –l     跟踪库调用  ltrace 2 lsof(list open file)     查看程序命令打开了哪些文件  lsof –p PID; lsof –c CMD     查看某个用户打开的文件  lsof –u root     查看某个文件被哪个程序访问 lsof filename 3 proc文件系统     虚拟文件系统,可以使用cat,more,less查看     例如:cat /proc/cpuinfo;    c

Linux中的保护机制

Linux中的保护机制 在编写漏洞利用代码的时候,需要特别注意目标进程是否开启了NX.PIE等机制,例如存在NX的话就不能直接执行栈上的数据,存在PIE 的话各个系统调用的地址就是随机化的. 一:canary(栈保护) 栈溢出保护是一种缓冲区溢出攻击缓解手段,当函数存在缓冲区溢出攻击漏洞时,攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行.当启用栈保护后,函数开始执行的时候会先往栈里插入cookie信息,当函数真正返回的时候会验证cookie信息是否合法,如果不合法就停止程序运行.

Linux的分段和分页机制

1 基于80x86的Linux分段机制 80386的两种工作模式:80386的工作模式包括实地址模式和虚地址模式(保护模式).Linux主要工作在保护模式下. 在保护模式下,80386虚地址空间可达16K个段,每段大小可变,最大达4GB.逻辑地址到线性地址的转换由80386分段机制管理.段寄存器CS.DS.ES.SS.FS或GS各标识一个段.这些段寄存器作为段选择器,用来选择该段的描述符. 分段逻辑地址到线性地址转换图: Linux对80386的分段机制使用得很有限,因为Linux的设计目标是支

Linux的mmap内存映射机制解析

在讲述文件映射的概念时,不可避免的要牵涉到虚存(SVR 4的VM).实际上,文件映射是虚存的中心概念, 文件映射一方面给用户提供了一组措施,好似用户将文件映射到自己地址空间的某个部分,使用简单的内存访问指令读写文件:另一方面,它也可以用于内核的基本组织模式,在这种模式种,内核将整个地址空间视为诸如文件之类的一组不同对象的映射.中的传统文件访问方式是,首先用open系统调用打开文件,然后使用read, write以及lseek等调用进行顺序或者随即的I/O.这种方式是非常低效的,每一次I/O操作都

Linux之grub的运行机制及grub修复

理论区: GNU GRUB(GRand Unified Bootloader简称"GRUB")是一个来自GNU项目的多操作系统启动程序.GRUB是多启动规范的实现,它允许用户可以在计算机内同时拥有多个操作系统,并在计算机启动时选择希望运行的操作系统.GRUB可用于选择操作系统分区上的不同内核,也可用于向这些内核传递启动参数. 位于磁盘的0磁头(盘面),0磁道,1扇区位置,该位置共计有512Byte,至于前446个字节是grub. 目前,grub现有两个版本,0.x系列被称为是grub1

Linux内存寻址之分段机制

http://blog.xiaohansong.com/2015/10/03/Linux内存寻址之分段机制/ .段的起始地址.段的长度等等,而在保护模式下则复杂一些.IA32将它们结合在一起用一个8字节的数表示,称为描述符 .IA32的一个通用的段描述符的结构从图可以看出,一个段描述符指出了段的32位基地址和20位段界限(即段长).这里我们只关注基地址和段界限,其他的属性略过. 段描述符表 各种各样的用户描述符和系统描述符,都放在对应的全局描述符表.局部描述符表和中断描述符表中.描述符表(即段表

Linux程序包管理总结

Linux程序包管理 相比于Windows系统,Linux的程序包的管理就没有那么简单了,当然在Linux系统中也有像Windows系统中EXE或者MSI安装包一样的安装包文件,可以直接实现进行程序包安装,但即是这样的程序包的安装也要比Windows复杂多了,当然,大家不要被我这两句话给唬到了,当你学过这课后,你会发现Linux的程序包管理其实也很简单的,同样你也会发现Linux的程序包管理比Windows的好玩儿多了. Linux中的程序包格式: .deb  源于debian系统的安装包格式

linux程序分析工具介绍(二)—-ldd,nm

本文要介绍的ldd和nm是linux下,两个用来分析程序很实用的工具.ldd是用来分析程序运行时需要依赖的动态库的工具:nm是用来查看指定程序中的符号表相关内容的工具.下面通过例子,分别来介绍一下这两个工具: 1. ldd, 先看下面的例子, 用ldd查看cs程序所依赖的动态库: [email protected]:~/Public$ ldd cs linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0xb7f8c000)

Linux程序包管理之rpm包管理

Linux程序包管理 软件包管理 功能:将编译好的程序的各组成文件打包成一个或几个程序包文件,为了方便的实现程序包的安装.升级.卸载.查询.校验.数据库维护. API:Application ProgramInterface应用程序接口: ABI:Application BinaryInterface应用二进制接口: Unix-like和linux在ABI层次是相同的 linux程序包:ELF格式: 但是与Windows相差甚远 windows程序包:exe,msi格式: API层次兼容不一定A