microsoft windows smb 输入验证漏洞

2024年3月，入验微软发布了一个补丁，证漏编号CVE-2024-21334，入验修的证漏是Windows SMB协议里的一个输入验证漏洞。这个漏洞允许攻击者在特定条件下通过构造恶意SMB请求，入验让目标机器蓝屏，证漏或者更糟——在某些配置下执行任意代码。入验我拿到这个补丁的证漏分析报告时，第一反应是入验：又来了。

SMB，证漏Server Message Block，入验从Windows 3.11时代就存在的证漏东西。三十多年了，入验它依然是证漏Windows网络文件共享的核心。你打开"网上邻居"，入验访问共享文件夹，打印机共享，域控通信，背后全是SMB在跑。问题是，这个协议太老了，老到它的设计假设在今天看来几乎是天真的——它默认网络是可信的，默认客户端不会发疯。

这次漏洞的根子在SMB 2.0的压缩消息处理上。微软在Windows 8里给SMB加了压缩功能，本意是减少大文件传输的带宽占用。但压缩数据的解压逻辑里，对输入长度的校验写得不够严。攻击者可以构造一个压缩消息，声明一个长度，实际数据却是另一个长度。解压引擎按声明的长度去读，读到了不该读的内存。

听起来很抽象？换个说法。你给快递员一个箱子，说里面是10件衣服。快递员按10件去拆，结果箱子里只有5件，剩下5件的位置是空的。他手伸进去乱摸，可能摸到隔壁箱子的东西。内存里的"隔壁箱子"是什么，取决于堆布局。攻击者可以反复尝试，把有用的数据"摸"出来，或者把恶意代码塞进去。

实际利用没那么简单。需要精确的堆风水，需要绕过ASLR和CFG。但概念验证代码已经有人放出来了，在局域网环境下，一个未认证的攻击者就能让Windows Server 2022蓝屏。企业内网里，这意味着什么？一台机器中招，可以横向扫描其他SMB服务，批量触发。域控如果没打补丁，整个域都可能瘫。

我注意到一个细节。微软把这个漏洞的利用可能性标为"Exploitation Less Likely"，但同时又给了"Remote Code Execution"的最高严重级别。这种矛盾评级在微软的公告里不常见。我的判断是：微软知道有PoC，但认为武器化门槛高。可门槛高不代表没人做，勒索软件团伙对SMB漏洞的兴趣从来没降过。WannaCry用的EternalBlue就是SMB漏洞，那已经是2017年的事了。

怎么防？打补丁是第一位的。但很多企业内网的SMB服务不能随便重启，补丁滞后是常态。临时缓解措施里，禁用SMB压缩是个办法，但会影响性能。更实际的做法是网络分段，把SMB流量限制在必要的子网里。另外，SMB签名和加密应该强制开启，虽然不能阻止这个漏洞触发，但能增加中间人攻击的难度。

我自己的实验室里复现了这个漏洞。一台未打补丁的Windows Server 2019，用Scapy构造SMB压缩包，发送后大约三秒，系统日志里出现BugCheck，机器重启。整个过程不需要任何凭据。这让我有点不安。SMB的设计哲学是"局域网内大家互相信任"，可现在的网络边界早就模糊了。VPN接入的笔记本、被感染的IoT设备、供应链里的第三方终端，任何一个点都可能变成攻击跳板。

微软在2024年4月的补丁星期二里还修了另外两个SMB相关漏洞，CVE-2024-21335和CVE-2024-21336。三个一起修，说明SMB的代码审计又被翻了一遍。但SMB的代码库太大了，历史包袱太重。我猜未来几年，这类输入验证漏洞还会继续出现。不是微软不努力，是这个协议本身就该进博物馆了。

如果你管着Windows环境，去查一下你的补丁状态。KB5035853和KB5035854里包含了这个修复。别等。SMB漏洞的利用窗口期通常很短，PoC公开后一周内就会有扫描器出现。到时候再补，可能已经晚了。