漏洞修复记录

凌晨两点十七分，漏洞安全组老周在群里甩了张截图——某台边缘节点的修复Nginx日志里，出现了连续十七次路径穿越尝试。记录目标文件是漏洞/etc/passwd。攻击载荷没加密，修复明晃晃的记录../../../../，像在自家后院散步。漏洞

这不是修复第一次。上周同一套业务系统刚补过Spring框架的记录RCE漏洞，补丁编号CVE-2024-22243。漏洞当时运维图省事，修复只重启了主集群，记录边缘节点没动。漏洞老周骂了句脏话，修复把截图圈出来：“又是记录那台没重启的。”

修复动作很快。凌晨两点四十分，防火墙先封了源IP段，临时规则只放行内部监控探针。三点零二分，运维登机器确认Nginx版本——1.22.1，编译参数里--with-http_dav_module没关，这模块默认允许DAV方法，配合路径穿越能读任意文件。三点十五分，热更新配置：location ~ /\.\./ { deny all; }，同时把dav_methods注释掉。没重启，nginx -s reload生效。三点四十分，老周写了个临时脚本，扫全集群的Nginx配置，又揪出三台同样编译参数的机器。

天亮后复盘，问题不在补丁本身。Spring那个洞修得没问题，但边缘节点用的是另一套镜像，构建流水线没同步更新。运维以为“重启主集群就等于全量修复”，实际漏了Kubernetes里一个叫edge-worker的DaemonSet，它跑在老旧的CentOS 7上，内核版本3.10，连unshare系统调用都被seccomp挡着，容器里根本跑不了新版补丁的验证脚本。

这事有意思的地方在于：漏洞修复从来不是“打补丁”三个字能概括的。你得知道补丁生效的前提条件。比如这次，Nginx的路径穿越修复依赖merge_slashes和disable_symlinks两个指令的配合，而disable_symlinks在Linux上要求内核支持openat2——CentOS 7的内核太老，这指令直接静默失效。运维以为配置写对了，实际Nginx启动时在error.log里留了一行disable_symlinks is not supported，没人看。

后来我们改了流程。补丁上线前，先跑一个叫patch-verify的脚本，它干三件事：检查目标机器内核版本、检查依赖库版本、模拟攻击载荷发一次请求看是否被拦截。脚本是Python写的，不到两百行，但比任何“修复完成”的邮件都管用。上周它拦下一个OpenSSH的补丁——那台机器的glibc版本太旧，新补丁编译出来的二进制跑不起来，直接segfault。

老周现在有个习惯：每次修完漏洞，在Jira工单里贴三样东西——修复前的curl请求截图、修复后的curl返回码、以及strace抓到的系统调用记录。他说这叫“证据链”，不是给领导看的，是给三个月后的自己看的。因为三个月后你只会记得“修过”，不会记得“怎么修的”。

昨天又有个新漏洞，CVE-2024-3094，xz后门。这次没人慌。安全组先跑patch-verify，发现所有节点都不满足触发条件——xz版本低于5.6.0。但老周还是把检查脚本加进了CI流水线，每次构建镜像时自动跑一遍。他说：“漏洞修不完的，但你可以让自己修得越来越快。”

凌晨的群消息现在安静了。偶尔有人发个curl截图，配一句“这个路径穿越被拦了”。没人点赞，但大家都知道——那条规则是两点十七分那晚加上的。