记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

一种漏洞原型:多个变量表示同一状态

2020-10-16 16:18

 

前言

最近分析了2个漏洞,分别是FreeBSD 内核中的CVE-2020-7454 ,Netgear路由器中的ZDI-20-709。虽然这2个漏洞所涉及的厂商设备不同,但是对其Root Cause 分析,可以得到这2个漏洞出现的根本原因是他们都使用了一种错误的编程范式—使用多个变量表示同一个状态。本文侧重对漏洞根因的分析,目的是能够举一反三,在别的厂商设备中找到根因相同的漏洞。PS:本文不包含对漏洞利用的详细叙述。

 

CVE-2020-7454

官方公布的漏洞的原因是libalias库中的函数对UDP包的header访问之前,并没有对其数据长度进行验证,最终导致了一个OOB的越界的读或者写漏洞。

libalias(3) packet handlers do not properly validate the packet length before
accessing the protocol headers. As a result, if a libalias(3) module does
not properly validate the packet length before accessing the protocol header,
it is possible for an out of bound read or write condition to occur.

这个漏洞出现在FreeBSD内核的libalias库中,这个库的主要作用是对IP包进行aliasing和dealiasing,以实现NAT功能,同时libalias库还实现了一些和协议转换相关的功能。具体包含漏洞的源码为

