CVE-2016-6187：利用堆大小差一错误爆破Linux内核

大小差一错误（off-by-one）介绍

▼

大小差一错误是一类常见的程序设计错误。这方面有一个经典的例子OpenSSH。去 Google 搜索关键词“OpenSSH off-by-one”可以了解相关状况。具体来说，

1. if(id < 0 || id >channels_alloc)...

2. if(id < 0 || id >=channels_alloc)...

第二句应该是正确的写法。举个更通俗的例子：

int a[5],i;

for(i = 1;i < = 5;i++)

   a[i]=0;

上述代码定义了长度为 5 的数组 a，循环的目的是给数组元素初始化，赋值为 0。但是，循环下标从 1 开始到 5，出现了 a[5]=0，这样的不存在的数组元素。这就是典型的“差一错误”(off-by-one)。

其实，貌似说栅栏柱错误(fencepost error)大家更熟悉。我问过身边的朋友，很多人知道这个问题。

如果你要建造一个100米长的栅栏，其栅栏柱间隔为10米，那么你需要多少根栅栏柱呢？

11 根或 9 根都是正确答案，这取决于是否要在栅栏的两端树立栅栏柱，但是 10 根却是错误的。我想起来了我高中是数学老师告诉我们的一个很容易犯错的数学题目。从周一到周五一共有几天？也许你立即反应5-1=4，但是，下意识你也会说五天。实际上应该是5-1+1=5。转换到数学，数字 1 到数字 5 一共有几个数字？这里有一个公式：

从 M 到 N，一共有 M-N+1 项。

这个问题写出来后很简单，只不过在写代码的时候，往往比较容易忽略。尤其在涉及到数组操作两端界限的时候，如果不是从 0 开始计数，就要稍微考虑一下咯。

前 言

▼

我认为我决定写关于本漏洞的理由是因为当我把它发在推特上时，我收到了一些私信说这个内核路径不是爆破点（找不到 bug 在哪）或者不可利用。另一个的理由就是我想在实际中尝试 userfaultfd() 的系统调用。我需要一个真实的 UAF 来试试。

首先，我不知道这个漏洞是否影响到在主要发行版本的任何 upstream 的内核。我只检查了 ubuntu 支线和 Yakkety 支线没有影响。但是，补丁包常常会出问题。Bug 在中有介绍，在中提交和修复。

因为我不能找到一个拥有爆破点的 ubuntu 内核版本，我在 ubuntu16.04（x86_64）上编译了4.5.1内核。虽然值得一提的是爆破点仅仅影响（像 ubuntu）默认使用AppArmor的发行版本。

Vulnerability（爆破点）

▼

写入 /proc/self/attr/current触发proc_pid_attr_write() 函数。接下来介绍的代码是爆破点前面的：

staticssize_t proc_pid_attr_write(struct file * file, const char __user * buf,

                                   size_tcount, loff_t *ppos)

{

        struct inode * inode =file_inode(file);

        char *page;

        ssize_t length;

        struct task_struct *task =get_proc_task(inode);

        length = -ESRCH;

        if (!task)

                goto out_no_task;

        if (count > PAGE_SIZE)                            [1]

                count = PAGE_SIZE;

        /* No partial writes. */

        length = -EINVAL;

        if (*ppos != 0)

                goto out;

        length = -ENOMEM;

        page =(char*)__get_free_page(GFP_TEMPORARY);    [2]

        if (!page)

                goto out;

        length = -EFAULT;

        if (copy_from_user(page, buf,count))             [3]

                goto out_free;

        /* Guard against adverse ptraceinteraction */

        length =mutex_lock_interruptible(&task-;>signal->cred_guard_mutex);

        if (length < 0)

                goto out_free;

        length = security_setprocattr(task,

                                     (char*)file->f_path.dentry->d_name.name,

                                     (void*)page, count);

...

buf 参数代表用户提供的缓冲区（和长度 count）被写入到 /proc/self/attr/current。在[1] 处，check 被执行以确保缓冲区会适应一个单页（默认 4096 个字节）。在 [2] 和[3]，一个单页被分配了并且用户空间缓冲区被复制到新分配的页。这个页传递给代表 LSM 钩子（AppArmour,SELinux,Smack）的 security_setprocattr。假如是 ubuntu，这个钩子触发了apparmor_setprocattr() 函数，代码显示如下：

在 [4] 处，如果用户提供的缓冲区最后的字节不为空并且缓冲区大小不等于页的大小时，缓冲区末端为空。在另一面，如果用户提供的缓冲区超过（或者等于）单页的大小（在 [2] 处分配的），路径被终止并且 -EINVAL 被返回。

接下来显示的代码改为在爆破点之后的（在 [3] 处的） proc_pid_attr_write()：

static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,

                                   size_t count, loff_t *ppos)

