漏洞背景
VxWorks是世界上使用最广泛的实时操作系统（RTOS），有超过20亿台设备正在使用，包括工业、电力、能源，航空航天等行业关键基础设施。
近日，Armis研究团队Armis Labs在VxWorks中发现了11个0day漏洞被称为URGENT/11，其中6个漏洞为严重漏洞并可以远程执行代码（RCE），其余5个漏洞包含拒绝服务、信息泄露和逻辑缺陷漏洞。这些漏洞能够使攻击者远程接管设备，而无需交互，甚至可以绕过防火墙等周边安全设备。这些特征使这些漏洞“易于使用”，这意味着它们可用于将恶意软件传播到网络内部，这种攻击具有很大的潜力，类似于WannaCry恶意软件的传播方式，启明星辰ADLab强烈建议相关用户尽快进行设备版本升级并做好网络安全设备的规则升级工作。
漏洞影响版本
URGENT/11漏洞影响自6.5版以来的几乎所有VxWorks版本，不包括为认证而设计的产品版本，例如VxWorks 653和VxWorks Cert Edition。
VxWorks7(SR540和SR610)
VxWorks6.5~6.9.4
使用IPNet网络协议栈的VxWorks版本
表1 漏洞影响列表
解决方案
防火墙和IDS产品添加规则，检测异常流量。
使用最新漏洞扫描工具检测内部受漏洞影响的设备资产。
风河(Wind River)公司已发布相关版本更新和补丁信息。
罗克韦尔(Rockwell)、Sonicwall、施乐(Xerox)等公司已发布更新包，请及时更新。
漏洞原理分析
Armis Labs在VxWorks中共发现了11个0day漏洞，其中6个漏洞为严重漏洞并可以远程执行代码（RCE），其余5个漏洞为拒绝服务，信息泄露或逻辑缺陷漏洞。具体如下表所示：
表2 漏洞描述列表 启明星辰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版本中，实现代码如下所示：
图1 iptcp_deliver中设置urg_ptr的代码
在此后socket执行recv（）操作时，会调用函数iptcp_usr_get_from_recv_queue，该函数处理报文段时首先判断当前TCP数据段是否包含urgent标志，如果包含该标志，则检查是否会将当前TCP窗口中的urgent 数据读取出来（urgent数据不允许通过常规recv读取）。检查方式如下图所示：
图2 检查读取数据是否会包含urgent data
其中，ugent_pointer是在函数iptcp_deliver中赋值的，len为recv函数参数，如果通过计算发现读取len长度的数据会读取到urgent data数据，则重新对len赋值，以保证urgent 数据不被读取。下面两张图展示了上述代码的效果。
图3 recv请求的数据区域（来源：URGENT/11技术白皮书）
图4 重新修正len之后recv读取的数据区域（来源：URGENT/11技术白皮书）
如果接收到的TCP段中的urgent_pointer字段设置为0，则iptcp_usr_get_from_recv_queue通过计算得到修正后的len为-1。由于len是无符号整数，即等于0xffffffff。这导致recv（）调用中设置的读取长度限制失效，从而拷贝所有可读取的数据到用户缓冲区，造成溢出。
漏洞验证：
该漏洞影响的版本包括VxWorks6.5到VxWorks 6.9.3。
根据漏洞原理，我们编写了该漏洞的POC验证程序，并在VxWorks6.8版本的系统上进行了验证。通过直接发送urgent pointer为0的数据包，造成栈溢出后覆盖函数返回地址，如下图所示：
图5 CVE-2019-12255漏洞验证
CVE-2019-12257漏洞分析
此漏洞是VxWorks系统设备内置的ipdhcpc（VxWorks的内置DHCP客户端）在处理DHCP响应数据包时触发的堆溢出漏洞。当ipdhcpc尝试从DHCP服务器获取IP地址时，与目标设备位于同一子网中的攻击者可以通过特殊设计的DHCP响应数据包回复，使得VxWorks系统设备发生堆溢出，从而可以在VxWorks系统设备上执行任意代码。
ipdhcpc守护进程启动后会进入ipdhcpc_daemon函数进行网络数据的循环监听，ipdhcpc_daemon函数主要流程有三步，第一步是通过调用ipdhcpc_if_eventcb函数对DHCP客户端的handle进行初始化并发送DHCP广播请求，第二步是调用ipcom_recvfrom接收DHCP服务器回复的响应数据包，第三步是通过调用ipdhcpc_replay_input对接收到的响应数据包进行处理。
图6 ipdhcpc_daemon函数流程示意
当通过调用ipdhcpc_if_eventcb函数对dhcp客户端的handle进行初始化时，ipdhcpc_if_eventcb函数会调用ipdhcpc_handle_malloc函数为dhcp客户端的handle分配空间，在ipdhcpc_handle_malloc函数中，该函数为handle->info.options分配了大小为ipdhcpc.max_message_size-264字节的空间。
图7 ipdhcpc_handle_malloc函数流程示意
当ipdhcpc_daemon的主循环内执行ipcom_recvfrom接收响应数据包时：
此处接收最多为ipdhcpc.max_message_size字节的数据包，ipdhcpc.in_pkt_len的最大长度为ipdhcpc.max_message_size。
图8 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。
图9 ipdhcpc_reply_input函数调用示意
然后，在后续的调用 ipdhcpc_offer_input（或ipdhcpc_ack_input），在这两个函数中会执行memcpy操作：
图10 ipdhcpc_reply_input流程示意
在上图中，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漏洞分析
CVE-2019-12255漏洞是IPNet协议栈在处理TCP报文分片时的拒绝服务漏洞。在受影响的VxWorks系统中Iptcp_input函数用于处理TCP分片的数据包，在解析TCP头时，实现代码如下：
图11 Iptcp_input函数示意
Iptcp_input函数会调用iptcp_process_options()函数处理TCP头的options数据域。Iptcp_process_options()函数在判断options数据域类型时，实现代码如下：
图12 Iptcp_process_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。
参考文献：
1.https://www.windriver.com/customers/
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/
声明：本文来自ADLab，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
