操作系统漏洞分析列表

2021年12月，操作Log4j2的系统JNDI注入漏洞（CVE-2021-44228）在GitHub上公开那天，我正给一个客户做内网渗透测试。漏洞列表他们的分析运维团队花了整整一个周末没合眼，因为超过300台服务器都跑着受影响版本。操作这不是系统个例——那个漏洞的CVSS评分是10.0，满分。漏洞列表一个字符串拼接就能触发远程代码执行，分析攻击者只需要往日志里写一段特定格式的操作文本。这种级别的系统漏洞，几年才出一次，漏洞列表但每次出现都能把整个安全圈掀个底朝天。分析

操作系统层面的操作漏洞比应用层更致命。应用漏洞炸的系统是单个服务，系统漏洞炸的漏洞列表是整台机器。2016年，Google的Project Zero团队披露了Windows内核的本地提权漏洞（CVE-2016-7255），攻击者通过win32k.sys里的一个越界读写，能从普通用户直接拿到SYSTEM权限。这个漏洞后来被用在了多个APT攻击链里，配合浏览器漏洞实现沙箱逃逸。微软当月补丁日发了十几个修复，但企业内网里打补丁的节奏永远比攻击者慢半拍。

Linux这边也不太平。Dirty Pipe（CVE-2022-0847）是我近几年印象最深的一个。它允许覆盖只读文件的内容，哪怕是/etc/passwd或者SUID二进制。原理不复杂——管道缓冲区的标志位没初始化干净，导致splice()系统调用能往只读页缓存里写数据。从5.8到5.16.11的内核全中招。我当时的测试环境是Ubuntu 20.04，5.13内核，编译一个不到50行的PoC，三秒钟拿到root shell。修复补丁倒是很简洁，初始化那个标志位就行。问题是，有多少嵌入式设备、IoT终端、老旧的CentOS 7服务器还在跑受影响的内核？没人知道确切数字。

macOS也不是铁板一块。2023年发现的CVE-2023-32434，XNU内核里的整数溢出，能导致任意代码执行。苹果在快速安全响应里修了，但只针对最新两代系统。老版本macOS的用户？自己看着办。这种“只修最新”的策略，苹果用了好几年了。从安全工程的角度看，这很糟糕。但从商业角度看，逼你升级硬件，库克笑而不语。

漏洞分析这件事，光看CVE编号和CVSS分数远远不够。同一个漏洞在不同环境里的利用难度天差地别。比如堆溢出，在浏览器里可能被ASLR和CFI挡得死死的，但在一个没开任何缓解措施的嵌入式Linux上，就是一行shellcode的事。我见过太多团队拿着Nessus扫描报告，看到“Critical”就慌，看到“Medium”就扔一边。实际上，一个配置错误的sudo规则（比如NOPASSWD: /usr/bin/vim）比很多CVE都好用。GTFOBins上列了几百个这样的二进制，运维看了直摇头。

补丁管理是个体力活，也是技术活。Windows的累积更新越做越大，现在一个月的补丁包动辄七八百MB。Linux发行版各有各的节奏——RHEL慢但稳，Arch快但容易翻车。我自己的做法是：内核漏洞优先，远程可利用的优先，需要交互的往后排。但现实里，业务部门永远会说“这个服务不能重启”。所以很多漏洞就这么挂着，一挂就是几年。直到某天被勒索软件教做人。

说回Log4j。那个周末之后，客户问我：“下次再出这种事怎么办？”我说，没有银弹。但你可以做几件事：把JNDI在Log4j配置里禁掉，给Java进程加上log4j2.formatMsgNoLookups=true，然后祈祷下一个漏洞不是出现在你依赖的另一个库里。安全这行干久了，会变得有点悲观。但正是这种悲观，让你在别人睡觉的时候还能发现那个可疑的curl请求。

很赞哦!（53124）