APT重试机制为何放大供应链风险?

APT 的重试机制通常被当作一个提升下载成功率的参数，但在下载验证绕过类漏洞中，它改变的不只是成功率，还有攻击者可利用的窗口数量。CVE-2026-109518 的公开信息描述的正是这样一条链条：攻击者位于路径上，借助恶意镜像或代理，在 APT 完成包检查之后替换 .deb，安装时以 root 执行包内脚本。这个“检查之后、安装之前”的时间差是漏洞成立的基础，而重试机制会把这个时间差复制成多份。

原因在于重试的本质是重新发起获取。每一次重试都意味着系统再次经历下载、校验、落盘的完整流程，也就多出一个可被干预的时机。单次下载时，路径上的攻击者需要在狭窄的窗口内完成替换；当重试存在时，窗口随着尝试次数成倍延展。更值得警惕的是触发条件：302 重定向或 503 临时错误本身就可以由同一位置的攻击者制造。先抛出一个临时错误，逼出重试，再在重试响应里投放替换包，重试机制就成了攻击节奏的控制器，而不是单纯的概率提升。

这一点之所以重要，是因为暴露并不依赖运维误配。Ubuntu 官方公告明确指出，22.04 LTS 及更新版本默认受影响，较旧版本仅在 Acquire::Retries 设置为非零时才受影响；Debian 侧的公开分析也把 Debian 12 及更新版本列为默认启用重试。也就是说，大量系统在默认配置下就已经站在风险链条上，管理员甚至从未主动调整过这个参数。

判断风险时，孤立地问“有没有漏洞”意义有限，更有效的是看四个条件是否同时成立：系统到软件源之间是否存在可被操纵的 HTTP 段，目标是否正处于下载或安装窗口，Acquire::Retries 是否非零或按发行版默认为非零，以及被替换的包能否在完整性校验之后进入安装路径。四项缺一，链条就无法闭环；四项齐全，替换才可能真正落地。对应的可观察证据也很具体：源列表里的协议、自动更新定时器的活跃状态、apt-config 输出的重试取值、实际下载文件哈希与索引中 SHA256 是否一致。

整改顺序应遵循“先缩小暴露面，再修补自身”的原则。先确认镜像是否支持 HTTPS 并逐条迁移源地址，限制 APT 出站到受控镜像或代理，避免流量经过不受控节点；再升级 APT 到修复版本，Ubuntu 侧公开的修复版本包括 22.04 LTS 的 2.4.15ubuntu0.1、24.04 LTS 的 2.8.4ubuntu0.1 和 20.04 LTS 的 2.0.12+esm1，Debian 侧则以安全公告为准。升级后仍需回归验证，而不是跑一次安装就结束。监控侧应把 APT 日志中的重试记录、302 或 503 响应、异常包 URL，以及实际哈希与索引哈希不一致的情况纳入日常告警。

重试本身不是缺陷，它解决的是网络抖动下的可用性问题。但在校验与使用之间存在时间差的场景里，它客观上把一次机会变成了多次机会。把重试配置和传输协议、仓库信任、APT 版本放在一起评估，才能得出接近真实的风险结论；单独看其中任何一项，都容易低估这条链条的完整程度。