{

        struct inode * inode = file_inode(file);

        void *page;

        ssize_t length;

        struct task_struct *task = get_proc_task(inode);

        length = -ESRCH;

        if (!task)

                goto out_no_task;

        if (count > PAGE_SIZE)

                count = PAGE_SIZE;

        /* No partial writes. */

        length = -EINVAL;

        if (*ppos != 0)

                goto out;

        page = memdup_user(buf, count);                   [5]

        if (IS_ERR(page)) {

                length = PTR_ERR(page);

                goto out;

        }

        /* Guard against adverse ptrace interaction */

        length = mutex_lock_interruptible(&task-;>signal->cred_guard_mutex);

        if (length < 0)

                goto out_free;

        length = security_setprocattr(task,

                                      (char*)file->f_path.dentry->d_name.name,

                                      page, count);

...

不像 __get_free_page()，memdup_user() 分配了一块被 count 参数指定内存并且复制用户提供的数据到其中。因此，对象被分配的大小不再是严格的 4096 个字节（即使它仍然是最大缓冲区大小）。让我们假设用户提供的数据是 128 个字节大小并且缓冲区的最后字节不为空。当 apparmor_setprocattr() 被触发，args[128] 将被设置为0，因为检查的仍然为 PAGE_SIZE，并不是真实缓冲区大小：

 if (args[size - 1] != '\0') {

                if (size == PAGE_SIZE)

                        return -EINVAL;

                args[size] = '\0';

        }

因为对象在堆中被动态分配，下一个对象的第一位会被重写为 null。标准技术在不会起作用的爆破点对象之后放置了一个目标对象（包含了一个函数指针作为第一个成员）。一个主意是在一些对象上（因为像爆破点对象同样大小的）重写一个引用计数器并且然后触发一个 UAF（谢谢 Nicolas Tripar 的建议）。

对象引用计数器（atomic_t type = signed int 所代表）通常是结构的第一个成员。因为计数器的值通常对于大多数对象都是在 255 以下的，重写像一个对象最低有效的字节会清除计数器并且导致一个标准的 UAF。然而为了利用这个漏洞，我决定用一个不同的方法：重写SLUB freelist 指针。

Exploitation（爆破）

▼

关于这个漏洞的一件好事是我们能控制目标对象的大小。为了触发这个漏洞，对象大小应该被设置为缓存大小中的一个（如9，16，32，64，96，等等）。我们不会探究SLUB分配器如何工作（linux默认内核内存分配器）。我们所需要知道的是同样大小的不同对象为多用途和特殊用途分配积累成相同的缓存。slab是在缓存上包含同样大小对象主要的页。自由对象在偏移地址0（默认）处有一个“next free”的指针指向slab的下一个自由对象。

这个主意是在同样的一个slabshang 放置我们脆弱的对象（A）邻近一个自由对象（B）,然后清除对象B的“next free”指针的least-significant字节。当两个新对象在同样的slab上被分配，最后的对象将会被分配在靠着“next free”指针的对象A和/或者对象B。

上文情境（重叠 A 和 B 对象）是仅仅可能结局之一。目标对象“变化”的值是一个字节（0-255）并且最终目标对象的位置会依靠在原始的“next free”指针的值和对象大小。

假设目标对象会与对象 A 和 B 重叠，我们想要控制这些对象的内容。

在一个高等级，漏洞利用程序如下：

1. 在同样的slab上在邻近对象B处放置脆弱对象 A

2. 重写 B中的“next free”指针的 least-significant 字节

3. 在同样的 slab 分配两个新对象：第一个对象将会被放在 B 处，并且第二个对象将会替代我的目标对象 C

4. 如果我们控制对象A和B的内容，我们可以强制对象 C 被分配在用户空间

5. 假设对象 C 有一个能从其他地方触发函数指针，在用户空间或者可能的一个 ROP 链（绕过 SMEP）中设置这个指针为我们的权利提升的 payload。

为了执行步骤 1-3，连续的对象分配能够取得使用一个标准的堆耗尽技术。

接下来，我们需要选择正确的对象的大小。对象比 128 字节更大（例如，申请缓存256，512，1024 个字节，等等）的话，就不会在这里起作用。让我们假设起始的 slab 地址是 0x1000（标记slab的起始地址是与页大小一致的并且连续对象分配是相连的）。接下来的 C 程序列出了被给定对象大小的一个单页的分配：

//page_align.c

#include

int main(intargc, char **argv) {

        int i;

        void *page_begin = 0x1000;

        for (i = 0; i < 0x1000; i +=atoi(argv[1]))

                printf("%p\n",page_begin + i);

}

因为这些对象是 256 个字节（或>128并<=256字节），我们接下来匹配模式：

vnik@ubuntu:~$./align 256

0x1000

0x1100

0x1200

0x1300

0x1400

0x1500

0x1600

0x1700

0x1800

...

在 slab 所有配置的最低有效位为0并且重写邻近的自由对象的“nextfree”指针为 null 会没有效果：

因为 128 字节缓存，这里有两种可能选项：

vnik@ubuntu:~$./align 128

0x1000

0x1080

0x1100

0x1180

0x1200

0x1280

0x1300

0x1380

0x1400

...

第一个选项相似于之上的 256 字节例子（“nextfree”指针的最低有效位字节已经为0）。第二个选项很有趣，因为重写“next free”指针的最低有效位字节会指向自由对象本身。分配一些8个字节大小的对象（A）到一些（确定的）用户空间内存地址，其次是目标对象（B）的分配会在用户空间用户控制的内存地址放置对象B。这可能是在可靠性和易于利用两者间中的最好的选项。

1.      这有一个50/50成功机会。如果它是第一选项，没有崩溃,我们可以再试一次

2.      找到一个有一些用户空间地址的对象（首8个字节）将被放置在kmalloc-128缓存并不难。

尽管这是最好的方法，我决定将所有96字节对象和用msgsnd()堆耗尽/喷涂粘合起来。主要（仅有）的理由是因为已经发现了一个我想要使用的96字节的目标对象了。感谢Thomas Pollet帮助找到合适的堆对象并且在运行时用gdb/python自动化处理这个乏味的过程！

 然而，显然使用 96 字节对象有下降趋势；一个主要的原因是利用的可靠性。一个耗尽slab（如填充满slab部分）的主意就是 48 字节对象的标准 msgget() 技术（其他48字节被用来作为消息头）。这也将用作一个堆喷涂因为我们控制了 msg 对象的一半（48字节）。我们也控制脆弱对象的内容（数据从用户空间被写到 /proc/self/attr/current）。如果目标对象分配以便首8个字节被我们的数据所覆盖，然后漏洞利用将会成功。在另一方面，如果这8个字节用 msg 头（我们没有控制的）来覆盖，这会导致一个页面错误但是内核可能会被它自身恢复。基于我的分析，这里有两个例子，在这“next free”指针会用先前分配的随机 msg 头覆盖。

这里是有一些技巧来提高漏洞利用的可靠性。

目 标 对 象

▼

因为目标对象，我使用了 struct subprocess_info 结构，正是96字节大小。为了触发这个对象的分配，下面的套接字操作可以使用一个随机的协议家族：

socket(22,AF_INET, 0);

套接字族22不存在但是模块自动加载会触发到内核中下面的函数：

intcall_usermodehelper(char *path, char **argv, char **envp, int wait)

{

        struct subprocess_info *info;

        gfp_t gfp_mask = (wait == UMH_NO_WAIT)? GFP_ATOMIC : GFP_KERNEL;

        info = call_usermodehelper_setup(path,argv, envp, gfp_mask,    [6]

                                         NULL,NULL, NULL);

        if (info == NULL)

                return -ENOMEM;

        return call_usermodehelper_exec(info,wait);                    [7]

}

call_usermodehelper_setup [6] 然后会分配对象和初始化它的字段：

structsubprocess_info *call_usermodehelper_setup(char *path, char **argv,

                char **envp, gfp_t gfp_mask,

                int (*init)(structsubprocess_info *info, struct cred *new),

                void (*cleanup)(structsubprocess_info *info),

                void *data)

{

        struct subprocess_info *sub_info;

        sub_info = kzalloc(sizeof(structsubprocess_info), gfp_mask);

        if (!sub_info)

                goto out;

        INIT_WORK(⊂_info->work,call_usermodehelper_exec_work);

        sub_info->path = path;

        sub_info->argv = argv;

        sub_info->envp = envp;

        sub_info->cleanup = cleanup;

        sub_info->init = init;

        sub_info->data = data;

  out: 

        return sub_info;

}

一旦对象被初始化，这将绕过 call_usermodehelper_exec in [7]:

intcall_usermodehelper_exec(struct subprocess_info *sub_info, int wait)

{

        DECLARE_COMPLETION_ONSTACK(done);

        int retval = 0;

        if (!sub_info->path) {                                          [8]

               call_usermodehelper_freeinfo(sub_info);

                return -EINVAL;

        }

...

}

如果路径变量为 null[8]，然后 cleanup 函数被执行并且对象被释放：

static voidcall_usermodehelper_freeinfo(struct subprocess_info *info)

{

        if (info->cleanup)

                (*info->cleanup)(info);

        kfree(info);

}

如果我们覆盖了 cleanup 函数指针（记住对象现在在用户空间被分配），然后我们随着 CPL=0 就有了任意代码执行。仅有的一个问题是 subprocess_info 对象分配和释放在同样的路径。在 info->cleanup)(info) 被调用并且设置函数指针到我们的权限提升payload之前修改对象函数指针的一个方法是以某种方法停止执行。我本可以找到其他同样大小的因为分配和函数触发的两种“分开”路径，但是我需要一个理由去尝试userfaultfd() 和这个页面分裂的想法。

