原创 | 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 。。 。。。。。。
由于物联网设备供给链的个性，，， ，，，，，缝隙影响的设备多多，，， ，，，，，影响领域广且持续功夫长，，， ，，，，，缝隙建复的执行较难题 。。 。。。。。。因而，，， ，，，，，8827太阳集团ADLab第一功夫对有关缝隙进行了分析并提出了防备建议 。。 。。。。。。
二、和谈栈检测
由于选取Treck和谈栈的厂家较多，，， ，，，，，有些厂家是硬件IP核的方式引用了Treck和谈栈 。。 。。。。。。单纯通过设备指纹来鉴别缝隙是不及的，，， ，，，，，若何检测指标设备是否为Treck和谈栈成为资产排查的关键，，， ，，，，，为此8827太阳集团ADLab安全钻研员对Treck和谈栈进行了深刻分析，，， ，，，，，并公开了Treck和谈栈指纹检测步骤发现缝隙 。。 。。。。。。
Treck和谈栈自界说了类型为165(0xa5)的ICMP包，，， ，，，，，并一旦收到165的ICMP包会回复类型为166的ICMP包响应 。。 。。。。。。如下代码所示：
首先，，， ，，，，，向指标发送 ICMP要求包，，， ，，，，，其中type=0xa5，，， ，，，，，code=0 。。 。。。。。。如下图所示：
而后，，， ，，，，，接管指标返回的icmp响应包数据，，， ，，，，，其中type =0xa6,code =0，，， ，，，，，ICMP报文第9字节后的六个字节为0x01,0x51,0x35,0x28,0x57,0x32(大端)或0x51,0x01,0x28,0x35,0x32,0x57(幼端） 。。 。。。。。。
满足上述的前提，，， ，，，，，则批瞩指标设备为treck 和谈栈 。。 。。。。。。如下图所示：
三、防备建议
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包结构如下图所示：
2、IP隧路技术
IP隧路允许两个独立网络之间的虚构点到点链路 。。 。。。。。。它是通过将包（可所以IP包）封装在另一个包中来实现的，，， ，，，，，使得内部包拥有与表部包分歧的源地址和指标地址 。。 。。。。。。表部包的源地址和指标地址是隧路端点，，， ，，，，，内部包中的地址用于隧路两端的网络路由 。。 。。。。。。隧路入口点是接管应通过隧路转发的IP数据包的节点 。。 。。。。。。它将此数据包封装在表部IP数据包中 。。 。。。。。。当数据包达到隧路出口点时，，， ，，，，，它被解封装并转发，，， ，，，，，就如同它是在指标网络中发送的通例数据包一样 。。 。。。。。。IP-in-IP包如下图所示：
IP隧路技术重要利用在虚构专用网（VPN）技术中 。。 。。。。。。目前有几种隧路和谈，，， ，，，，，其中最单一和最古老的是IP-in-IP（IP和谈编号4） 。。 。。。。。。IP-in-IP是一种IP隧路和谈，，， ，，，，，其中一个IP包通过增长一个表部IP报头（其源地址和指标地址别离蹬宗隧路的入口点和出口点）封装在另一个IP包中 。。 。。。。。。内部数据包未被批改，，， ，，，，，表部IP头从内部IP头复造一些字段 。。 。。。。。。表部报头的IP和谈号为4 。。 。。。。。。IP-in-IP报文示例如下图所示：
五、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指针 。。 。。。。。。例如，，， ，，，，，若是8827太阳集团包是一个ICMP回显要求包（ping），，， ，，，，，它的和谈由三层组成：Ethernet、IPv4、ICMP 。。 。。。。。。在这种情况下，，， ，，，，，当处置以太网层（在tfEtherRecv()函数中）时，，， ，，，，，pktuLinkDataPtr指向以太网报头的起头，，， ，，，，，而后在移动到下一层之前，，， ，，，，，使用以下代码对其进行调整，，， ，，，，，如下代码所示：
在本例中，，， ，，，，，0xe（十进造为14）是以太网报头（6（dst MAC）+6（src MAC）+2（etherType））的大幼 。。 。。。。。。当tfEtherRecv()函数实现包处置时，，， ，，，，，它将包转发到下一层处置 。。 。。。。。。支持的以太网类型有ARP、IPv4和IPv6 。。 。。。。。。如下代码所示：
在示例中，，， ，，，，，当IPv4层接管到数据包（在函数tfIpIncomingPacket()函数中）时，，， ，，，，，指针pktuLinkDataPtr已经指向IP报头 。。 。。。。。。传入数据由拥有一样定名约定tf*IncomingPacket的函数处置，，， ，，，，，其中*是和谈名 。。 。。。。。。对于ICMP包来说，，， ，，，，，它由三层和谈组成（Ethernet/IPv4/ICMP），，， ，，，，，数据包将由函数tfEtherRecv、tfIpIncomingPacket和tfIcmpIncomingPacket函数别离处置 。。 。。。。。。
3、吩飕沉组
Treck和谈栈在tfIpReassemblePacket()函数中处置吩飕的沉组，，， ，，，，，该函数由tfIpIncomingPacket()挪用 。。 。。。。。。每当接管到发往设备的IP吩飕时，，， ，，，，，就会挪用此函数 。。 。。。。。。若是短缺吩飕，，， ，，，，，函数将返回NULL 。。 。。。。。。不然，，， ，，，，，若是所有吩飕都达到并且没有浮泛，，， ，，，，，则网络和谈栈将使用pktuLinkNextPtr字段将吩飕链接在一路，，， ，，，，，而后将数据包传递给下一层进前进一步处置 。。 。。。。。。在此高低文中，，， ，，，，，“沉组”一词并不料味着将数据包复造到陆续的存储块，，， ，，，，，而只是单一地将它们链接到一个链表中 。。 。。。。。。吩飕数据链表结构如下图所示：
4、tfIpIncomingPacket函数
tfIpIncomingPacket()函数是处置IP包的重要函数，，， ，，，，，该函数重要流程如下图所示：
tfIpIncomingPacket()首先判断数据包合法性 。。 。。。。。。tfIpIncomingPacket()函数除了验证IP头校验和，，， ，，，，，它还进行以下验证，，， ，，，，，如下代码所示：
而后若是所有合法性查抄都通过，，， ，，，，，tfIpIncomingPacket()函数将查抄IP报头中TotalLength 是否严格幼于数据包的pktuChainDataLength，，， ，，，，，这暗示现实接管的数据比IP报头中申明的数据多 。。 。。。。。。若是是真的，，， ，，，，，则进行建剪操作，，， ，，，，，要删除额表的数据，，， ，，，，，如下代码所示：
再者若是IP数据包的MF为1或者Fragment Offset大于0，，， ，，，，，则tfIpIncomingPacket()函数就要挪用tfIpReassemblePacket()函数进行吩飕沉组 。。 。。。。。。若是IP吩飕数据接管不齐全，，， ，，，，，则tfIpReassemblePacket()函数返回NULL 。。 。。。。。。若是所有IP吩飕都达到并且没有谬误，，， ，，，，，则Treck和谈栈使用pktuLinkNextPtr字段将这些吩飕链接在一路，，， ，，，，，成立链表，，， ，，，，，并将包传递到下一层进前进一步处置，，， ，，，，，如下代码所示：
最后若是已经收到齐全的IP数据包，，， ，，，，，则tfIpIncomingPacket()函数凭据IP数据包中的和谈字段的和谈号，，， ，，，，，挪用相应的和谈包处置函数进行处置 。。 。。。。。。鄙人列代码中，，， ，，，，，当和谈号为UDP时，，， ，，，，，则挪用tfUdpIncomingPacket()函数，，， ，，，，，当数据包和谈为IP-in-IP和谈（和谈号4）时，，， ，，，，，会递归挪用tfIpIncomingPacket()函数，，， ，，，，，代码实现如下所示：
六、缝隙道理分析
1、CVE-2020-11896
前文已经介绍tfIpIncomingPacket()函数的实现过程，，， ，，，，，第二步的数据裁剪是缝隙的原因，，， ，，，，，如下代码所示：
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 。。 。。。。。。事俘中的吩飕结构如下图所示：
当Treck和谈栈处置表部吩飕时，，， ，，，，，它使用tsUserPacket结构中的pktuLinkNextPtr字段来链接它们 。。 。。。。。。如前所述，，， ，，，，，当tfIpIncomingPacket()函数处置内部IP数据包（和谈为4，，， ，，，，，IP-in-IP）时，，， ，，，，，它已经实现了吩飕数据的沉组（内部IP数据包由链接在一路的两个tsPacket结构暗示） 。。 。。。。。。吩飕数据沉组后的链表结构如下图所示：
由于tfIpIncomingPacket()函数在进行有效性判断时，，， ，，，，，只思考tsUserPacket中的pktuChainDataLength字段（而不是pktuLinkDataLength），，， ，，，，，所以在处置内部IP包时将进入谬误的链表长度的裁剪流程，，， ，，，，，从而导致了问题 。。 。。。。。。
内部IP包通过了IP头齐全性查抄，，， ，，，，，在该例子中，，， ，，，，，内部IP包的总长度(32）幼于链表数据长度（1000+8+20=1028），，， ，，，，，因而Treck和谈栈将尝试谬误地建剪数据包，，， ，，，，，步骤是将字段pktuLinkDataLength和pktuChainDataLength设置为一样的值ipTotalLength（在8827太阳集团示例中为32） 。。 。。。。。。这导致内部IP数据包由链接在一路的两个tsPacket结构暗示，，， ，，，，，但它们的数据总长度大于pktuChainDataLength字段（建剪后pktuChainDataLength字段不是1028字节，，， ，，，，，而是蹬宗32） 。。 。。。。。。经过数据长度裁剪后的链表结构如下图所示：
此刻已经使得链表白到了不一致的状态，，， ，，，，，下面将介绍若何利用这种不一致的状态来导致内存粉碎 。。 。。。。。。
在Treck和谈栈代码中至少有一个代码蹊径能够将吩飕数据复造到单个陆续缓冲区中 。。 。。。。。。具体的执行蹊径为：
tfUdpIncomingPacket() -> tfSocketIncomingPacket() -> tfCopyPacket() 。。 。。。。。。下面的代码是tfSocketIncomingPacket()函数处置UDP数据报的代码的一部门，，， ，，，，，如下代码所示：
这段代码中tfSocketIncomingPacket()函数挪用tfGetSharedBuffer()申请内存，，， ，，，，，其大幼基于pktuChainDataLength字段的值，，， ，，，，，而后通过tfCopyPacket()函数将数据包的分歧吩飕逐个复造到新分配的内存空间中，，， ，，，，，产生溢出的代码如下所示：
由于两个吩飕中的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数据包的其余字节作为有效负载 。。 。。。。。。
事俘中的吩飕结构如下图所示：
这里ihl为0xf，，， ，，，，，暗示为最大IP选项，，， ，，，，，长度为60字节，，， ，，，，，数据包总长度total_length为100 。。 。。。。。。当网络和谈栈收到两个吩飕时，，， ，，，，，它将使用tfIpReassemblePacket()函数沉新组装它们 。。 。。。。。。吩飕数据沉组后的链表结构如下图所示：
该tfIpReassemblePacket()函数使用tsUserPacket结构中的字段pktuLinkNextPtr链接两个吩飕 。。 。。。。。。若是启用了IP-in-IP隧路传输，，， ，，，，，则内部IP数据包将随后由tfIpIncomingPacket()函数中处置，，， ，，，，，建剪后的pktuChainDataLength字段不是160，，， ，，，，，而是蹬宗100 。。 。。。。。。经过数据长度裁剪后的链表结构如下图所示：
内部IP数据包通过IP标头齐全性查抄，，， ，，，，，由于仅思考了tsUserPacket的pktuChainDataLength字段（而不思考pktuLinkDataLength） 。。 。。。。。。由于在尺度IP头部（20个字节）之后有4个空字节，，， ，，，，，并且一个空字节代表IP选项的末尾，，， ，，，，，IP选项解析通过查抄 。。 。。。。。。由于内部IP数据包蕴含无效的IPv4和谈编号（Protocol为0），，， ，，，，，进入default分支，，， ，，，，，而后直接进入TM_IP_LOCAL_FLAG分支 。。 。。。。。。如下代码所示：
因而网络和谈栈将通过发送类型为3（指标不成达）和代码为2（和谈不成达）的ICMP谬误新闻来回绝该数据包 。。 。。。。。。如下代码所示：
掌管创建谬误数据包的是tfIcmpErrPacket()函数 。。 。。。。。。它分配一个新的数据包，，， ，，，，，初始化一些ICMP头部字段 。。 。。。。。。如下代码所示：
最后从后续数据包（内部IP数据包）中复造一些数据 。。 。。。。。。复造部门如下代码所示：
如代码所见，，， ，，，，，tfIcmpErrPacket()函数通过获取IP报头长度（以字节为单元加上8，，， ，，，，，在现实情况下为60 + 8 = 68）与pktuLinkDataLength字段（以及被裁剪为100）之间的最幼致反推算要复造的字节数 。。 。。。。。。由于发送数据包的第一个吩飕的现实链路数据长度为24（而不是100），，， ，，，，，因而tfIcmpErrPacket()函数将从堆中复造68-24 = 44字节的额表数据 。。 。。。。。。而后设置v12_icmpErrPacket中有关数据 。。 。。。。。。如下代码所示：
最后挪用tfIpSendPacket()函数发送icmp_ErrPacket包到指标地址，，， ，，，，，这将导致44字节的信息泄露 。。 。。。。。。
3、CVE-2020-11910
CVE-2020-11910是越界读缝隙，，， ，，，，，该缝隙存在tfIcmpIncomingPacket函数中，，， ，，，，，该函数重要是处置ICMP包 。。 。。。。。。tfIcmpIncomingPacket函数在处置设备收到类型为3，，， ，，，，，code为4的ICMP包的时辰，，， ，，，，，代码并没有验证后续数据的长度，，， ，，，，，直接就接见了对应地位的数据，，， ，，，，，造成了越界读缝隙 。。 。。。。。。如下代码所示：
4、CVE-2020-11911
CVE-2020-11911是未授权的敏感信息更新缝隙，，， ，，，，，该缝隙存在tfIcmpIncomingPacket函数中，，， ，，，，，该函数重要是处置ICMP包 。。 。。。。。。tfIcmpIncomingPacket函数在处置设备收到类型为18（Address mask reply）包的时辰，，， ，，，，，代码并没有验证设备是否发送过类型17（Address mask request）要求，，， ，，，，，就直接更新了设备的子网掩码 。。 。。。。。。如下代码所示：
七、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
8827太阳集团积极防御尝试室（ADLab）
ADLab成立于1999年，，， ，，，，，是中国安全行业最早成立的攻防技术钻研尝试室之一，，， ，，，，，微软MAPP打算主题成员，，， ，，，，，“黑雀攻击”概想首推者 。。 。。。。。。截止目前，，， ，，，，，ADLab已通过CVE累计颁布安全缝隙1000余个，，， ，，，，，通过 CNVD/CNNVD累计颁布安全缝隙800余个，，， ，，，，，持续维持国际网络安全领域一流水准 。。 。。。。。。尝试室钻研方向涵盖操作系统与利用系统安全钻延注移动智能终端安全钻延注物联网智能设备安全钻延注Web安全钻延注工控系统安全钻延注云安全钻研 。。 。。。。。。钻研成就利用于产品主题技术钻延注国度沉点科技项目攻关、专业安全服务等 。。 。。。。。。
京公网安备11010802024551号