近日，奇安信CERT监测到Windows TCP/IP 存在远程代码执行漏洞，攻击者可通过向受影响主机发送特制ICMPv6 路由广告包来利用此漏洞，成功利用此漏洞的攻击者可在目标服务器或客户端上执行任意代码。目前已经监测到可稳定触发BSOD(蓝屏死机)的POC，经过奇安信CERT研判，此漏洞危害较大，攻击者有可能制作蠕虫病毒来实现远程代码执行。奇安信CERT强烈建议受影响用户及时更新补丁，做好相应防护。
此次更新新增内容：
此漏洞的PoC已被公开，漏洞危害变大。
新增技术分析
奇安信 CERT
漏洞描述
CVE-2020-16898被称为“坏邻居”漏洞。Windows TCP/IP协议栈在处理ICMPv6 路由广告包时，存在此远程代码执行漏洞。由于使用选项类型25和偶数长度字段对ICMPv6路由器播发数据包的处理不当，导致存在此漏洞。
目前Windows TCP/IP 远程代码执行漏洞(CVE-2020-16898)细节以及POC已在网上公开，攻击者可通过向受影响主机发送特制ICMPv6 路由通告包来利用此漏洞，成功利用此漏洞的攻击者可在目标服务器或客户端上执行任意代码。经验证，网上公开的POC可稳定触发BSOD(蓝屏死机)。鉴于该漏洞影响较大，建议客户尽快升级到最新版本。
奇安信CERT第一时间复现了CVE-2020-16898漏洞，复现截图如下：
漏洞时间线：
2020年10月14日，在微软补丁日当天，修复了一个紧急漏洞：Windows TCP/IP 远程代码执行漏洞(CVE-2020-16898)，国外安全厂商发布了漏洞验证视频，可证明此漏洞会造成BSOD(蓝屏死机)，并指出有可能被恶意攻击者利用来进行蠕虫攻击。
2020年10月16日，监测到Windows TCP/IP 远程代码执行漏洞细节及POC，经验证，网上公开的POC可稳定触发BSOD(蓝屏死机)。
漏洞公开情况：
细节是否公开 | PoC状态 | EXP状态 | 在野利用 |
是 | 已公开 | 未知 | 未知 |
风险等级
奇安信 CERT风险评级为：高危
风险等级：蓝色(一般事件)
影响范围Windows 10 Version 1709 for 32-bit Systems
Windows 10 Version 1709 for ARM64-based Systems
Windows 10 Version 1709 for x64-based Systems
Windows 10 Version 1803 for 32-bit Systems
Windows 10 Version 1803 for ARM64-based Systems
Windows 10 Version 1803 for x64-based Systems
Windows 10 Version 1809 for 32-bit Systems
Windows 10 Version 1809 for ARM64-based Systems
Windows 10 Version 1809 for x64-based Systems
Windows 10 Version 1903 for 32-bit Systems
Windows 10 Version 1903 for ARM64-based Systems
Windows 10 Version 1903 for x64-based Systems
Windows 10 Version 1909 for 32-bit Systems
Windows 10 Version 1909 for ARM64-based Systems
Windows 10 Version 1909 for x64-based Systems
Windows 10 Version 2004 for 32-bit Systems
Windows 10 Version 2004 for ARM64-based Systems
Windows 10 Version 2004 for x64-based Systems
Windows Server 2019
Windows Server 2019 (Server Core installation)
Windows Server, version 1903 (Server Core installation)
Windows Server, version 1909 (Server Core installation)
Windows Server, version 2004 (Server Core installation)
处置建议
使用奇安信天擎的客户可以通过奇安信天擎控制台一键更新修补相关漏洞，也可以通过奇安信天擎客户端一键更新修补相关漏洞。
也可以采用以下官方解决方案及缓解方案来防护此漏洞：
Windows自动更新
Windows系统默认启用 Microsoft Update，当检测到可用更新时，将会自动下载更新并在下一次启动时安装。还可通过以下步骤快速安装更新：
1、点击“开始菜单”或按Windows快捷键，点击进入“设置”
2、选择“更新和安全”，进入“Windows更新”(Windows 8、Windows 8.1、Windows Server 2012以及Windows Server 2012 R2可通过控制面板进入“Windows更新”，步骤为“控制面板”-> “系统和安全”->“Windows更新”)
3、选择“检查更新”，等待系统将自动检查并下载可用更新
4、重启计算机，安装更新
系统重新启动后，可通过进入“Windows更新”->“查看更新历史记录”查看是否成功安装了更新。对于没有成功安装的更新，可以点击该更新名称进入微软官方更新描述链接，点击最新的SSU名称并在新链接中点击“Microsoft 更新目录”，然后在新链接中选择适用于目标系统的补丁进行下载并安装。
手动安装补丁
另外，对于不能自动更新的系统版本(如Windows 7、Windows Server 2008、Windows Server 2008 R2)，可参考以下链接下载适用于该系统的10月补丁并安装：
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898
如果无法立即安装更新，可参考以下步骤缓解漏洞：
1.禁用ICMPv6 RDNSS：
您可以使用下面的PowerShell命令禁用ICMPv6 RDNSS，以防止攻击者利用此漏洞。此解决方案仅适用于Windows 1709及更高版本。有关更多信息，请参见Windows Server 1709的新增功能(https://docs.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-1709)。
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable注意：此变更无需重启系统
您可以使用下面的PowerShell命令恢复：
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=enable注意：此变更无需重启系统
技术分析
近日，奇安信CERT监测到 CVE-2020-16898 漏洞细节以及 POC 在网上公开，便第一时间复现了此漏洞，经测试，该 POC 可稳定触发 BSOD，以下为测试时的抓包数据：
当Windows TCP / IP堆栈不正确地处理使用选项类型 25(递归DNS服务器(RDNSS)选项)且长度字段值为偶数的 ICMPv6 路由器广告数据包时，存在一个远程执行代码漏洞。抓包数据确实满足以上条件。
IPv6 路由器广告选项允许 IPv6 路由器向 DNS6 主机广告 DNS 递归服务器地址列表和 DNS 搜索列表。RDNSS 选项通常包含一个或多个递归 DNS 服务器的 IPv6 地址列表。所有地址共享相同的生命周期值。如果希望具有不同的“生存时间”值，则可以使用多个 RDNSS 选项。以下为 RDNSS 选项的格式：
Type(1个字节)：RDNSS选项类型的类型为25(0x19)
Length(1个字节)：如果该选项中包含一个IPv6地址，则长度取最小值3 。每增加一个RDNSS地址，长度就会增加2。接收器使用“长度”字段来确定选项中IPv6地址的数量
LifeTime(4个字节)：该RDNSS地址可以用于名称解析的最长时间(相对于发送包的时间，以秒为单位)
Addresses of IPv6 Recursive DNS Servers(可变长度，由“Length”字段确定)：一个或多个递归DNS服务器的128位IPv6地址 。地址个数为(Length - 1)/ 2
可以将 Length 字段理解为 RDNSS 选项总长度/8，IPv6 Recursive DNS Servers 地址前的字段占 8 字节，每个 IPv6 Recursive DNS Servers 地址长度为 16 个字节，所以正常的 RDNSS 选项总长度应满足 16x+8(x>=1)，将其除以 8 就是 2x+1(x>=1) ，也就是 Length 字段应该满足的条件。漏洞在于没有对 Length 字段进行奇偶判断，导致对 Addresses of IPv6 Recursive DNS Servers 及下一个 RDNSS 选项边界的错误解析，从而引发安全问题。
系统使用 Ipv6pHandleRouterAdvertisement 函数处理 IPv6 路由器广告数据，在该函数中使用 NdisGetDataBuffer 函数以从 NET_BUFFER 结构中访问数据(连续或不连续)，使用 NET_BUFFER 结构( NdisGetDataBuffer 函数第一个参数)中 CurrentMdlOffset 的字段定位要访问数据起始地址相对于 MDL 指向内存数据的偏移。如下所示，使用 NdisGetDataBuffer 函数获取第一个 RDNSS 选项数据指针。
0: kd> gBreakpoint 0 hittcpip!Ipv6pHandleRouterAdvertisement+0x984:fffff806`4c1dad2c e89f33d7ff call ndis!NdisGetDataBuffer (fffff806`4bf4e0d0)0: kd> dt _net_buffer @rcxndis!_NET_BUFFER +0x000 Next : (null) +0x008 CurrentMdl : 0xffffdd06`68748d60 _MDL +0x010 CurrentMdlOffset : 0x10 +0x018 DataLength : 0x188 +0x018 stDataLength : 0x188 +0x020 MdlChain : 0xffffdd06`6a9c8180 _MDL +0x028 DataOffset : 0x70 +0x000 Link : _SLIST_HEADER +0x000 NetBufferHeader : _NET_BUFFER_HEADER +0x030 ChecksumBias : 0 +0x032 Reserved : 0 +0x038 NdisPoolHandle : 0xffffdd06`68531040 Void +0x040 NdisReserved : [2] (null) +0x050 ProtocolReserved : [6] 0x00000198`00000000 Void +0x080 MiniportReserved : [4] (null) +0x0a0 DataPhysicalAddress : _LARGE_INTEGER 0x0 +0x0a8 SharedMemoryInfo : (null) +0x0a8 ScatterGatherList : (null) 0: kd> dx -id 0,0,ffffdd0666892300 -r1 ((ndis!_MDL *)0xffffdd0668748d60)((ndis!_MDL *)0xffffdd0668748d60) : 0xffffdd0668748d60 [Type: _MDL *] [+0x000] Next : 0xffffdd066e8ea9b0 [Type: _MDL *] [+0x008] Size : 56 [Type: short] [+0x00a] MdlFlags : 4 [Type: short] [+0x00c] AllocationProcessorNumber : 0x0 [Type: unsigned short] [+0x00e] Reserved : 0x0 [Type: unsigned short] [+0x010] Process : 0x0 [Type: _EPROCESS *] [+0x018] MappedSystemVa : 0xffffdd0668748da0 [Type: void *] [+0x020] StartVa : 0xffffdd0668748000 [Type: void *] [+0x028] ByteCount : 0x30 [Type: unsigned long] [+0x02c] ByteOffset : 0xda0 [Type: unsigned long]0: kd> db 0xffffdd0668748da0 + 10ffffdd06`68748db0 19 04 00 00 00 00 03 84-30 30 30 30 30 30 30 30 ........00000000ffffdd06`68748dc0 30 30 30 30 30 30 30 30-18 22 fd 81 00 00 03 84 00000000."......ffffdd06`68748dd0 00 f9 09 02 55 48 33 77-9e f9 09 f1 00 00 00 00 ....UH3w........ffffdd06`68748de0 e0 8d 74 68 06 dd ff ff-90 26 3c 68 06 dd ff ff ..th.....&ffffdd06`68748df0 10 86 74 68 06 dd ff ff-80 85 74 68 06 dd ff ff ..th......th....ffffdd06`68748e00 02 00 00 00 00 00 00 00-48 8e 74 68 06 dd ff ff ........H.th....ffffdd06`68748e10 00 00 00 00 00 00 00 00-18 8e 74 68 06 dd ff ff ..........th....ffffdd06`68748e20 18 8e 74 68 06 dd ff ff-00 00 00 00 00 00 00 00 ..th............0: kd> ptcpip!Ipv6pHandleRouterAdvertisement+0x989:fffff806`4c1dad31 0fb64801 movzx ecx,byte ptr [rax+1]0: kd> db raxffffdd06`68748db0 19 04 00 00 00 00 03 84-30 30 30 30 30 30 30 30 ........00000000ffffdd06`68748dc0 30 30 30 30 30 30 30 30-18 22 fd 81 00 00 03 84 00000000."......ffffdd06`68748dd0 00 f9 09 02 55 48 33 77-9e f9 09 f1 00 00 00 00 ....UH3w........ffffdd06`68748de0 e0 8d 74 68 06 dd ff ff-90 26 3c 68 06 dd ff ff ..th.....&ffffdd06`68748df0 10 86 74 68 06 dd ff ff-80 85 74 68 06 dd ff ff ..th......th....ffffdd06`68748e00 02 00 00 00 00 00 00 00-48 8e 74 68 06 dd ff ff ........H.th....ffffdd06`68748e10 00 00 00 00 00 00 00 00-18 8e 74 68 06 dd ff ff ..........th....ffffdd06`68748e20 18 8e 74 68 06 dd ff ff-00 00 00 00 00 00 00 00 ..th............据 quarkslab 博客中所讲，Ipv6pUpdateRDNSS 会计算 IPv6 地址数量为(option.Length-1)/ 2，使用 POC 调试的话为(4-1)/ 2 = 1，因而会以 3 个 8 字节为单位前进 NET_BUFFER，以下为在第一个 RDNSS 选项的 length 字段下断点的情况。
0: kd> gBreakpoint 1 hittcpip!Ipv6pUpdateRDNSS+0x9d:fffff806`4c34a661 8d4e01 lea ecx,[rsi+1]0: kd> ub rip l1tcpip!Ipv6pUpdateRDNSS+0x99:fffff806`4c34a65d 0fb64301 movzx eax,byte ptr [rbx+1]0: kd> db rbxffffdd06`68748db0 19 04 00 00 00 00 03 84-30 30 30 30 30 30 30 30 ........00000000ffffdd06`68748dc0 30 30 30 30 30 30 30 30-18 22 fd 81 00 00 03 84 00000000."......ffffdd06`68748dd0 00 f9 09 02 55 48 33 77-9e f9 09 f1 00 00 00 00 ....UH3w........ffffdd06`68748de0 e0 8d 74 68 06 dd ff ff-90 26 3c 68 06 dd ff ff ..th.....&ffffdd06`68748df0 10 86 74 68 06 dd ff ff-80 85 74 68 06 dd ff ff ..th......th....ffffdd06`68748e00 02 00 00 00 00 00 00 00-48 8e 74 68 06 dd ff ff ........H.th....ffffdd06`68748e10 00 00 00 00 00 00 00 00-18 8e 74 68 06 dd ff ff ..........th....ffffdd06`68748e20 18 8e 74 68 06 dd ff ff-00 00 00 00 00 00 00 00 ..th............0: kd> u rip //计算(length - 1)/ 2tcpip!Ipv6pUpdateRDNSS+0x9d:fffff806`4c34a661 8d4e01 lea ecx,[rsi+1] // rsi =1,ecx=2fffff806`4c34a664 2bc6 sub eax,esi // 4-1=3fffff806`4c34a666 4183cfff or r15d,0FFFFFFFFhfffff806`4c34a66a 99 cdqfffff806`4c34a66b f7f9 idiv eax,ecx // 3/2 =1fffff806`4c34a66d 8b5304 mov edx,dword ptr [rbx+4]fffff806`4c34a670 8945b7 mov dword ptr [rbp-49h],eaxfffff806`4c34a673 8bf0 mov esi,eax0: kd> tcpip!Ipv6pUpdateRDNSS+0xa7:fffff806`4c34a66b f7f9 idiv eax,ecx0: kd> tcpip!Ipv6pUpdateRDNSS+0xa9:fffff806`4c34a66d 8b5304 mov edx,dword ptr [rbx+4]0: kd> r eaxeax=1Ipv6pUpdateRDNSS 函数执行完之后，偏移变成 0x28，正好指向了 18 22 ... 这个选项。0: kd> gutcpip!Ipv6pHandleRouterAdvertisement+0xb89a7:fffff806`4c292d4f 440fb77c2462 movzx r15d,word ptr [rsp+62h]0: kd> dt _net_buffer ffffdd06`6e29dea0ndis!_NET_BUFFER +0x000 Next : (null) +0x008 CurrentMdl : 0xffffdd06`68748d60 _MDL +0x010 CurrentMdlOffset : 0x28 +0x018 DataLength : 0x170 +0x018 stDataLength : 0x170 +0x020 MdlChain : 0xffffdd06`6a9c8180 _MDL +0x028 DataOffset : 0x88 +0x000 Link : _SLIST_HEADER +0x000 NetBufferHeader : _NET_BUFFER_HEADER +0x030 ChecksumBias : 0 +0x032 Reserved : 0 +0x038 NdisPoolHandle : 0xffffdd06`68531040 Void +0x040 NdisReserved : [2] (null) +0x050 ProtocolReserved : [6] 0x00000198`00000000 Void +0x080 MiniportReserved : [4] (null) +0x0a0 DataPhysicalAddress : _LARGE_INTEGER 0x0 +0x0a8 SharedMemoryInfo : (null) +0x0a8 ScatterGatherList : (null) 0: kd> dx -id 0,0,ffffdd0666892300 -r1 ((ndis!_MDL *)0xffffdd0668748d60)((ndis!_MDL *)0xffffdd0668748d60) : 0xffffdd0668748d60 [Type: _MDL *] [+0x000] Next : 0xffffdd066e8ea9b0 [Type: _MDL *] [+0x008] Size : 56 [Type: short] [+0x00a] MdlFlags : 4 [Type: short] [+0x00c] AllocationProcessorNumber : 0x0 [Type: unsigned short] [+0x00e] Reserved : 0x0 [Type: unsigned short] [+0x010] Process : 0x0 [Type: _EPROCESS *] [+0x018] MappedSystemVa : 0xffffdd0668748da0 [Type: void *] [+0x020] StartVa : 0xffffdd0668748000 [Type: void *] [+0x028] ByteCount : 0x30 [Type: unsigned long] [+0x02c] ByteOffset : 0xda0 [Type: unsigned long]0: kd> db 0xffffdd0668748da0+28ffffdd06`68748dc8 18 22 fd 81 00 00 03 84-00 f9 09 02 55 48 33 77 ."..........UH3wffffdd06`68748dd8 9e f9 09 f1 00 00 00 00-e0 8d 74 68 06 dd ff ff ..........th....ffffdd06`68748de8 90 26 3c 68 06 dd ff ff-10 86 74 68 06 dd ff ff .&ffffdd06`68748df8 80 85 74 68 06 dd ff ff-02 00 00 00 00 00 00 00 ..th............ffffdd06`68748e08 48 8e 74 68 06 dd ff ff-00 00 00 00 00 00 00 00 H.th............ffffdd06`68748e18 18 8e 74 68 06 dd ff ff-18 8e 74 68 06 dd ff ff ..th......th....ffffdd06`68748e28 00 00 00 00 00 00 00 00-b0 18 cd 68 06 dd ff ff ...........h....ffffdd06`68748e38 f0 c4 d1 66 06 dd ff ff-01 00 00 00 00 00 00 00 ...f............在下一次循环时，会对该选项进行解析，并按照 Route Information Option(其类型为 0x18)的流程进行处理。
0: kd> Breakpoint 0 hittcpip!Ipv6pHandleRouterAdvertisement+0x984:fffff806`4c1dad2c e89f33d7ff call ndis!NdisGetDataBuffer (fffff806`4bf4e0d0)0: kd> ptcpip!Ipv6pHandleRouterAdvertisement+0x989:fffff806`4c1dad31 0fb64801 movzx ecx,byte ptr [rax+1]0: kd> db raxffffdd06`68748dc8 18 22 fd 81 00 00 03 84-00 f9 09 02 55 48 33 77 ."..........UH3wffffdd06`68748dd8 9e f9 09 f1 00 00 00 00-e0 8d 74 68 06 dd ff ff ..........th....ffffdd06`68748de8 90 26 3c 68 06 dd ff ff-10 86 74 68 06 dd ff ff .&<h......th....ffffdd06`68748df8 80 85 74 68 06 dd ff ff-02 00 00 00 00 00 00 00 ..th............ffffdd06`68748e08 48 8e 74 68 06 dd ff ff-00 00 00 00 00 00 00 00 H.th............ffffdd06`68748e18 18 8e 74 68 06 dd ff ff-18 8e 74 68 06 dd ff ff ..th......th....ffffdd06`68748e28 00 00 00 00 00 00 00 00-b0 18 cd 68 06 dd ff ff ...........h....ffffdd06`68748e38 f0 c4 d1 66 06 dd ff ff-01 00 00 00 00 00 00 00 ...f............在 case 0x18 中，直接调用 NdisGetDataBuffer 函数向栈上复制大量数据(由于数据不连续并且指定了Storage 参数为栈上的地址)，函数执行完之后，栈被破坏且复制到栈上的数据完全可控。
0: kd> tcpip!Ipv6pHandleRouterAdvertisement+0xb8a08:fffff806`4c292db0 e81bb3cbff call ndis!NdisGetDataBuffer (fffff806`4bf4e0d0)0: kd> r r8 // Storage 参数r8=fffff8064ad237180: kd> r rsprsp=fffff8064ad234600: kd> ptcpip!Ipv6pHandleRouterAdvertisement+0xb8a0d:fffff806`4c292db5 660f6f0553e50d00 movdqa xmm0,xmmword ptr [tcpip!_xmm (fffff806`4c371310)]0: kd> k # Child-SP RetAddr Call Site00 fffff806`4ad23460 42424242`42424242 tcpip!Ipv6pHandleRouterAdvertisement+0xb8a0d01 fffff806`4ad23810 84030000`00000519 0x42424242`4242424202 fffff806`4ad23818 41414141`41414141 0x84030000`0000051903 fffff806`4ad23820 41414141`41414141 0x41414141`4141414104 fffff806`4ad23828 00000000`00000000 0x41414141`41414141最终在 Ipv6pHandleRouterAdvertisement 函数返回时由于 cookie 检查不通过，触发蓝屏。
0: kd> tcpip!Ipv6pHandleRouterAdvertisement+0x10ea:fffff806`4c1db492 e869f70800 call tcpip!_security_check_cookie (fffff806`4c26ac00)0: kd> pKDTARGET: Refreshing KD connection*** Fatal System Error: 0x00000139 (0x0000000000000002,0xFFFFF8064AD232C0,0xFFFFF8064AD23218,0x0000000000000000)WARNING: This break is not a step/trace completion.The last command has been cleared to preventaccidental continuation of this unrelated event.Check the event, location and thread before resuming.Break instruction exception - code 80000003 (first chance)A fatal system error has occurred.Debugger entered on first try; Bugcheck callbacks have not been invoked.A fatal system error has occurred.For analysis of this file, run !analyze -vnt!DbgBreakPointWithStatus:fffff806`497cf7e0 cc int 30: kd> k # Child-SP RetAddr Call Site00 fffff806`4ad227f8 fffff806`498add92 nt!DbgBreakPointWithStatus01 fffff806`4ad22800 fffff806`498ad487 nt!KiBugCheckDebugBreak+0x1202 fffff806`4ad22860 fffff806`497c7a97 nt!KeBugCheck2+0x94703 fffff806`4ad22f60 fffff806`497d9829 nt!KeBugCheckEx+0x10704 fffff806`4ad22fa0 fffff806`497d9c50 nt!KiBugCheckDispatch+0x6905 fffff806`4ad230e0 fffff806`497d7fe3 nt!KiFastFailDispatch+0xd006 fffff806`4ad232c0 fffff806`4c26ac35 nt!KiRaiseSecurityCheckFailure+0x32307 fffff806`4ad23458 fffff806`4c1db497 tcpip!_report_gsfailure+0x508 fffff806`4ad23460 42424242`42424242 tcpip!Ipv6pHandleRouterAdvertisement+0x10ef09 fffff806`4ad23810 84030000`00000519 0x42424242`424242420a fffff806`4ad23818 41414141`41414141 0x84030000`000005190b fffff806`4ad23820 41414141`41414141 0x41414141`414141410c fffff806`4ad23828 00000000`00000000 0x41414141`41414141以下为补丁前后对比，其中，v29 和 v32 来自于 length << 3，补丁前只判断了 length 长度是不是大于等于 3，补丁后加入了对 length 值奇偶的校验，如果 length 为偶数，则会转入错误流程。
补丁前
补丁后
产品线解决方案
奇安信网神天堤防火墙产品防护方案
奇安信新一代智慧防火墙(NSG3000/5000/7000/9000系列)和下一代极速防火墙(NSG3500/5500/7500/9500系列)产品系列，已通过更新IPS特征库完成了对该漏洞的防护。建议用户尽快将IPS特征库升级至“2010141000”及以上版本并启用规则ID: 1227101进行检测防御。
奇安信天眼产品解决方案
奇安信天眼新一代威胁感知系统在第一时间加入了该漏洞的检测规则，请将规则包升级到3.0.1014.12434及以上版本。规则名称：Windows TCP/IP 远程代码执行漏洞(CVE-2020-16898)，规则ID：0x5d84。奇安信天眼流量探针(传感器)升级方法：系统配置->设备升级->规则升级，选择“网络升级”或“本地升级”。
奇安信网神网络数据传感器系统产品检测方案
奇安信网神网络数据传感器(NDS3000/5000/9000系列)产品，已具备该漏洞的检测能力。规则ID为：51549，建议用户尽快升级检测规则库至2010141012以后版本并启用该检测规则。
参考资料
[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898
[2] https://www.mcafee.com/blogs/other-blogs/mcafee-labs/cve-2020-16898-bad-neighbor/
时间线
2020年10月14日，奇安信 CERT发布安全风险通告
2020年10月17日，奇安信 CERT发布安全风险通告第二次更新
奇安信 CERT
奇安信CERT致力于
第一时间为企业级客户提供
安全风险通告和有效的解决方案
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
