8827太阳集团ADLab：VxWorks多个远程缝隙分析
颁布功夫 2019-08-02VxWorks是世界上使用最宽泛的实时操作系统（RTOS），，，，，有超过20亿台设备在使用，，，，，蕴含工业、电力、能源，，，，，航空航天等行业关键基础设施 。 。 。。 。。。
? 缝隙影响版本
URGENT/11缝隙影响自6.5版以来的险些所有VxWorks版本，，，，，不蕴含为认证而设计的产品版本，，，，，例如VxWorks 653和VxWorks Cert Edition 。 。 。。 。。。
? VxWorks6.5~6.9.4
? 使用IPNet网络和谈栈的VxWorks版本
? 解决规划
? 防火墙和IDS产品增长规定，，，，，检测异常流量 。 。 。。 。。。
? 使用最新缝隙扫描工具检测内部受缝隙影响的设备资产 。 。 。。 。。。
? 风河(Wind River)公司已颁布有关版本更新和补丁信息 。 。 。。 。。。
? 罗克韦尔(Rockwell)、Sonicwall、施乐(Xerox)等公司已颁布更新包，，，，，请实时更新 。 。 。。 。。。
? 缝隙道理分析
Armis Labs在VxWorks中共发现了11个0day缝隙，，，，，其中6个缝隙为严沉缝隙并能够远程执行代码（RCE），，，，，其余5个缝隙为回绝服务，，，，，信息泄露或逻辑缺点缝隙 。 。 。。 。。。具体如下表所示：
8827太阳集团ADLab拔取了三个比力典型的缝隙CVE-2019-12255、CVE-2019-12257、CVE-2019-12258进行分析 。 。 。。 。。。它们涉及到了IPNet和谈栈及DHCP和谈处置实现 。 。 。。 。。。
▲ CVE-2019-12255缝隙分析
CVE-2019-12255缝隙是IPNet和谈栈在处置TCP报文urg标志时的整数溢露马脚 。 。 。。 。。。在受影响版本的VxWorks TCP和谈栈实现中，，，，，若是一个TCP报文设置了urg标志，，，，，那么该TCP报文的urgent pointer字段会在iptcp_deliver函数中用于变量tcb-> recv.urg_ptr的赋值 。 。 。。 。。。在VxWorks版本6.8版本中，，，，，实现代码如下所示：
在尔后socket执行recv（）操作时，，，，，会挪用函数iptcp_usr_get_from_recv_queue，，，，，该函数处置报文段时首先判断当前TCP数据段是否蕴含urgent标志，，，，，若是蕴含该标志，，，，，则查抄是否会将当前TCP窗口中的urgent 数据读取出来（urgent数据不允许通过通例recv读� 。 。 。。 。。。� 。 。 。。 。。。查抄方式如下图所示：
其中，，，，，ugent_pointer是在函数iptcp_deliver中赋值的，，，，，len为recv函数参数，，，，，若是通过推算发现读取len长度的数据会读取到urgent data数据，，，，，则沉新对len赋值，，，，，以保障urgent 数据不被读取 。 。 。。 。。。下面两张图展示了上述代码的成效 。 。 。。 。。。
若是接管到的TCP段中的urgent_pointer字段设置为0，，，，，则iptcp_usr_get_from_recv_queue通过推算得到建改后的len为-1 。 。 。。 。。。由于len是无符号整数，，，，，即蹬宗0xffffffff 。 。 。。 。。。这导致recv（）挪用中设置的读取长度限度失效，，，，，从而拷贝所有可读取的数据到用户缓冲区，，，，，造成溢出 。 。 。。 。。。
缝隙验证：
凭据缝隙道理，，，，，我们编写了该缝隙的POC验证法式，，，，，并在VxWorks6.8版本的系统上进行了验证 。 。 。。 。。。通过直接发送urgent pointer为0的数据包，，，，，造成栈溢出后覆盖函数返回地址，，，，，如下图所示：
▲ CVE-2019-12257缝隙分析
此缝隙是VxWorks系统设备内置的ipdhcpc（VxWorks的内置DHCP客户端）在处置DHCP响应数据包时触发的堆溢露马脚 。 。 。。 。。。当ipdhcpc尝试从DHCP服务器获取IP地址时，，，，，与指标设备位于统一子网中的攻击者能够通过特殊设计的DHCP响应数据包回复，，，，，使得VxWorks系统设备产生堆溢出，，，，，从而能够在VxWorks系统设备上执行肆意代码 。 。 。。 。。。
当通过挪用ipdhcpc_if_eventcb函数对dhcp客户端的handle进行初始化时，，，，，ipdhcpc_if_eventcb函数会挪用ipdhcpc_handle_malloc函数为dhcp客户端的handle分配空间，，，，，在ipdhcpc_handle_malloc函数中，，，，，该函数为handle->info.options分配了大幼为ipdhcpc.max_message_size-264字节的空间 。 。 。。 。。。
当ipdhcpc_daemon的主循环内执行ipcom_recvfrom接管响应数据包时：
ipdhcpc_daemon函数接管后数据后，，，，，会挪用ipdhcpc_reply_input函数对接管到的dhcp和谈数据进行处置，，，，，其中handle->priv->in_optlen 的长度基于ipdhcpc.in_pkt_len推算，，，，，handle->priv->in_optlen=ipdhcpc.in_pkt_len-240，，，，，也就是说handle->priv->in_optlen的最大值为ipdhcpc.max_message_size-240 。 。 。。 。。。
而后，，，，，在后续的挪用 ipdhcpc_offer_input（或ipdhcpc_ack_input），，，，，在这两个函数中会执行memcpy操作：
在上图中，，，，，handle-> priv-> in_optlen的最大值可所以ipdhcpc.max_message_size - 240，，，，，它大于为handle-> info.options分配的空间，，，，，为ipdhcpc.max_message_size - 264 。 。 。。 。。。在vxwroks中ipdhcpc.max_message_size值默以为576，，，，，攻击者在局域网中通过机关长度为576的恶意dhcp响应数据就能够使得被攻击设备中的vxworks系统产生24字节的堆溢出 。 。 。。 。。。
▲ CVE-2019-12258缝隙分析
Iptcp_input函数会挪用iptcp_process_options()函数处置TCP头的options数据域 。 。 。。 。。。Iptcp_process_options()函数在判断options数据域类型时，，，，，实现代码如下：
该switch凭据options数据域的类型进行分发，，，，，这个case分支是设置MSS的，，，，，行80并判断该类型的options数据域长度必须为4，，，，，若是不蹬宗4，，，，，就判断MSS犯法，，，，，直接退出 。 。 。。 。。。返回到iptcp_input函数中，，，，，由于返回值幼于0，，，，，就进入if分支，，，，，挪用iptcp_send_reset()函数，，，，，该函数职能是沉置并断掉当前TCP衔接 。 。 。。 。。。若是攻击者发送恶意options的TCP数据包，，，，，将导致衔接断开 。 。 。。 。。。此缝隙能够允许攻击者强造沉置衔接到受影响的VxWorks设备的任何TCP会话，，，，，造成回绝服务攻击 。 。 。。 。。。
? ABB公司工业自动化产品
? 通用电气工业自动化产品? 艾默生(Emerson)公司工业节造设备
? 日立(HITACHI)公司医疗设备
? 百通(Belden)工业设备
? 德尔格(Dr?ger)公司医疗设备
? 施耐德(Schneider)公司PLC
? 三菱(Mitsubishi)公司工业节造器
? 飞利浦(Philips)公司医疗设备
? 库卡(KUKA)公司工业机械人
? 史陶比尔(St?ubli)公司工业机械人
? 安川(Yaskawa)电机工业机械人
除了以上设备，，，，，还有大量使用VxWorks的设备，，，，，具体列表请参照参考文件链接1和2 。 。 。。 。。。
参考文件：
2.https://en.wikipedia.org/wiki/VxWorks#Notable_uses
3.https://armis.com/urgent11/
4.https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1088561
5.https://www.sonicwall.com/support/product-notification/?sol_id=190717234810906
6.https://security.business.xerox.com/en-us/
7.https://www.windriver.com/security/announcements/tcp-ip-network-stack-ipnet-urgent11/
京公网安备11010802024551号