Userfaultfd 系统调用能够被用来处理用户空间中的页面错误。我们可以在用户空间分配一个页面并且设置一个处理器（当做一个分线程）；当这个页面因为读或写被访问，执行会被转移到用户空间处理器去处理页面错误。这里没有新鲜的并且这是被Jann Hornh所提到的。

SLUB 分配器在被分配之前访问对象（首8个字节去更新缓存 freelist 指针）。因此，这个主意就是分离开subprocess_info对象到两个连续的页面以便所有对象字段除了说这最后一个（如 void *data）将会被放在同样的页：

然后我们会设置用户空间页面错误处理器去处理在第二页的 PF。当 call_usermodehelper_setup 去设定 sub_info->data，代码被转移到用户空间PF处理器（在那里我们可以改变先前设定的 sub_info->cleanup 函数指针）。如果目标被kmalloc 所分配，这个方法会起作用。不像 kmalloc，kzalloc 在分配之后使用memset(..., 0, size(...))归零对象。不像 glibc，内核的杂类函数实现是十分简洁直接的（例如设置连续化的单个字节）：

void *memset(void*s, int c, size_t count)

{

        char *xs = s;

        while (count--)

                *xs++ = c;

        return s;

}

EXPORT_SYMBOL(memset);

这意味着设置在第二页的用户空间PF处理器将不再起作用，因为一个 PF 将会被杂项函数触发。然而，这仍然有可能被束缚用户空间页面错误所绕过：

