Treck TCP/IP协议库“Ripple20”系列漏洞分析

2020年6月16日，位于以色列的一家专门从事物联网和嵌入式设备安全的JSOF公司警告说，由于严重安全漏洞影响了Treck TCP/IP协议堆栈，全球数亿台物联网设备可能会受到远程攻击。该漏洞修复于2020年6月29号由Treck发布。

Treck TCP/IP是一家总部位于美国辛辛那提的软件公司“Treck”在1997年推出的一套专用于嵌入式系统的TCP/IP底层Internet协议套件库。通过设计针对内核、定时器、驱动程序、套接字的API接口，Treck TCP/IP协议套件库可以很容易地集成到各种各样的嵌入式产品中。二十多年来，全球很多公司一直在使用这个库，使他们的设备或软件通过TCP/IP协议连接到互联网。

2.1 TCP/IP堆栈介绍

首先介绍Treck TCP/IP使用的2个机制：

（1）ipv4报文分片操作

在TCP/IP协议中，由于数据链路层MTU（最大传输单元）的限制，当一个IP数据包从一个MTU较高的网络传向MTU较低的网络时数据包就会被分片成一个个大小小于或等于MTU较低的目标网络的碎片。数据包在传输过程中往往都要经过数个网络，每个网络的MTU或许都不同，如果数据包大小比网络的MTU大时就进行分片，如果比网络的MTU小时则不做操作，也就是说传输过程中数据包可能被多次分片，但不进行重组，重组操作由数据包的最终接收方执行。

（2）IP隧道

 IP隧道技术允许两个独立网络之间的虚拟点对点链接。它是通过将一个数据包（可能是IP数据包）封装在另一个数据包中来实现的，从而使内部数据包具有与外部数据包不同的源地址和目的地址。

外部数据包的源地址和目的地址是IP隧道的两端，内部数据包的地址用于在两侧的网络中传输数据。中间的路由器不会考虑封装的数据内容，而链接的两端需要配置隧道协议。入口点需要将原始数据包用外部IP封装，出口点则要解包并检查其中是否存在一个可以在目标网络中发送的标准数据包。

根据JSOF对这个漏洞的描述，Treck TCP/IP协议堆栈中的数据包由称为tspacket的数据结构表示，包含另一个重要结构ttUserPacket，以及指向tsSharedData数据结构的指针，一个tspacket与一个数据缓冲区相关联，tspacket包含以下几个涉及漏洞的字段：

tsSharedData结构为：

这些结构用于支持IP报文分片，字段pktuLinkDataPtr指向当前片段的数据缓冲区。这个数据缓冲区中的确切位置随着网络堆栈在不同阶段处理数据包的不同而改变，并取决于当前正在处理的数据包的层位置。堆栈中的一个常见模式是报文在堆栈中的层之间移动时调整pktuLinkDataPtr指针。例如，如果我们的数据包是ICMP返回请求数据包（Ping），数据将由三层包组成：以太网，其次是IPv4，最后是ICMP。在这种情况下，当以太网层被处理时（在函数tfEtherRecv中），pktuLinkDataPtr指向以太网报头的开始处，然后在移动到下一层之前，使用以下图所示代码进行调整：

0xe是以太网报头（6位（目的地址MAC）+6位（源地址MAC）+2位（以太网类型））的长度大小。当tfEtherRecv完成数据包处理时，它使用表示下一层协议的以太网类型EtherType字段将数据包转发到下一层处理。所支持以太网类型包括ARP、IPv4和IPv6。

2.2 漏洞根本原因

首先了解以下两个字段：

IHL（4位）：表示IP报头的大小（以双字为单位）。最小值为5（20个字节）。如果有IP选项，则报头长度会变大，最大值为0xf（60字节）。

TotalLength总长度（2字节）：整个IP数据包的大小，以字节为单位包括报头。

函数tfIpIncomingPacket从一些基本的健全性检查开始。除报头校验和外还验证ip_version,data_available,header_length,total_length等字段，如果所有健全性检查均通过，则该函数检查IP报头中指定的总长度是否严格小于数据包的pktuChainDataLength值，如果是则表明实际收到的数据比IP报头中所描述的要多，这时进行微调操作以删除多余的数据。如果为真，则进行微调操作以删除多余的数据。判断方式为：

