在CVE-2023-0179-Nftables整型溢出中,分析了漏洞的成因,接下来分析漏洞的利用。
根据漏洞成因可以知道,payload_eval_copy_vlan
函数存在整型溢出,导致我们将vlan
头部结构拷贝到寄存器(NFT_REG32_00-NFT_REG32_15
),而该变量时存在与栈上的,因此可以覆盖栈上的其余变量的。
可以发现regs
变量是无法覆盖到返回地址。
因此我们需要观察源码,jumpstack
变量是在regs
变量下方
我们可以通过溢出regs
变量覆盖到jumpstack
变量。
那么接下来需要观察一下nft_jumpstack
结构体中存在哪些变量
struct nft_jumpstack {
const struct nft_chain *chain;
const struct nft_rule_dp *rule;
const struct nft_rule_dp *last_rule;
};
chain
:用于指定在哪个流程进行hook
rule
:以什么样的规则处理数据包
last_rule
:规则可能不止一条,因此last_rule
用于指向最后一条规则
nft_jumpstack
结构体在nft_do_chain
函数的作用如下,当状态寄存器被设置为JUMP
条件时,意味着需要跳转到其他chain
进行处理,因此需要先保存当前chain
的状态,这里与函数调用时保存栈时的处理一样,估计因此才命名为jumpstack
。并且使用一个全局变量stackptr
用于确定保存的chain
的先后顺序。在保存完之后,就跳转到目的chain
,目的chain
则是存储在regs.verdict.chain
中。
...
switch (regs.verdict.code) {
case NFT_JUMP:
if (WARN_ON_ONCE(stackptr >= NFT_JUMP_STACK_SIZE))
return NF_DROP;
jumpstack[stackptr].chain = chain;
jumpstack[stackptr].rule = nft_rule_next(rule);
jumpstack[stackptr].last_rule = last_rule;
stackptr++;
case NFT_GOTO:
chain = regs.verdict.chain;
goto do_chain;
...
还原chain
的过程如下,通过递减stackptr
来取出存储在jumpstack
变量中存储的chain
、rule
、lastrule
,然后就会跳转到next_rule
对还原的rule
,进行rule
的解析,这里需要注意的是在遍历rule
的时候,循环是通过rule < last_rule
进行遍历的,因此我们在后续伪造last_rule
的时候需要大于rule
,否则是无法进入循环内部的。
next_rule:
regs.verdict.code = NFT_CONTINUE;
for (; rule < last_rule; rule = nft_rule_next(rule)) {
nft_rule_dp_for_each_expr(expr, last, rule) {
if (expr->ops == &nft_cmp_fast_ops)
nft_cmp_fast_eval(expr, ®s);
else if (expr->ops == &nft_cmp16_fast_ops)
nft_cmp16_fast_eval(expr, ®s);
else if (expr->ops == &nft_bitwise_fast_ops)
nft_bitwise_fast_eval(expr, ®s);
else if (expr->ops != &nft_payload_fast_ops ||
!nft_payload_fast_eval(expr, ®s, pkt))
expr_call_ops_eval(expr, ®s, pkt);
if (regs.verdict.code != NFT_CONTINUE)
break;
}
...
if (stackptr > 0) {
stackptr--;
chain = jumpstack[stackptr].chain;
rule = jumpstack[stackptr].rule;
last_rule = jumpstack[stackptr].last_rule;
goto next_rule;
}
...
紧接着来看一下nft_rule_dp
结构体,可以发现第一个八个字节是一些标志位组成的,而后续的八个字节则是用于存储nft_expr
结构体的指针。
struct nft_rule_dp {
u64 is_last:1,
dlen:12,
handle:42; /* for tracing */
unsigned char data[]
__attribute__((aligned(__alignof__(struct nft_expr))));
};
然后可以看到nft_expr
结构体里存储了函数指针,如果我们能够篡改该函数指针就可以劫持程序流程。
struct nft_expr {
const struct nft_expr_ops *ops;
unsigned char data[]
__attribute__((aligned(__alignof__(u64))));
};
然后在这篇文章https://www.ctfiot.com/100156.html学习到了一个小技巧。使用ptype /o struct xxx
就可以看到具体的结构体信息与偏移。
因此构造的流程如下,首先我们通过漏洞溢出到nft_jumpstack
结构体,并且修改rule
变量为可控内容的地址同时需要将lastrule
的值篡改为比rule
更大的值,原因上述已经说过。紧接着在可控内容中伪造一个nft_rule_dp
结构体,第一个八字节是填充位,而第二个八字节是需要伪造的函数表指针,同样的我们也将该指针篡改为可控内容的地址,然后再该地址处伪造nft_expr
,并且将ops
变量指向我们想要执行的函数即可。
通过上述分析已经知道了该如何通过漏洞完成程序流程的劫持,接下来需要分析如果伪造上述几个结构体。
首先在nft_payload_copy_vlan
函数中,漏洞点是将vlan
头的数据拷贝到指定的寄存器里面,而vlan
头的地址是低于寄存器的地址,这就会导致在拷贝完vlan
头后会将寄存器中的值也进行拷贝的操作,而寄存器的值我们是能人为控制的,因此就可以完成伪造的操作。
可以看到我们对NFT_REG32_00
的赋值会覆盖到jumpstack[7].rule
的值,完成了对jumpstack
结构体的篡改,这里我们可以通过NFT_REG32_00 - NFT_REG32_15
进行赋值,紧接着查看jumpstack
哪个值是被赋值。就可以知道哪个jumpstack
可以被篡改。
由于我们可以控制regs
变量的值,我们可以首先泄露regs
的地址,然后在regs
上伪造rule
即可。然后expr
重新指向为jumpstack
即可,这里采用了一个小技巧就是将last_rule
设置为一个函数地址,由于函数地址的值是大于regs
变量的地址值的,因此我们可以节约八个字节。
但是这里有个问题就是我们只能控制八个字节的函数指针,因此是无法构造一个完整的ROP
链的,而内核并不存在像用户态下有one_gadget
可以只利用八个字节就能完成利用,因此在这里必须使用栈迁移,迁移的目的是一段可以控制的内存,那么这里选用的目的自然就是regs
了。那么该如何找栈迁移的gadget
呢?,这里我首先采用的使用利用vmlinux-to-elf
将bzImage
的符号表提取出来,然后寻找对应的gadget
,gadget
类型如下
mov rsp,xxx
push xxx;pop rsp
add rsp,xxx
xchg rsp,xxx
上述指令都可以修改rsp
寄存器,完成栈迁移的效果。
首先通过vmlinux-to-elf ./bzImage ./vmlinux
去提取出符号表
然后通过ropper
进行gadget
的提取,ropper --file ./vmlinux --nocolor > g
最后这在搜索gadget
,cat g | grep 'add rsp.*ret'
,但是通过尝试发现下述的地址都没办法使用,因为下述地址都不具备可执行的权限。
然后尝试了搜索上述所有的gadget
,我都没有找到可以用的gadget
,唯一比较接近的gadget
是pop rsi
的,但是无法控制rsi
的寄存器,其实这里一开始我使用的镜像是自己编译的,这里搜索的gadget
是需要控制rdi
寄存器的,经过多次尝试无果后才使用了作者的config
文件重新编译发现还是不可行。
其实我们在编译内核文件时是存在vmlinux
文件的,但是那个文件十分的大,使用ropper
工具无法分析,就在我准备放弃的时候,想到使用objdump
工具进行gadget
的提取
使用objdump -d -M intel vmlinux > ./gadget.txt
-d
是dump
代码
-M
是指定汇编代码的格式
objdump
提取的速度非常快,提取代码如下,但是它没有ropper
搜索gadget
那么方便,但是会全的多
这里我首先尝试了搜索栈迁移的gadget
,cat gadget.txt | grep -E 'add rsp.*'
可以发现有非常多的匹配的gadget
,接着我们在gdb
中验证可以使用的gadget
,通常在栈进行还原的时候会用到add rsp,xxx
,因此都是有效的gadget
,然后就是计算栈顶与resg
函数地址的差值找到相应的栈迁移gadget
即可。
接下就是考虑如何进行提权的利用了,虽然我们可以控制regs
但是可控的范围也只有0x40
是不足于采用commit_creds(prepare_kernel_cred(0))
设置root
凭证然后返回到用户空间执行后门的。那么相当的一个办法就是通过覆盖modprobe_path
进行提权。这里我找了下列gadget
进行modprobe_path
的覆盖,将rdi
设置为modprobe_path
,rax
设置为覆盖后的路径即可。
0xffffffff810d1e6b: mov qword ptr [rdi], rax; ret;
0xffffffff81004165: pop rdi; pop rbp; ret
最后就是覆盖完modprobe_path
该如何返回到用户态,因为modprobe_path
的提权需要在用户态下执行非法文件头的文件,这里作者采用的是将栈还原,通过在rbp
中的地址值覆盖会rsp
中即可,采用下述gadget
0xffffffff810b47f0: mov rsp, rbp; pop rbp; ret;
但是在我的环境下直接返回不行,这是因为在返回到nf_hook_slow
函数时,有对状态码的一个检验,而在上述覆盖modprobe_path
时,我们设置了rax
值,就导致无法将状态码设置成合法值。那分支就会跳转到default
,导致报错。在尝试搜索了gadget
之后,可以将rax
设置为0,但是这回进入到NF_DROP
分支 中,但是此时skb
变量也被我们破坏了,无法正常执行。
int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state,
const struct nf_hook_entries *e, unsigned int s)
{
unsigned int verdict;
int ret;
for (; s < e->num_hook_entries; s++) {
verdict = nf_hook_entry_hookfn(&e->hooks[s], skb, state);
switch (verdict & NF_VERDICT_MASK) {
case NF_ACCEPT:
break;
case NF_DROP:
kfree_skb_reason(skb,
SKB_DROP_REASON_NETFILTER_DROP);
ret = NF_DROP_GETERR(verdict);
if (ret == 0)
ret = -EPERM;
return ret;
case NF_QUEUE:
ret = nf_queue(skb, state, s, verdict);
if (ret == 1)
continue;
return ret;
default:
/* Implicit handling for NF_STOLEN, as well as any other
* non conventional verdicts.
*/
return 0;
}
}
return 1;
}
在尝试很久之后,最终放弃正常返回的这个选项,然后我在rbp
中搜索是否有合适的返回地址。最后在rbp
中我找到了一个do_softirq
函数
该函数是一个软中断处理的函数,当时我就猜想,如果这个函数返回了,应该不会影响程序的执行。
尝试运行之后,发现还是有内核异常,顿时有点失望。
但是在操控命令行的时候是能够正常输入命令的,说明我们成功返回到用户态了。
最后就是查看是否将新用户写入到/etc/passwd
中了,最终完成写入。完结撒花!。
完整exp可以参考https://github.com/h0pe-ay/Vulnerability-Reproduction/blob/master/CVE-2023-0179(nftables)/poc.c