NetScaler：握手分片怎样写出了内存边界

1 为什么没登录也能走到这里

DTLS 可以理解为运行在 UDP 上的加密通信协议。UDP 数据包可能丢失、乱序，一条较长的握手消息也可能被拆成多片。接收端因此要记住每片属于哪条消息、应该放在哪里，等缺少的部分到齐后继续协商。RFC 6347 的握手格式分别设置了完整消息长度 length、消息编号 message_seq、分片位置 fragment_offset 和本片长度 fragment_length。这些字段回答的是不同问题。

例如，一条 8 字节的消息分成两片，第一片覆盖位置 0 到 3，第二片覆盖 4 到 7，接收端便能判断内容已经收齐。内存里保存的字节却可能更多，因为实现还会留下记录头、内部缓冲结构或暂存内容。接下来复制数据时，程序需要知道自己搬的是哪一部分。

DTLS 还有一层 cookie 往返：服务器发回一个值，请客户端带着它再来。协议对这一步的用途说得很清楚，它帮助确认请求方能接收到该地址上的响应，减少伪造源地址造成的资源消耗。一个能正常收发网络包的人也能完成往返；员工账号验证仍在后面。排查时应沿着数据包到达的路径找入口。

Citrix 的 正式公告给出的前提是启用 DTLS，VPN 虚拟服务器默认开启。配置里没出现大写的 DTLS，也可能满足这个条件：一条普通的 SSL VPN 虚拟服务器配置，如果没有显式关闭 DTLS，就仍使用默认值。还有独立的 DTLS 类型虚拟服务器和负载均衡服务。因此，简单搜索一个关键词容易漏掉默认配置，应该逐个核对虚拟服务器的实际状态和网络可达范围。

2 消息收齐以后，复制量却失去了约束

watchTowr 比较 14.1-73.30 与 14.1-73.37后，找到了 Packet Engine 的 nsppe 中的一次复制：程序沿着链式 NetScaler Buffer（NSB）取出内容，汇入一块 0x8c00，也就是 35,840 字节的缓冲区。旧循环没有逐项检查剩余空间，补丁在每次复制前补上了容量判断。厂商没有公开源码函数名和行号；以下设备机制来自这份固件差异分析，SOSEC 未取得固件或独立复现设备代码执行。

公开研究给出了一组能说明问题的输入。完整消息声明只有 120 字节，每片只让重组进度前进 1 字节，相应的 NSB 节点却保留了远多于 1 字节的记录内容。120 个位置填满后，程序认为消息已经收齐，接着沿链复制各节点保留的内容。它此时搬运的是节点中的实际字节，累计值可以远超先前用于判断进度的 120 字节；目标缓冲区的容量却始终只有 35,840 字节。

所以，分片收齐后仍要检查每次写入是否装得下。合法分片同样需要这项检查，重传造成的重叠则应按协议处理；直接拒绝所有重叠会伤到正常通信。

越界写入之后会发生什么，取决于旁边是什么内存、写进去的内容能否控制，以及后续代码怎样使用被破坏的状态。崩溃是其中一种结果；厂商确认的影响还包括远程代码执行。对运营者，这意味着不能把一次异常重启只归为可用性故障，也不能从一次重启直接推定已经执行了攻击者代码。需要保留现场，再把异常时间与连接、进程及文件变化关联起来。

3 修补应守住每一次写入

下面用一个独立的小模型说明容量检查应放在哪里。它只处理整数，没有网络请求，也不模拟 NetScaler 报文。假定目标容量为 64 字节，已经保存的头部占 8 字节，余下空间必须容纳每个待复制块。所有长度都是已验证的非负整数：

def fits(capacity, header_size, chunks):
    if header_size > capacity:
        return False
    remaining = capacity - header_size
    for size in chunks:
        if size > remaining:
            return False
        remaining -= size
    return True

assert fits(64, 8, [20, 20, 16])
assert not fits(64, 8, [20, 20, 17])
assert not fits(64, 65, [])

