RCE漏洞

2021年12月，Log4j2爆出JNDI注入漏洞，全球超过一亿台服务器在几天内被迫紧急打补丁。攻击者只需要往日志里发一段特定字符串，就能让目标机器从远程加载并执行任意代码。这就是RCE——远程代码执行。它不需要你下载文件、不需要你点击确认，一段文本就够了。

RCE的本质，是攻击者找到了一个入口，让目标系统把"数据"当成了"代码"来跑。数据本来是死的，代码是活的。一旦这个边界被打破，机器就变成了别人的提线木偶。

很多人觉得RCE离自己很远，觉得那是黑客电影里的桥段。但实际情况是，RCE漏洞的成因往往极其朴素。举几个真实场景：

某个Web应用的文件上传功能，只检查了文件后缀名是不是.jpg，但没管文件内容。攻击者把一段PHP代码写进图片文件，上传后通过路径拼接直接访问，服务器就把这段PHP当代码执行了。后缀检查？形同虚设。

再比如，某接口的参数直接拼进了系统命令——ping $ip。正常用户传个IP地址，攻击者传的是127.0.0.1; cat /etc/passwd。分号后面的命令，服务器照单全收。

还有反序列化。Java、PHP、Python都有序列化机制，把对象变成字节流存储或传输。如果反序列化的数据可以被攻击者控制，他就能构造一条"魔法链"，让目标在还原对象的过程中触发一系列方法调用，最终执行任意命令。Log4j那个漏洞就是这条路径的经典案例——JNDI lookup把远程的恶意类拉进来实例化，实例化的过程就是执行的过程。

我观察到的一个规律是：RCE漏洞很少是单一错误造成的。它通常是两三个"看起来不严重"的问题叠加的结果。一个参数校验缺失，加上一个权限控制不严，再加上一个框架的默认配置——单独看每个都能忍，叠在一起就是灾难。安全圈有个说法叫"漏洞链"，说的就是这个。

防御层面，说几个实际有效的做法。参数化查询能挡掉注入类问题，这个大家都知道，但很多人不知道的是——命令执行场景下，白名单比黑名单靠谱得多。黑名单永远在追着攻击者的新姿势跑，白名单只允许已知安全的字符和格式，攻击面直接收窄。

反序列化这块，能不用就不用。非要用，加签名校验，确保数据没被篡改。JNDI的话，新版本JDK已经默认禁了远程codebase加载，但老系统还在跑，这才是真正头疼的地方。

还有一点容易被忽略：RCE的利用不一定需要复杂的技术。有时候一个配置错误就够了。比如开发环境留了个debug接口，上线没关；比如某个管理后台的默认密码没改；比如容器里跑着root权限的进程。这些不是"漏洞"，但它们是RCE的加速器。

写到这里我想说，RCE之所以让人头疼，不是因为它技术含量高，恰恰相反——它的门槛在降低。自动化利用工具越来越成熟，攻击者不需要理解底层原理，拿现成的payload打就行了。防守方要补的洞，永远比攻击方要找的口子多。

一个现实：你不可能把所有RCE都堵死。但你可以让攻击成本变高。输入校验、最小权限、及时打补丁、别把内部接口暴露在公网——这些老生常谈的事做到位，就能筛掉大部分机会主义者。剩下的那些盯着你打的，那就是另一场游戏了。