网络安全领域再传警报。知名安全研究员 Marcus Hutchins 近日披露了一个潜伏在 Comodo Internet Security 防火墙驱动中的严重缺陷——这个被命名为ComoDoS的零日漏洞能让远程攻击者仅凭一个精心构造的 IPv6 数据包就直接让目标 Windows 系统陷入崩溃而且全程绕过所有防火墙规则。更令业界担忧的是Comodo 方面在收到多次漏洞披露后至今没有任何回应。Marcus Hutchins 已经向 Comodo 安全团队提交了完整的根本原因分析、补丁建议以及概念验证代码但截至目前官方补丁仍然遥遥无期。防火墙驱动里的阿喀琉斯之踵问题的根源藏在Inspect.sys这个内核级防火墙驱动里。作为 Comodo Internet Security 的核心组件它负责在数据包进入系统时进行深度检测决定哪些流量可以放行、哪些应当拦截。IPv6 协议在设计时引入了扩展头机制——这些可选头部串联在固定的 40 字节 IPv6 基础头部和上层协议如 TCP、UDP之间用于携带路由提示、分片信息、目的地选项等附加数据。Inspect.sys 在解析这些扩展头时会从 IPv6 固定头部读取payload_length字段然后逐个遍历扩展头将每个头的长度从该变量中扣除。这本身是一个常规的解析流程但代码中却遗漏了最关键的一步从未验证 payload_length 的合理性。如果攻击者故意把 IPv6 的载荷长度设得比所有扩展头的总长度还要小那个无符号 64 位的payload_length变量就会发生灾难性的整数下溢——数值从 0 直接回绕到约18.4 万亿亿0xFFFFFFFFFFFFFFF8。这个荒谬的超大数值随后被用于内存操作直接触发内核崩溃也就是我们熟悉的 Windows 蓝屏死机BSOD。防火墙规则形同虚设这个漏洞最棘手的地方在于它的穿透性。防火墙驱动必须先完成 TCP/IP 头部的解析才能根据端口、协议、方向等条件判断是否执行拦截。而 ComoDoS 的攻击恰恰发生在解析阶段——无论你把所有端口封得多么严实数据包都会在规则生效之前就把系统搞崩溃。换句话说传统的端口封锁、入站规则、IP 黑名单对这类攻击完全无效。攻击者不需要和目标建立任何合法连接也不需要目标开放特定端口一个孤零零的 IPv6 数据包飞过来系统就直接躺平。Marcus Hutchins 在 PoC 中特意选用了目标选项扩展头Destination Options Header类型 60原因很实际这种扩展头在路由器层面的过滤最少恶意数据包穿越互联网到达目标的成功率最高。四行 Python 代码就能让系统崩溃概念验证的简洁程度令人咋舌。利用 Scapy 库整个攻击代码仅需寥寥数行Pythonext IPv6ExtHdrDestOpt(nh6, options[PadN(optdatab\x00 * 8)]) tcp TCP(sport1337, dport80, flagsS, seq0, ack1, window0x2000) ipv6 IPv6(dstdst_ip, nh60, hlim64, plen8) pkt ipv6 / ext / tcp send(pkt)plen8把载荷长度压到极低而扩展头本身的长度却超过了这个值。两者一相减下溢瞬间发生。接下来的内核内存操作因为拿到了一个近乎无限大的长度值直接触发页面错误系统以 DISPATCH_LEVEL 级别崩溃连容错的机会都没有。不止蓝屏同一下溢还埋着更深的隐患除了稳定的远程拒绝服务攻击DoS原语Marcus Hutchins 还在同一下溢路径中发现了两种更复杂的内存损坏可能。越界读取OOB Read发生在 WebDAV/HTTP 工件扫描器内部。下溢后的超大长度值在这里被截断为 16 位上限约 65 KB。虽然数值被砍了一刀但非法的内存访问仍然会导致页面错误系统照样崩溃。越界写入OOB Write则需要先完成完整的 TCP 三次握手才能触发。这条路径把下溢值截断为 32 位产生的内核池溢出高达4 GB。考虑到标准网络数据包的最大尺寸只有 65 KB目前几乎没有办法把溢出控制到刚好不崩溃的程度。这意味着虽然从理论上存在进一步利用的空间但远程代码执行RCE在当前条件下可行性极低。从旧版驱动里找到的线索这个漏洞的发现过程本身也值得一提。Marcus Hutchins 当时正在研究 BYOVDBring Your Own Vulnerable Driver自带易受攻击驱动攻击面并借助 AI 辅助分析流程对多款安全软件的驱动进行审计。在检查 Comodo 的旧版驱动时他注意到了一些架构层面的设计缺陷。这些发现促使他对手头的最新版 Inspect.sys 进行人工深度分析最终锁定了 IPv6 扩展头解析器中的这个整数下溢问题。可以说AI 辅助筛查提供了方向而人工的精细审查才挖出了真正的炸弹。在补丁到来之前企业能做些什么由于官方补丁尚未发布依赖 Comodo Internet Security 的组织需要采取一些临时措施来降低风险监控异常 IPv6 流量重点关注包含畸形扩展头的数据包尤其是目标选项头Type 60出现的频率和来源。网络层过滤在边界路由器或防火墙上配置规则丢弃格式异常的 IPv6 扩展头数据包尽可能在入口端就把恶意流量掐掉。评估替代方案对于安全要求极高的环境在补丁发布前可以考虑临时调整端点防护策略或部署额外的网络入侵检测层。
Comodo Internet Security 曝高危零日漏洞 ComoDoS:单个 IPv6 数据包即可触发 Windows 蓝屏死机
发布时间:2026/6/7 23:36:21
网络安全领域再传警报。知名安全研究员 Marcus Hutchins 近日披露了一个潜伏在 Comodo Internet Security 防火墙驱动中的严重缺陷——这个被命名为ComoDoS的零日漏洞能让远程攻击者仅凭一个精心构造的 IPv6 数据包就直接让目标 Windows 系统陷入崩溃而且全程绕过所有防火墙规则。更令业界担忧的是Comodo 方面在收到多次漏洞披露后至今没有任何回应。Marcus Hutchins 已经向 Comodo 安全团队提交了完整的根本原因分析、补丁建议以及概念验证代码但截至目前官方补丁仍然遥遥无期。防火墙驱动里的阿喀琉斯之踵问题的根源藏在Inspect.sys这个内核级防火墙驱动里。作为 Comodo Internet Security 的核心组件它负责在数据包进入系统时进行深度检测决定哪些流量可以放行、哪些应当拦截。IPv6 协议在设计时引入了扩展头机制——这些可选头部串联在固定的 40 字节 IPv6 基础头部和上层协议如 TCP、UDP之间用于携带路由提示、分片信息、目的地选项等附加数据。Inspect.sys 在解析这些扩展头时会从 IPv6 固定头部读取payload_length字段然后逐个遍历扩展头将每个头的长度从该变量中扣除。这本身是一个常规的解析流程但代码中却遗漏了最关键的一步从未验证 payload_length 的合理性。如果攻击者故意把 IPv6 的载荷长度设得比所有扩展头的总长度还要小那个无符号 64 位的payload_length变量就会发生灾难性的整数下溢——数值从 0 直接回绕到约18.4 万亿亿0xFFFFFFFFFFFFFFF8。这个荒谬的超大数值随后被用于内存操作直接触发内核崩溃也就是我们熟悉的 Windows 蓝屏死机BSOD。防火墙规则形同虚设这个漏洞最棘手的地方在于它的穿透性。防火墙驱动必须先完成 TCP/IP 头部的解析才能根据端口、协议、方向等条件判断是否执行拦截。而 ComoDoS 的攻击恰恰发生在解析阶段——无论你把所有端口封得多么严实数据包都会在规则生效之前就把系统搞崩溃。换句话说传统的端口封锁、入站规则、IP 黑名单对这类攻击完全无效。攻击者不需要和目标建立任何合法连接也不需要目标开放特定端口一个孤零零的 IPv6 数据包飞过来系统就直接躺平。Marcus Hutchins 在 PoC 中特意选用了目标选项扩展头Destination Options Header类型 60原因很实际这种扩展头在路由器层面的过滤最少恶意数据包穿越互联网到达目标的成功率最高。四行 Python 代码就能让系统崩溃概念验证的简洁程度令人咋舌。利用 Scapy 库整个攻击代码仅需寥寥数行Pythonext IPv6ExtHdrDestOpt(nh6, options[PadN(optdatab\x00 * 8)]) tcp TCP(sport1337, dport80, flagsS, seq0, ack1, window0x2000) ipv6 IPv6(dstdst_ip, nh60, hlim64, plen8) pkt ipv6 / ext / tcp send(pkt)plen8把载荷长度压到极低而扩展头本身的长度却超过了这个值。两者一相减下溢瞬间发生。接下来的内核内存操作因为拿到了一个近乎无限大的长度值直接触发页面错误系统以 DISPATCH_LEVEL 级别崩溃连容错的机会都没有。不止蓝屏同一下溢还埋着更深的隐患除了稳定的远程拒绝服务攻击DoS原语Marcus Hutchins 还在同一下溢路径中发现了两种更复杂的内存损坏可能。越界读取OOB Read发生在 WebDAV/HTTP 工件扫描器内部。下溢后的超大长度值在这里被截断为 16 位上限约 65 KB。虽然数值被砍了一刀但非法的内存访问仍然会导致页面错误系统照样崩溃。越界写入OOB Write则需要先完成完整的 TCP 三次握手才能触发。这条路径把下溢值截断为 32 位产生的内核池溢出高达4 GB。考虑到标准网络数据包的最大尺寸只有 65 KB目前几乎没有办法把溢出控制到刚好不崩溃的程度。这意味着虽然从理论上存在进一步利用的空间但远程代码执行RCE在当前条件下可行性极低。从旧版驱动里找到的线索这个漏洞的发现过程本身也值得一提。Marcus Hutchins 当时正在研究 BYOVDBring Your Own Vulnerable Driver自带易受攻击驱动攻击面并借助 AI 辅助分析流程对多款安全软件的驱动进行审计。在检查 Comodo 的旧版驱动时他注意到了一些架构层面的设计缺陷。这些发现促使他对手头的最新版 Inspect.sys 进行人工深度分析最终锁定了 IPv6 扩展头解析器中的这个整数下溢问题。可以说AI 辅助筛查提供了方向而人工的精细审查才挖出了真正的炸弹。在补丁到来之前企业能做些什么由于官方补丁尚未发布依赖 Comodo Internet Security 的组织需要采取一些临时措施来降低风险监控异常 IPv6 流量重点关注包含畸形扩展头的数据包尤其是目标选项头Type 60出现的频率和来源。网络层过滤在边界路由器或防火墙上配置规则丢弃格式异常的 IPv6 扩展头数据包尽可能在入口端就把恶意流量掐掉。评估替代方案对于安全要求极高的环境在补丁发布前可以考虑临时调整端点防护策略或部署额外的网络入侵检测层。