第一组刚好用满：8 + 20 + 20 + 16 = 64。第二组只多一个字节，就应在第三次复制开始前拒绝。第三组连头部都装不下，应在处理内容之前拒绝。SOSEC 在本地运行了这三项断言，结果均通过；这验证的是模型里的预算关系，设备补丁是否正确还需要厂商实现和设备测试。

这个写法还有一个容易忽略的好处：先比较当前块与剩余空间，再做减法。用固定宽度整数编写底层代码时，如果先累加多个外部长度，再拿总和比较容量，总和本身可能已经回绕。实现者还要保证长度没有负值、指针范围有效、失败路径能释放暂存状态，以及检查使用的长度与最终复制使用的长度完全相同。只要两处又各取一个数字，同类错误就可能留下来。

回归测试应让正常单片、多片和恰好装满的消息通过，让多一个字节的输入在写入前被拒绝；重复、乱序和重叠分片按协议处理，中断或拒绝后仍能建立下一条正常连接。这些检查应在隔离环境进行；一个能让旧设备崩溃的样例只覆盖其中一种结果，拿它试生产网关还会中断业务。

4 管理员现在该改哪一处

先找出自行管理的 NetScaler 实例，包括备用节点和 Secure Private Access Hybrid 中的实例；Citrix 管理的云服务由厂商更新。对旧版本且 DTLS 可达的服务，尽快安排修补。暂时关闭相关 DTLS 服务或在受控网络边界阻断其 UDP 入口，可以收窄这项漏洞的暴露；远程访问的性能和可用性可能随之改变，是否回退到其他传输必须按实际客户端验证。同一公告中的 88771 仍需升级处理。

截至 9 月 30 日，官方下载页普通分支列出的修复目标为 14.1-73.37 和 13.1-64.24。各分支按自己的发布线选择，不能把普通包替换到 FIPS 或 NDcPP 环境：

13.1 应选 13.1-64.24，因为 13.1-64.23 在配置过变量的部署中会循环重启。Citrix 的补充说明给出了这个条件，可用只读命令 show ns variable 检查。升级还会要求签名的 SAML assertion，应提前确认身份提供方配置，避免安全更新完成后员工无法登录。15.1 Technology Preview 当时仍受影响，厂商也未许可用于生产。

扫描结果可能与这张包表不一致。截至 2026 年 9 月 30 日 04:07 UTC，NVD 已完成分析，但其 14.1 FIPS 机器可读范围仍把修复版 14.1-73.37 列为受影响端点，与厂商公告和 NetScaler CNA冲突。修补版本应按厂商包表核对。评分也有两套：NIST 的 CVSS 3.1 为 8.1，CNA 的 CVSS 4.0 为 9.5，不能把不同标准的数字当成严重性的升降。

验收应从自己的正常业务开始：逐节点核对实际运行版本、主备状态、预期的 DTLS 开关，完成一次合法登录及应用访问，再检查进程稳定性和日志。保留需要的临时限制，直到这些检查结束。如果升级失败，继续隔离未修节点；普通 13.1 环境本次回退也优先使用 13.1-64.24，避免把已知循环重启风险带回来。其他分支不得退回各自首次修复版本之前。确有业务原因只能启动旧版本时，应保持隔离，由应急负责人决定后续恢复。

5 补上入口之后，还要查之前发生过什么

已知利用让这次升级多了一项责任：检查旧设备在暴露期间是否被进入。Citrix 的疑似入侵处置指南要求保全时间信息、日志和必要的实例或磁盘证据，再隔离、调查、重建。Packet Engine core 的采集会引发 warm restart 并断开 SSH，安排前要清楚它对现场和业务的影响。外部 syslog 中保留下来的记录也应一起保存。

如果发现入侵迹象，恢复工作需要覆盖设备接触过的身份和系统：调查关联认证服务，撤销可能泄露的凭据、证书和私钥，从可信介质重建，再恢复入侵前的可靠配置并轮换秘密。Citrix 提供的 IOC 检查可以辅助判断，覆盖范围随检测逻辑更新而变化；一次无命中仍留下未覆盖行为的调查空间。记录检测版本与时间，才能知道这次检查实际回答了多少问题。