apache漏洞

2021年12月，漏洞Apache Log4j2 的漏洞一个JNDI lookup功能被爆出远程代码执行漏洞，编号CVE-2021-44228。漏洞那个周末，漏洞全球安全圈几乎没人睡觉。漏洞运维群里消息刷得飞快，漏洞有人连夜升级版本，漏洞有人直接在下游服务里加了过滤规则。漏洞一个日志组件，漏洞把半个互联网搅得鸡飞狗跳。漏洞

这事说出来挺荒诞的漏洞。Log4j 只是漏洞用来记日志的——谁会把一个记日志的东西当成攻击入口？但偏偏它支持 ${ jndi:ldap://...} 这种表达式解析，攻击者只要在能被记录的漏洞内容里注入这段字符串，比如在User-Agent里、漏洞在用户名里、漏洞在一个聊天消息里，服务器就会乖乖去连接攻击者指定的LDAP服务，加载远程class文件，执行任意代码。整个过程不需要任何认证。

我后来在本地搭了个环境复现。写一行 logger.error("${ jndi:ldap://127.0.0.1:1389/exploit}");，启动一个恶意的LDAP服务，几秒钟后，弹出一个计算器。那一刻的感觉很复杂——既觉得这个漏洞设计得太离谱，又不得不承认，它暴露的是整个Java生态里长期被忽视的信任边界问题。

Apache 基金会那几周的补丁节奏也够呛。2.15.0 修了JNDI，但没修干净；2.16.0 直接禁用了JNDI，又引入了新的DoS问题；2.17.0 才算把主要面都堵上。企业这边更惨，很多老系统跑的还是 Log4j 1.x，根本不在官方支持范围内，只能自己打补丁或者硬隔离。

Log4j 不是 Apache 唯一的坑。往前翻，Struts2 的 OGNL 表达式注入从 2013 年一直修到 2020 年，S2-045、S2-048、S2-052……每隔一段时间就来一次。原因也类似：框架为了方便开发者，开放了过于强大的表达式解析能力，但没有对输入做足够的约束。攻击者总能找到绕过过滤的办法。

Apache HTTP Server 也没少出事。2021年的 CVE-2021-41773 是个路径穿越漏洞，攻击者可以通过构造特殊的URL读取服务器上的任意文件。这个漏洞的成因是路径规范化处理不完整。补丁发布后没几天，就有人发现补丁可以被绕过，又出了 CVE-2021-42013。这种“补丁绕过再补”的循环，在 Apache 项目里不算罕见。

我的看法是，Apache 项目的安全问题不能简单归结为“代码质量差”。这些项目大多有二十年以上的历史，代码库庞大，贡献者众多，很多模块的设计决策是在当年的环境下做出的。Log4j 的JNDI lookup功能在2001年加入时，JNDI本身还是个相对安全的本地服务发现机制，没人预料到二十年后它会变成远程代码执行的跳板。技术债这种东西，平时不显眼，一旦被攻击者盯上，就是连锁反应。

对普通开发者来说，能做的事情其实很具体。依赖版本别锁死，定期跑 mvn dependency:tree 看看有没有引入过时的Apache组件。生产环境里，日志组件的配置尽量收紧，能关的lookup就关掉。WAF规则该加就加，虽然绕过的办法总会有，但至少能挡住大部分扫描器。最重要的是，别觉得“我只是个写业务的，安全不关我事”——Log4j 那次，写业务的人也被迫在周末加班。

Apache 软件基金会后来成立了专门的security team，响应速度比之前快了不少。但开源项目的安全，终究不能只靠几个维护者熬夜打补丁。用的人越多，责任就越分散，这大概就是开源生态的悖论。