原创 | Ripple20：：：Treck TCP/IP和谈栈缝隙分析与验证

颁布功夫 2020-06-30

一、、媒介


国外安全钻研人员在由Treck开发的TCP/IP和谈栈中发现了多个缝隙，这一系列缝隙统称为Ripple20�！！！�。这些缝隙宽泛存在于嵌入式和物联网设备中，影响了多个行业领域（蕴含医疗、、运输、、能源、、电信、、工业节制、、零售和贸易等），涉及了众多供给商（蕴含HP、、Schneider Electric、、Intel、、Rockwell Automation、、Caterpillar、、Baxter等）�！！！�。


这些缝隙源于Ripple20的多个和谈（蕴含IPv4、、ICMPv4、、IPv6、、IPv6OverIPv4、、TCP、、UDP、、ARP、、DHCP、、DNS或以太网链路层）在处置网络报文发送时存在缺点，其中蕴含四个严重缝隙，它们的CVE编号别离为CVE-2020-11896、、CVE-2020-11898、、CVE-2020-11910、、CVE-2020-11911�！！！�。CVE-2020-11896（CVSS评分10）可导致远程执行代码，CVE-2020-11897（CVSS评分10）可导致越界写入，CVE-2020-11901（CVSS评分9）可导致远程执行代码，CVE-2020-11898（CVSS评分9.1）可导致泄露敏感信息�！！！�。其它15个Ripple20缝隙的严重水平各别，CVSS评分别离从3.1到8.2�！！！�。


由于物联网设备供给链的个性，缝隙影响的设备众多，影响领域广且持续功夫长，缝隙修复的执行较难题�！！！�。因而，OG东方厅ADLab第一功夫对有关缝隙进行了分析并提出了防备建议�！！！�。


二、、和谈栈检测


由于选取Treck和谈栈的厂家较多，有些厂家是硬件IP核的方式引用了Treck和谈栈�！！！�。单纯通过设备指纹来鉴别缝隙是不及的，若何检测指标设备是否为Treck和谈栈成为资产排查的关键，为此OG东方厅ADLab安全钻研员对Treck和谈栈进行了深刻分析，并公开了Treck和谈栈指纹检测步骤发现缝隙�！！！�。


Treck和谈栈自界说了类型为165(0xa5)的ICMP包，并一旦收到165的ICMP包会回复类型为166的ICMP包响应�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


首先，向指标发送 ICMP要求包，其中type=0xa5，code=0�！！！�。如下图所示：：：


OG东方厅·(中国大陆)


