mmap及linux地址空间随机化失效漏洞
mmap及linux地址空间随机化失效漏洞
Linux下动态库是通过mmap建立起内存和文件的映射关系。其定义如下void* mmap(void* start,size_t length,int prot,int flags,int fd,off_t offset);，在第一个参数start为NULL的时候系统会随机分配一个地址，我们可以通过示例来看mmap映射地址的流程。
分析一下程序加载libc.so的流程
open（“/ lib / libc.so.6 ”，O_RDONLY）= 3
读取（3，“\ 177ELF \ 1 \ 1 \ 1 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 3 \ 0 \ 3 \ 0 \ 1 \ 0 \ 0 \ 0 n \ 1 \ 0004 \ 0 \ 0 \ 0“ ...，512）= 512
fstat64（3，{st_mode = S_IFREG | 0755，st_size = 1409436，...}）= 0
mmap2（NULL，1415560，PROT_READ | PROT_EXEC，MAP_PRIVATE | MAP_DENYWRITE，3,0）= 0xb75b1000
mmap2（0xb7705000,12288，PROT_READ | PROT_WRITE，MAP_PRIVATE | MAP_FIXED | MAP_DENYWRITE，3,0x154）= 0xb7705000
mmap2（0xb7708000,10632，PROT_READ | PROT_WRITE，MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS，-1,0）= 0xb7708000
接近（3）在通常情况下通过mmap映射的地址会被内核进行随机化处理，所以每次程序运行加载的动态库基址都不相同。
〜$ ldd mmap
linux-gate.so.1 =>（0xb77d9000）
libc.so.6 => /lib/libc.so.6(0xb7654000）
/lib/ld-linux.so.2(0xb77bd000）
〜$ ldd mmap
linux-gate.so.1 =>（0xb7738000）
libc.so.6 => /lib/libc.so.6(0xb75b3000）
/lib/ld-linux.so.2(0xb771c0000x01 CVE-2016-3672
Linux kernel 4.5.2之前版本，arch/x86/mm/mmap.c内函数arch_pick_mmap_layout未正确随机化遗留基址。本地用户禁用栈资源消耗限制后，可破坏ADDR_NO_RANDOMIZE标记的限制，绕过setuid或setgid程序的ASLR保护机制。
这个漏洞在32位操作系统或者在64位操作系统运行32位程序时，将栈空间设置为不限制，会导致mmap的ASLR失效，导致动态库加载的地址固定。
验证方法:
- 设置栈空间为不限制大小
ulimit -s unlimited - 使用ldd看动态库加载的地址是否发生变化
〜$ ldd mmap
linux-gate.so.1 =>（0xb77d9000）
libc.so.6 => /lib/libc.so.6(0xb7654000）
/lib/ld-linux.so.2(0xb77bd000）
〜$ ldd mmap
linux-gate.so.1 =>（0xb7738000）
libc.so.6 => /lib/libc.so.6(0xb75b3000）
/lib/ld-linux.so.2(0xb771c000）
〜$ ulimit -s无限制
〜$ ldd mmap
linux-gate.so.1 =>（0x4001c000）
libc.so.6 => /lib/libc.so.6(0x4002e000）
/lib/ld-linux.so.2(0x40000000）
〜$ ldd mmap
linux-gate.so.1 =>（0x4001c000）
libc.so.6 => /lib/libc.so.6(0x4002e000）
/lib/ld-linux.so.2(0x40000000）可见，设置了栈空间不限制大小后，动态库的基址就固定了。
0x02 漏洞分析
漏洞所在函数为arch_pick_mmap_layout
/ *
*这个功能，在创建新功能的过程中非常早
*处理VM映像，设置要使用的VM布局功能：
* /
void arch_pick_mmap_layout （struct mm_struct * mm）
{
mm-> mmap_legacy_base = mmap_legacy_base（）;
mm-> mmap_base = mmap_base（）;
if（mmap_is_legacy（））{
mm-> mmap_base = mm-> mmap_legacy_base;
mm-> get_unmapped_area = arch_get_unmapped_area;
} else {
mm-> get_unmapped_area = arch_get_unmapped_area_topdown;
}
}如果让ASLR失效则需要让mm->mmap_base为固定值。看看mmap_legacy_base
/ *
* X86_32上的自下而上（传统）布局不支持随机化，X86_64
*但是在模拟X86_32时没有
* /
static unsigned long mmap_legacy_base （void）
{
if（mmap_is_ia32（））
返回 TASK_UNMAPPED_BASE;
其他
返回 TASK_UNMAPPED_BASE + mmap_rnd（）;
}可以看到mmap_is_ia32()为真时，返回的地址为固定值。注释更表明了影响32位机器和在64位机器上运行的32位程序。此时，只需要mmap_is_legacy()为真。
/ *
* mmap区域的顶部（就在进程堆栈下方）。
*
*留下至少~128 MB的空洞，可能有堆栈随机化。
* /
＃限定 MIN_GAP（128 * 1024 * 1024UL + stack_maxrandom_size（））
＃限定 MAX_GAP（TASK_SIZE / 6 * 5）
static int mmap_is_legacy （void）
{
if（current-> personality＆ADDR_COMPAT_LAYOUT）
返回 1 ;
if（rlimit（RLIMIT_STACK）== RLIM_INFINITY）
返回 1 ;
return sysctl_legacy_va_layout;
}注意到rlimit(RLIMIT_STACK) == RLIM_INFINITY则返回真，这就是ulimit -s unlimited的原因。
0x03 修复方案分析
diff --git a / arch / x86 / mm / mmap.cb / arch / x86 / mm / mmap.c
index 96bd1e2..389939f 100644
--- a / arch / x86 / mm / mmap.c
+++ b / arch / x86 / mm / mmap.c
@@ -94,18 +94,6 @@ static unsigned long mmap_base（unsigned long rnd）
}
/ *
- * X86_32上的自下而上（传统）布局不支持随机化，X86_64
- *确实如此，但在模拟X86_32时却没有
- * /
-static unsigned long mmap_legacy_base（unsigned long rnd）
- {
- if（mmap_is_ia32（））
- 返回TASK_UNMAPPED_BASE;
- 否则
- 返回TASK_UNMAPPED_BASE + rnd;
- }
-
- / *
*这个功能，在创建新功能的过程中非常早
*处理VM映像，设置要使用的VM布局功能：
* /
@@ -116,7 +104,7 @@ void arch_pick_mmap_layout（struct mm_struct * mm）
if（current-> flags＆PF_RANDOMIZE）
random_factor = arch_mmap_rnd（）;
- mm-> mmap_legacy_base = mmap_legacy_base（random_factor）;
+ mm-> mmap_legacy_base = TASK_UNMAPPED_BASE + random_factor;
if（mmap_is_legacy（））{
mm-> mmap_base = mm-> mmap_legacy_base;很简单，不管是以lagacy模式运行还是真正的32位程序，mmap的基址mmap_base均加入随即因子进行随机化
0x04 题外
在64位机器上发现也存在ASLR失效的问题，不过vDSO还是有随机化保护的。留个坑有时间在看看。
0x05 Refer
http://rk700.github.io/2016/11/22/mmap-aslr/ http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2016-April/023114.html http://hmarco.org/bugs/CVE-2016-3672-Unlimiting-the-stack-not-longer-disables-ASLR.html