这造成了协议的漏洞。pktuLinkDataLength的大小为当前片段和pktuChainDataLength保存整个数据包的大小。如果上述操作发生，则会创建了一个不一致情况，其中pkt->pktuChainDataLength==pkt->pktuLinkDataLength，但可能会有其他片段指向pkt->pktuLinkNextPtr。另一种情况，链表上片段的总长度比存储在pktuChainDataLength中的长度要大，这时构成不一致的状态。

每次使用一个接收到的片段都会调用tfIpIncomingPacket函数，并会调用-tfIp ReassemblePacket来处理。tfIpReassemblePacket负责将片段插入到上面描述的链表中。它不会将片段复制到连续的内存缓冲区中。接收到所有片段时，tfIpReassemblePacket将完整数据包作为片段的链接列表返回，以便在下一个协议层上进一步处理。此重组操作是在易受攻击的微调操作之后执行的。一旦重新分配操作完成，tfIpIncomingPacket将返回或转发数据包，以便在下一个网络层（例如：UDP）进行处理。因为我们需要一个碎片化的数据包才能到达不一致状态，所以这种情况阻止了我们利用漏洞。换句话说，成功攻击的代码只可能会在每个碎片的基础上执行（或者在单个碎片分组上）。

这样做并不易实现漏洞利用，但是结合IP隧道即可以实现允许封装的内层IP数据包被tfIpIncomingPacket函数作为非碎片数据包处理。tfIpIncomingPacket函数将被递归调用，一次用于IP隧道的内层，几次用于外层（每个碎片一次）。当tfIpIncomingPacket函数处理内层IP数据包时，它正在处理传入的片段数据（内层IP数据包由链接在一起的两个tsPacket结构表示），但仍将调用易受攻击的微调数据流，从而构成了漏洞利用的条件。

使用UDP实现堆栈溢出。由于已经有了一个定义长度和实际长度不一致的状态，接下来可以利用这个不一致来实现内存空间攻击。协议中有一段代码，实现将片段数据复制到单个连续缓冲区中。这是处理UDP数据报的代码的一部分。该操作的内部逻辑包括分配一个新的数据包（使用tfGetSharedBuffer），其大小基于pktuChainDataLength字段，然后将数据包的不同片段复制到新分配的数据包中。负责执行复制功能的函数是tfCopyPacket函数，它按顺序接受源数据包和目标数据包。

可以看出，函数tfCopyPacket没有考虑到它写入缓冲区的长度。它只是从源数据包（我们的分段数据包）中获取每个链接，并将其数据复制到目标数据包中。目标数据包是根据pktuChainDataLength的值分配的，因此，如果之前漏洞被触发了，则分配的缓冲区可能小于我们失效后数据包中所有单独链接的长度总和，此时，就会发生缓冲区堆溢出。

综上所述，当使用Treck TCP/IP协议栈的设备，开放UDP端口正在侦听，我们可以快速发送数据包，以便套接字接收队列为非空。同时，我们发送一个人为构建好的片段化的UDP数据包，该数据包将触发漏洞。如果之前使用tfGetSharedBuffer在内存上分配了一个小的缓冲区，那么tfCopyPacket操作可以将其成功溢出。

受影响版本：Treck TCP/IP < 6.0.1.67

3.1检测方式

可通过针对代码资产进行核查，看是否使用了Treck的相关代码，并从源代码中查看软件版本是否在受影响范围。针对二进制库文件，可以使用如下命令查看库文件的版本，确定是否使用了受影响的版本。

strings 驱动名称| grep -e"[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}"

若检测当前版本在受影响范围内，则存在上述安全风险。

3.2修复建议

TreckTCP/IP最新版本已修复该漏洞，修复版本为6.0.1.67及其后的所有版本。

访问该链接获取最新版相关组件：https://treck.com/products/

3.3 深信服检测方案

访问该链接获取深信服检测工具：

https://edr.sangfor.com.cn/api/download/scan_tool.zip

（本文由深信服科技供稿）

CHIMA大讲堂直播与回放：

https://djt.chima.org.cn

全国卫生健康行业网络安全技能大赛：

https://chcsc.chima.org.cn

CHIMA 2020 征文通知

CHIMA 2020 案例征集通知

CHIMA 2020 书展通知

2019-2020年度医院信息化状况调查