1. 分配两个连续页面，分割对象到这两个页面（如之前的）并且为第二个页面设置页面处理器。

2. 当用户空间 PF 被杂项函数触发，为第一页设置另一个用户空间 PF 处理器。

3. 当对象变量在 call_usermodehelper_setup 中初始化了，那么接下来的用户空间PF将会触发。这时候设置为第二个页面设置另一个PF。

4. 最终，最后一个的用户空间 PF 处理器可以修改 cleanup 函数指针（通过设置它指向我们的权限提升 payload 或者 ROP 链）并且设置 path 成员为 0（因为这些成员在第一页被分配并且已经初始化了）。

因为“页面错误”的页面能够通过再次去除内存页映射/映射这些页实现，设置用户空间 PF 处理器。并且然后传递它们到 userfaultfd()。4.5.1 版本的 POC 能够在这里被找到。尽管对于内核版本没有什么特殊的（它应该可以工作在所有含有漏洞的内核）。这里没有权限提升payload但是这 POC 会在用户空间地址 0xdeadbeef 执行指令。

结 论

▼

这有可能是更容易利用此漏洞的方法，但是我仅仅想我只想让我发现的目标对象随着userfaultfd“工作”。清理机制缺失是因为我们是分配 IPC msg 对象，这不是非常重要并且有一些简单的方法稳固系统。

本文由 看雪 iOS 安全小组成员 rodster 编译，来源 Vitaly Nikolenko@cyseclabs

戳👇 图片加入看雪 iOS 安全小组哦！

❤ 往期热门内容推荐

---

• ......
  

更多优秀文章，长按下方二维码，“关注看雪学院公众号”查看！

看雪论坛：http://bbs.pediy.com/

微信公众号 ID：ikanxue

微博：看雪安全

投稿、合作：www.kanxue.com