而后，接管指标返回的icmp响应包数据，其中type =0xa6,code =0，ICMP报文第9字节后的六个字节为0x01,0x51,0x35,0x28,0x57,0x32(大端)或0x51,0x01,0x28,0x35,0x32,0x57(小端）�！！！�。


满足上述的前提，则批瞩指标设备为treck 和谈栈�！！！�。如下图所示：：：


OG东方厅·(中国大陆)


三、、防备建议


1、、利用更新


实时更新到Treck TCP/IP和谈栈软件的最新不变版本（6.0.1.67或更高版本）�！！！�。


2. 阻止异常IP流量


能够通过深度数据包查抄来阻止网络攻击，以下是能够适当利用于网络环境中的可能缓解措施，过滤选项蕴含：：：


● 若是网络环境不支持，则规范化或回绝IP分片的数据包（IP分片）

● 若是不必要，请禁用或阻止IP隧道（IPv6-in-IPv4或IP-in-IP隧道）

● 阻止IP源路由和所有不赞成使用IPv6的职能，例如路由标头

● 强制执行TCP查抄并回绝体式谬误的TCP数据包

● 阻止未使用的ICMP节制新闻，例如MTU更新和地址掩码更新

● 通过安全的递归服务器或利用层防火墙规范DNS

● 确保网络环境中使用的是靠得住的OSI第2层设备（以太网）

● 通过DHCP侦听等职能提供DHCP / DHCPv6安全性

● 若是未在互换基础架构中使用，则禁用或阻止IPv6多播�！！！�。


四、、有关概念介绍


1、、IP分片


IP分片使得在网络中发送大的IP包成为可能，即便其巨细大于网络特定链路中允许的最大值�！！！�。IP分片技术是一种将数据包分成几个较小的部门以支持通过这些链路和网络传输的技术�！！！�。该和谈支持在发送端进行分片，而后在接管端对分片重新组合�！！！�。这允许分歧的包在网络中零散地传输，并在另一侧正确地重新组装�！！！�。


分歧的包使用IP头中的标识字段（Identification）进行分组�！！！�。此标识字段描述分片属于哪个包�！！！�。统一个包的多个分片的Identification是一样的�！！！�。IPv4通过Flags及Fragment Offset字段对分片进行治理，Flags由R、、DF、、MF三部门组成：：：


● R（Reserve bit）保留未用

● DF (Don't Fragment) DF =1：：：不容分片 , DF =0：：：允许分片

● MF (More Fragment) MF =1：：：非最后一片, MF =0：：：最后一片(或未分片)


Fragment Offset(13位)：：：一个IP分组分片封装原IP分组数据的相对偏移量, 片偏移字段以8字节为单元�！！！�。IP包结构如下图所示：：：


OG东方厅·(中国大陆)


2、、IP隧道技术


IP隧道允许两个独立网络之间的虚构点到点链路�！！！�。它是通过将包（可所以IP包）封装在另一个包中来实现的，使得内部包拥有与外部包分歧的源地址和指标地址�！！！�。外部包的源地址和指标地址是隧道端点，内部包中的地址用于隧道两端的网络路由�！！！�。隧道入口点是接管应通过隧道转发的IP数据包的节点�！！！�。它将此数据包封装在外部IP数据包中�！！！�。当数据包达到隧道出口点时，它被解封装并转发，就如同它是在指标网络中发送的通例数据包一样�！！！�。IP-in-IP包如下图所示：：：


OG东方厅·(中国大陆)


IP隧道技术重要利用在虚构专用网（VPN）技术中�！！！�。目前有几种隧道和谈，其中最单一和最古老的是IP-in-IP（IP和谈编号4）�！！！�。IP-in-IP是一种IP隧道和谈，其中一个IP包通过增长一个外部IP报头（其源地址和指标地址别离等于隧道的入口点和出口点）封装在另一个IP包中�！！！�。内部数据包未被批改，外部IP头从内部IP头复制一些字段�！！！�。外部报头的IP和谈号为4�！！！�。IP-in-IP报文示例如下图所示：：：


OG东方厅·(中国大陆)


五、、Treck和谈栈


1、、和谈栈概述


Treck和谈栈通过tsPacket结构来描述包结构，通过tsUserPacket结构支持数据包分片�！！！�。这两个结构体在treck/include/trsocket.h文件中界说�！！！�。Treck TCP/IP和谈栈中的包数据由tsPacket的结构暗示�！！！�。每个包都与一个数据缓冲区有关联，该数据缓冲区保留从接口驱动法式达到的原始数据�！！！�。tsPacket结构还保留另一个称为ttUserPacket的重要结构，以及指向tsSharedData结构的指针，该结构蕴含网络和谈栈处置数据包时所需的信息（指向套接字结构、、src/dst地址或端口等的指针）�！！！�。界说如下：：：


struct tsPacket {

ttUserPacket pktUserStruct;

ttSharedDataPtr pktSharedDataPtr;

struct tsPacket * pktChainNextPtr;

struct tsDeviceEntry * pktDeviceEntryPtr;

union anon_union_for_pktPtrUnion pktPtrUnion;

tt32Bit pktTcpXmitTime;

tt16Bit pktUserFlags;

tt16Bit pktFlags;

tt16Bit pktFlags2;

tt16Bit pktMhomeIndex;

tt8Bit pktTunnelCount;

tt8Bit pktIpHdrLen;

tt8Bit pktNetworkLayer;

tt8Bit pktFiller[1];

};


这是蕴含的ttUserPacket结构（tsUserPacket的typedef），界说如下：：：


struct tsUserPacket {

void * pktuLinkNextPtr; // Next tsUserPacket for fragmented data

ttUser8BitPtr pktuLinkDataPtr;

ttPktLen pktuLinkDataLength;

ttPktLen pktuChainDataLength;

int pktuLinkExtraCount;

};


pktuLinkNextPtr ：：：用于跟踪数据包中的分片�！！！�。此字段指向暗示下一个分片的另一个tsPacket结构，该tsPacket还保留对下一个分片的引用，若是此链接是最后一个分片，或者数据未被分片，则此字段将为NULL�！！！�。


pktuLinkDataPtr：：：指向当前分片的数据缓冲区�！！！�。当Treck和谈栈在分歧阶段处置数据包时，数据缓冲区中简直切地位会产生变动，这取决于当前正在处置的数据包地点和谈层�！！！�。例如，当Treck和谈栈处置以太网层（在tfEtherRecv()函数中）时，此字段指向以太网报头�！！！�。


pktuLinkDataLength：：：pktuLinkDataPtr指向的数据的巨细，即单个分片的巨细�！！！�。

pktuChainDataLength：：：暗示蕴含所有分片的数据包长度，即数据包的总巨细�！！！�。它只为第一个分片设置�！！！�。若是数据没有分片，则等于pktuLinkDataLength�！！！�。


2、、和谈栈处置过程


和谈栈中的一个常见模式是在和谈栈中的层之间移动时调整pktuLinkDataPtr指针�！！！�。例如，若是OG东方厅包是一个ICMP回显要求包（ping），它的和谈由三层组成：：：Ethernet、、IPv4、、ICMP�！！！�。在这种情况下，当处置以太网层（在tfEtherRecv()函数中）时，pktuLinkDataPtr指向以太网报头的起头，而后在移动到下一层之前，使用以下代码对其进行调整，如下代码所示：：：


OG东方厅·(中国大陆)


在本例中，0xe（十进制为14）是以太网报头（6（dst MAC）+6（src MAC）+2（etherType））的巨细�！！！�。当tfEtherRecv()函数实现包处置时，它将包转发到下一层处置�！！！�。支持的以太网类型有ARP、、IPv4和IPv6�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


在示例中，当IPv4层接管到数据包（在函数tfIpIncomingPacket()函数中）时，指针pktuLinkDataPtr已经指向IP报头�！！！�。传入数据由拥有一样定名约定tf*IncomingPacket的函数处置，其中*是和谈名�！！！�。对于ICMP包来说，它由三层和谈组成（Ethernet/IPv4/ICMP），数据包将由函数tfEtherRecv、、tfIpIncomingPacket和tfIcmpIncomingPacket函数别离处置�！！！�。


3、、分片重组


Treck和谈栈在tfIpReassemblePacket()函数中处置分片的重组，该函数由tfIpIncomingPacket()挪用�！！！�。每当接管到发往设备的IP分片时，就会挪用此函数�！！！�。若是短缺分片，函数将返回NULL�！！！�。不然，若是所有分片都达到并且没有浮泛，则网络和谈栈将使用pktuLinkNextPtr字段将分片链接在一路，而后将数据包传递给下一层进前进一步处置�！！！�。在此高低文中，“重组”一词并不料味着将数据包复制到陆续的存储块，而只是单一地将它们链接到一个链表中�！！！�。分片数据链表结构如下图所示：：：


OG东方厅·(中国大陆)

4、、tfIpIncomingPacket函数


tfIpIncomingPacket()函数是处置IP包的重要函数，该函数重要流程如下图所示：：：


OG东方厅·(中国大陆)


tfIpIncomingPacket()首先判断数据包合法性�！！！�。tfIpIncomingPacket()函数除了验证IP头校验和，它还进行以下验证，如下代码所示：：：


OG东方厅·(中国大陆)


而后若是所有合法性查抄都通过，tfIpIncomingPacket()函数将查抄IP报头中TotalLength 是否严格小于数据包的pktuChainDataLength，这暗示现实接管的数据比IP报头中申明的数据多�！！！�。若是是真的，则进行修剪操作，要删除额外的数据，如下代码所示：：：


OG东方厅·(中国大陆)


再者若是IP数据包的MF为1或者Fragment Offset大于0，则tfIpIncomingPacket()函数就要挪用tfIpReassemblePacket()函数进行分片重组�！！！�。若是IP分片数据接管不齐全，则tfIpReassemblePacket()函数返回NULL�！！！�。若是所有IP分片都达到并且没有谬误，则Treck和谈栈使用pktuLinkNextPtr字段将这些分片链接在一路，成立链表，并将包传递到下一层进前进一步处置，如下代码所示：：：


OG东方厅·(中国大陆)


最后若是已经收到齐全的IP数据包，则tfIpIncomingPacket()函数凭据IP数据包中的和谈字段的和谈号，挪用相应的和谈包处置函数进行处置�！！！�。鄙人列代码中，当和谈号为UDP时，则挪用tfUdpIncomingPacket()函数，当数据包和谈为IP-in-IP和谈（和谈号4）时，会递归挪用tfIpIncomingPacket()函数，代码实现如下所示：：：



OG东方厅·(中国大陆)


六、、缝隙道理分析


1、、CVE-2020-11896


前文已经介绍tfIpIncomingPacket()函数的实现过程，第二步的数据裁剪是缝隙的原因，如下代码所示：：：


OG东方厅·(中国大陆)


pktuLinkDataLength保留当前分片的巨细，pktuChainDataLength保留整个IP数据包的巨细�！！！�。若是执行上述操作，将导致一个不一致性的状态，其中pkt->pktuChainDataLength==pkt->pktuLinkDataLength，但可能有pkt->pktuLinkNextPtr指向其他分片�！！！�。更进一步的其中链表上分片的总数据巨细可能大于存储在pktuChainDataLength变量中的巨细�！！！�。这种操作导致的不一致性将会导致后续报文处置产生异常�！！！�。


通过单一地设置谬误的IP包分片是无法触发缝隙的，由于裁剪过后的分片数据在后续的tfIpReassemblePacket()函数操作中会凭据pktuChainDataLength的巨细，重新成立分片链表，不会造成不一致的状态�！！！�。梦想的流程是先实现分片链表的成立，再进行链表数据总巨细的裁剪流程，这样就会进入不一致的状态�！！！�。


为了在IP层处置分片数据包并触发执行有问题的流程代码，能够使用IP-in-IP数据包�！！！�。对于分片的IP-in-IP数据包，tfIpIncomingPacket()函数将至少递归挪用两次，一次用于IP隧道包的内层IP数据包，屡次用于外层IP数据包（每处置一个外层IP包分片算作一次）�！！！�。


tfIpIncomingPacket()函数在处置IP隧道数据包的时辰将内部IP数据包作为非分片数据包进行处置�！！！�。内部数据包此刻由多个分片组成，但在IP报头中象征为非分片（MF=0），所以它不会再进入tfIpReassemblePacket()函数进行重组�！！！�。它此刻由一个链表中的几个单独的tsPacket链接组成，每个链接都有一个单独的pktuLinkDataLength值�！！！��Ｋ伎枷旅娴睦�，它将有助于理解缝隙的成因：：：


● Inner IP packet: IPv4{len=32, proto=17}/UDP{checksum=0, len=12}，其中蕴含1000字节的数据’A’�！！！�。

● Outer IP packet (fragment 1): IPv4{frag offset=0, MF=1, proto=4, id=0xabcd} ,其中蕴含40字节的IP数据�！！！�。

● Outer IP packet (fragment 2): IPv4{frag offset=40, MF=0, proto=4, id=0xabcd} ，其中数据负荷为988字节�！！！�。


为了绕过UDP校验，将校验和字段checksum设置为0�！！！�。实例中的分片结构如下图所示：：：


OG东方厅·(中国大陆)


当Treck和谈栈处置外部门片时，它使用tsUserPacket结构中的pktuLinkNextPtr字段来链接它们�！！！�。如前所述，当tfIpIncomingPacket()函数处置内部IP数据包（和谈为4，IP-in-IP）时，它已经实现了分片数据的重组（内部IP数据包由链接在一路的两个tsPacket结构暗示）�！！！�。分片数据重组后的链表结构如下图所示：：：


OG东方厅·(中国大陆)


由于tfIpIncomingPacket()函数在进行有效性判断时，只思考tsUserPacket中的pktuChainDataLength字段（而不是pktuLinkDataLength），所以在处置内部IP包时将进入谬误的链表长度的裁剪流程，从而导致了问题�！！！�。


内部IP包通过了IP头齐全性查抄，在该例子中，内部IP包的总长度(32）小于链表数据长度（1000+8+20=1028），因而Treck和谈栈将尝试谬误地修剪数据包，步骤是将字段pktuLinkDataLength和pktuChainDataLength设置为一样的值ipTotalLength（在OG东方厅示例中为32）�！！！�。这导致内部IP数据包由链接在一路的两个tsPacket结构暗示，但它们的数据总长度大于pktuChainDataLength字段（修剪后pktuChainDataLength字段不是1028字节，而是等于32）�！！！�。经过数据长度裁剪后的链表结构如下图所示：：：


OG东方厅·(中国大陆)


此刻已经使得链表白到了不一致的状态，下面将介绍若何利用这种不一致的状态来导致内存粉碎�！！！�。


在Treck和谈栈代码中至少有一个代码蹊径能够将分片数据复制到单个陆续缓冲区中�！！！�。具体的执行蹊径为：：：

tfUdpIncomingPacket() ->  tfSocketIncomingPacket() -> tfCopyPacket()�！！！�。下面的代码是tfSocketIncomingPacket()函数处置UDP数据报的代码的一部门，如下代码所示：：：


OG东方厅·(中国大陆)


这段代码中tfSocketIncomingPacket()函数挪用tfGetSharedBuffer()申请内存，其巨细基于pktuChainDataLength字段的值，而后通过tfCopyPacket()函数将数据包的分歧分片逐个复制到新分配的内存空间中，产生溢出的代码如下所示：：：


OG东方厅·(中国大陆)


由于两个分片中的pktuLinkDataLength之和为1000字节，后续的tfCopyPacket函数将会把1000字节的数据拷贝到这段内存中，这将导致堆溢出�！！！�。


2、、CVE-2020-11898


正如前文描述若何触发CVE-2020-11896缝隙那样，Treck TCP/IP和谈栈无法正确处置通过IP-in-IP隧道传入的IPv4分片�！！！�。这也可能允许未经身份验证的攻击者从堆中泄漏内存�！！！��Ｄ芄谎∪∫韵率纠蟹煜洞シ�：：：


● 内部IP数据包：：：IPv4 {ihl = 0xf，len = 100，proto = 0}，有效载荷为'\ x00'* 40 +'\ x41'* 100�！！！�。

● 外部IP数据包（分片1）：：：IPv4 {frag offset = 0，MF = 1，proto = 4，id = 0xabcd}，其中24个字节来自内部IP数据包有效负载�！！！�。这意味着将复制20个字节的IP标头，外加4个空字节�！！！�。

● 外部IP数据包（分片2）：：：IPv4 {frag offset = 24，MF = 0，proto = 4，id = 0xabcd}，来自内部IP数据包的其余字节作为有效负载�！！！�。


实例中的分片结构如下图所示：：：


OG东方厅·(中国大陆)


这里ihl为0xf，暗示为最大IP选项，长度为60字节，数据包总长度total_length为100�！！！�。当网络和谈栈收到两个分片时，它将使用tfIpReassemblePacket()函数重新组装它们�！！！�。分片数据重组后的链表结构如下图所示：：：


OG东方厅·(中国大陆)


该tfIpReassemblePacket()函数使用tsUserPacket结构中的字段pktuLinkNextPtr链接两个分片�！！！�。若是启用了IP-in-IP隧道传输，则内部IP数据包将随后由tfIpIncomingPacket()函数中处置，修剪后的pktuChainDataLength字段不是160，而是等于100�！！！�。经过数据长度裁剪后的链表结构如下图所示：：：


OG东方厅·(中国大陆)


内部IP数据包通过IP标头齐全性查抄，由于仅思考了tsUserPacket的pktuChainDataLength字段（而不思考pktuLinkDataLength）�！！！�。由于在尺度IP头部（20个字节）之后有4个空字节，并且一个空字节代表IP选项的末尾，IP选项解析通过查抄�！！！�。由于内部IP数据包蕴含无效的IPv4和谈编号（Protocol为0），进入default分支，而后直接进入TM_IP_LOCAL_FLAG分支�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


因而网络和谈栈将通过发送类型为3（指标不成达）和代码为2（和谈不成达）的ICMP谬误新闻来回绝该数据包�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


掌管创建谬误数据包的是tfIcmpErrPacket()函数�！！！�。它分配一个新的数据包，初始化一些ICMP头部字段�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


最后从后续数据包（内部IP数据包）中复制一些数据�！！！�。复制部门如下代码所示：：：


OG东方厅·(中国大陆)


如代码所见，tfIcmpErrPacket()函数通过获取IP报头长度（以字节为单元加上8，在现实情况下为60 + 8 = 68）与pktuLinkDataLength字段（以及被裁剪为100）之间的最小值来推算要复制的字节数 �！！！�。由于发送数据包的第一个分片的现实链路数据长度为24（而不是100），因而tfIcmpErrPacket()函数将从堆中复制68-24 = 44字节的额外数据�！！！�。而后设置v12_icmpErrPacket中有关数据�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


最后挪用tfIpSendPacket()函数发送icmp_ErrPacket包到指标地址，这将导致44字节的信息泄露�！！！�。


3、、CVE-2020-11910


CVE-2020-11910是越界读缝隙，该缝隙存在tfIcmpIncomingPacket函数中，该函数重要是处置ICMP包�！！！�。tfIcmpIncomingPacket函数在处置设备收到类型为3，code为4的ICMP包的时辰，代码并没有验证后续数据的长度，直接就接见了对应地位的数据，造成了越界读缝隙�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


4、、CVE-2020-11911


CVE-2020-11911是未授权的敏感信息更新缝隙，该缝隙存在tfIcmpIncomingPacket函数中，该函数重要是处置ICMP包�！！！�。tfIcmpIncomingPacket函数在处置设备收到类型为18（Address mask reply）包的时辰，代码并没有验证设备是否发送过类型17（Address mask request）要求，就直接更新了设备的子网掩码�！！！�。如下代码所示：：：


OG东方厅·(中国大陆)


七、、CVE-2020-11898缝隙验证


远程攻击打印机，视频请到微信公家号中查看：：：验证视频�！！！�。


八、、参考


1、、https://www.ietf.org/rfc/rfc2003.txt

2、、https://www.ietf.org/rfc/rfc792.txt

3、、https://www.ietf.org/rfc/rfc1853.txt

4、、https://www.jsof-tech.com/ripple20/

5、、https://kb.cert.org/vuls/id/257161

6、、/article/1/11834.html

7、、JSOF_Ripple20_Technical_Whitepaper_June20.pdf



OG东方厅积极防御尝试室（ADLab）


ADLab成立于1999年，是中国安全行业最早成立的攻防技术钻研尝试室之一，微软MAPP打算主题成员，“黑雀攻击”概念首推者�！！！�。截止目前，ADLab已通过CVE累计颁布安全缝隙1000余个，通过 CNVD/CNNVD累计颁布安全缝隙800余个，持续维持国际网络安全领域一流水准�！！！�。尝试室钻研方向涵盖操作系统与利用系统安全钻研、、移动智能终端安全钻研、、物联网智能设备安全钻研、、Web安全钻研、、工控系统安全钻研、、云安全钻研�！！！�。钻研成就利用于产品主题技术钻研、、国度重点科技项目攻关、、专业安全服务等�！！！�。



OG东方厅·(中国大陆)