本篇为《深蓝洞察 | 2022 年度十大安全漏洞与利用》的第九篇。

Max Kellermann 是德国一家软件公司 CM4all 的开发人员。

CM4all 有一项业务，可以把网站每天的访问日志压缩保存，在月底的时候客户可以批量下载这些日志压缩包。

在过去一年（2021 - 2022）里，CM4all 间歇收到客户的反馈报告，原因是客户从 CM4all 服务器下载的日志压缩包不能解压。

Max 调查发现，客户下载的压缩包中，数据内容实际是完好的，只是最后的 CRC 校验值不对，因而解压缩软件不能正常解压。

Max 快速修复了这些 CRC，客户的问题也迎刃而解。

这件事到这里似乎就结束了。

但是，Max 觉得没那么简单，压缩文件的 CRC 为什么损坏了？

Max 怀疑过磁盘有问题、内存有问题、服务器有问题、甚至是宇宙射线。

当多个损坏的压缩包放到一起的时候，Max 突然发现，这些错误的 CRC 居然都是“50 4b 01 02”。CRC 的损坏表现得惊人的一致！

统一的损坏模式意味着这不是偶然事件。

那“50 4b 01 02”又是什么呢？

“50 4b”对应的字符是“PK”，这正是 ZIP 文件的 magic number，后面的“01 02”说明这是一个中央目录(Central directory)。

看上去这个文件原本的 CRC 被新的 ZIP 文件头覆盖了。

Max 不能定位哪里出了问题，只能通过程序，最小化模拟日志生成、压缩、合并的过程。

通过重现和还原问题发生的每个细节，Max 终于能稳定重现这个文件损坏场景了。

现在，内核成了最大嫌疑人。

在 Linux 内核中，有一个叫做 splice 的系统调用。这个 splice 调用，以管道（pipe）为中间通道，可以快速地在文件、Socket 等目标之间传输数据。

由于使用了管道（pipe），splice 可以避免文件读写过程中数据在用户态和内核态之间的频繁传导。

Max 发现，splice 在 Linux 内核中的实现存在逻辑不当，以至于对 pipe 的写入操作，最终可以穿透至磁盘文件。

这就不是简单的 CRC 破坏问题了。

他意识到，只要对某个文件具有读权限，就可以使用这个 splice 的 bug，对该文件写入任意数据。

这和几年前声名显赫的 DirtyCoW 异曲同工，甚至比 DirtyCoW 更容易操作。

因为漏洞的发现者对漏洞具有命名权，Max 就把这个漏洞称为 DirtyPipe。

尽管存在一些限制，DirtyPipe 基本上允许对任意只读文件写入任意内容，在 Linux 环境下可以轻松转化为权限提升问题。

最终的研究结果表明，DirtyPipe 不仅影响 Linux，还影响大量安卓设备，破坏力十足。

DirtyCoW、DirtyPipe 这类漏洞并不仅限于 Linux 操作系统。

2022 年 12 月 13 日，苹果发布 macOS 13.1 和 iOS16.2，修复了多个内核漏洞，其中就包括一个与 DirtyPipe 类似的漏洞。

内核在 vm_map_copy_overwrite_unaligned 等处理非对齐写操作过程中存在条件竞争，可以通过非对齐写的方式破坏只读内存。

虚拟内存是计算机体系中至关重要的环节。

在复杂的抽象、激进的优化叠加下，虚拟内存管理未来仍将是漏洞高发区域。

从 2021 年 4 月 CM4all 收到压缩文件破坏问题的报告，到 2022 年 2 月 Max 在 Linux 内核中确认问题根源，历时近一年。

Max 可能不是第一个或唯一一个遇到由 DirtyPipe 引起的莫名其妙的程序错误的人，但是好奇心促使他成为了第一个发现 DirtyPipe 漏洞的人。

参  考：

[1] https://dirtypipe.cm4all.com/

[2] https://en.wikipedia.org/wiki/Dirty_COW

[3] https://github.com/apple-oss-distributions/xnu/blob/xnu-8792.61.2/tests/vm/vm_unaligned_copy_switch_race.c

[4] https://worthdoingbadly.com/macdirtycow/