AliasHandleUdpNbtNS(...) 
{
/*...省略....*/

/* Calculate data length of UDP packet */
uh = (struct udphdr *)ip_next(pip);
nsh = (NbtNSHeader *)udp_next(uh);
p = (u_char *) (nsh + 1);
pmax = (char *)uh + ntohs(uh->uh_ulen); /* <--- (1) */

/* ... 省略... */
if (ntohs(nsh->ancount) != 0) {
p = AliasHandleResource(
ntohs(nsh->ancount),
(NBTNsResource *) p,
pmax,
&nbtarg
);
}
/* ... 省略... */
}
AliasHandleResource(..., char *pmax, ...)
{
/* ... 省略... */
switch (ntohs(q->type)) {
case RR_TYPE_NB:
q = (NBTNsResource *) AliasHandleResourceNB(
q,
pmax,
nbtarg
);
break;
/* ... 省略... */
}

在注释1的地方,内核直接从payload中读取UDP包的header,获得UDP数据包的length字段。注意这个地方很重要,payload是攻击者可控的,UDP包的长度也是攻击者可以修改的,UDP header中的length字段标识了UDP的负载和头的总长度。

继续分析代码,如果满足了一定的限制条件就可以进入到AliasHandleResource这个子函数的处理分支,进而可以到达AliasHandleResourceNB函数,这个函数是直接触发了OOB漏洞的函数。下面是AliasHandleResourceNB的部分源码

AliasHandleResourceNB(..., char *pmax, ...) 
{
/* ... 省略 ... */
while (nb != NULL && bcount != 0) {
if ((char *)(nb + 1) > pmax) { /* <--- (2) */
nb = NULL;
break;
}
if (!bcmp(&nbtarg->oldaddr, &nb->addr, sizeof(struct in_addr))) { /* <--- (3) /
/* ... snip ... */
nb->addr = nbtarg->newaddr; /* <--- (4) */
}
/* ... 省略 ... */
nb = (NBTNsRNB *) ((u_char *) nb + SizeOfNsRNB);
}
}

pmax的值就是从udp header中读取的UDP length与upd头的指针相加得到的偏移,简言之就是假设的udp的尾部,之所以说是假设的,因为有两种方式可以索引这个udp的尾部,第一种就是上述的方法,利用udp头的偏移和udp length之和索引。另一种方式就是通过ip包索引,ip header偏移与ip length之和也是索引的udp的尾部。如果udp包头的header length没有被恶意更改的情况下,这两种方式的索引都是可以的,但是如果udp 包的头部被恶意修改了,那么就会造成两种索引方式的不同步,udp包头的索引方式就是错误的。

而AliasHandleResourceNB这个子函数就是使用了错误的索引方式,以udp header偏移和udp length之和作为udp尾部的索引。标注2处是循环的终止条件,就是一直处理直到达到pmax位置,如果udp length被恶意改成很大的值,那么就会造成pmax位置已经超出了udp包payload,最终造成越界访问。标注3出现了一次越界读取,标注4则出现了越界写。

分析这个漏洞产生的根本原因就是有两种方式可以索引udp的尾部状态,如果对两种索引方式进行混用,那么一旦没有保持两种索引方式的同步,就会导致危险。

笔者分析了这个根因之后,也试图直接再在FreeBSD的源码中搜索采用两种方式索引UDP尾部的代码,期望能够找到类似的漏洞。经过搜索共发现了15个文件中34处出现通过UDP header索引的方式的代码。

经过简单分析,除了已经爆出的alias库中的漏洞,还有udp6_usrreq.c中出现了混用

/*
* Destination port of 0 is illegal, based on RFC768.
*/
if (uh->uh_dport == 0)
goto badunlocked;

plen = ntohs(ip6->ip6_plen) - off + sizeof(*ip6);
ulen = ntohs((u_short)uh->uh_ulen);

nxt = proto;
cscov_partial = (nxt == IPPROTO_UDPLITE) ? 1 : 0;
if (nxt == IPPROTO_UDPLITE) {
/* Zero means checksum over the complete packet. */
if (ulen == 0)
ulen = plen;
if (ulen == plen) ---------------->1
cscov_partial = 0;
if ((ulen < sizeof(struct udphdr)) || (ulen > plen)) {
/* XXX: What is the right UDPLite MIB counter? */
goto badunlocked;
}
if (uh->uh_sum == 0) {
/* XXX: What is the right UDPLite MIB counter? */
goto badunlocked;
}
}

虽然出现了混用,但是可以看到代码在一开始就对这两种索引方式进行了同步,所以这个地方也是不存在漏洞的。所以很遗憾笔者没有再找到别的漏洞,但是ZDI博文中的作者利用这种方法找到了FreeBSD中的另外一处相同原因的漏洞。


AliasHandleCUSeeMeIn(...)
{
/* ... 省略 ... */
end = (char *)ud + ntohs(ud->uh_ulen); /* <--- untrusted UDP header length */
if ((char *)oc <= end) {
/* ... 省略 ... */
if (ntohs(cu->data_type) == 101)
/* Find and change our address */
for (i = 0; (char *)(ci + 1) <= end && i < oc->client_count; i++, ci++)
if (ci->address == (u_int32_t) alias_addr.s_addr) { /* <--- OOBR */
ci->address = (u_int32_t) original_addr.s_addr; /* <--- OOBW */
break;
}
}
}

官方对此漏洞修复方式为:

即增加对UDP包头的验证,确保这两种对UDP尾部的索引方式是相同的。

 

ZDI-20-709

这个漏洞是一个无需认证的漏洞,发现者在追踪数据流的时候,发现在正常的认证逻辑之前存在一个无需认证的逻辑分支

这个无需认证的分支是一个文件上传的请求分支,这种无需认证的分支是安全审计的重点环节。在这个逻辑中存在一个漏洞,可以导致堆溢出。其原型就是

buffer = malloc(attacker_control_size)
memcpy(buffer, file_content, file_content_size)

这个漏洞根因也是由于有两种方式表示一个上传文件的长度,第一种方式是根据POST请求中文件字段的长度计算出来的,第二种是通过Content-Length字段计算出来的。一般情况下这二者是相同的,但是作者通过在URL中添加Content-Length字段,最终导致了二者的不同步。

当发现malloc的长度变量和memcpy中的长度变量并不是由一个变量而来的,而本来这两个变量应该是同步的,最好是同一个变量。

 

小结

除了这种常见的多个变量表示同一个长度信息造成的不同步,其他信息的不同步也同样可以导致漏洞,比如一个经典漏洞,OpenSolaris内核中的CVE-2008-568,它是由于设置了两种error状态的返回方式,一种是通过函数返回值返回错误信息,一种是通过全局变量返回错误信息,但是在一些逻辑中会造成二者的不同步,最终导致越界读写等。如果单纯的分析漏洞的表面原因,很难将这些漏洞联系起来,如果将这些漏洞原因深层思考,得到漏洞的Root Cause,就可以抽象出一种经常出现的漏洞原型-多个变量表示同一状态。


知识来源: https://www.anquanke.com/post/id/219468

阅读:6639 | 评论:0 | 标签:漏洞

想收藏或者和大家分享这篇好文章→复制链接地址

“一种漏洞原型:多个变量表示同一状态”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

ADS

标签云