CVE-2020-11896

基础知识

Treck TCP/IP

• Treck公司一套专用于嵌入式系统的TCP/IP协议
• tsPacket结构

struct tsPacket {
    ttUserPacket pktUserStruct; //数据包分片
    ttSharedDataPtr pktSharedDataPtr; // 指向存储处理数据包所需信息的Buffer的指针 
    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; // IP头所占长度
    tt8Bit pktNetworkLayer; // 指定数据包网络层类型.
    tt8Bit pktFiller[1];
};

• pktUserStruct

struct tsUserPacket {
    void * pktuLinkNextPtr; // 指向下一个分片
    ttUser8BitPtr pktuLinkDataPtr; //指向数据 
    ttPktLen pktuLinkDataLength; // 当前分片长度
    ttPktLen pktuChainDataLength; // 整个packet的长度，如果没有分片，等于pktuLinkDataLength
    int pktuLinkExtraCount;
};

漏洞原理

• 首先判断真实收到的数据（pktuChainDataLength）是否比头部中写的长，如果长则进行裁剪
  • 将当前分片长度（pktuLinkDataLength）和整个数据包长度（pktuChainDataLength）设置为头部中的长度
• 但是此时如果pktChainNextPtr仍然指向下一个分片，那么会产生不一致

存在问题：

• tfIpIncomingPacket函数处理中，首先进行的是trimming操作，然后调用tfIpReassemblePacke根据pktuChainDataLength建立分片链表，而在tfIpReassemblePacket函数中并不会将分片数据包复制到缓冲区中
• 最终将分片链表返回给下一层进行处理，而下一层并不会再次调用tfIpIncomingPacket，会导致不一致现象无法利用

• 使用IP隧道，tfIpIncomingPacket函数在处理内层IP数据包时，将之作为没有分片的数据包进行处理，此时将不会调用tfIpReassemblePacket函数进行处理
  
• 在处理内层数据包时就会产生不一致

将不一致转化为内存破坏

• 在UDP数据处理中，可以确定的是，至少有一条代码路径是将IP分片复制到自定义的buffer里面
  • 这个过程需要malloc堆空间，大小为 pktuChainDataLength 字段的大小
  • 然后通过tfCopyPacket将ip分片复制到heap中（拷贝未考虑长度）

i = 0;
do {
	memcpy(dst->pktuLinkDataPtr+i, src->pktuLinkDataPtr, src->pktuLinkDataLength);
	i = i+src->pktuLinkDataLength;
	src=(tsPacket *)src->pktuLinkNextPtr;
} while(src!=NULL)

• 所以堆的大小是小于实际报文长度的

参考文献

https://www.freebuf.com/vuls/243280.html