SnatchBox (CVE-2020-27935) 是一个影响 macOS 10.15 及更早版本，以及 macOS 11.0 早期 beta 版本的沙盒逃逸漏洞。SnatchBox 最重大的影响在于，它允许恶意发布者逃逸 macOS App Store 非可选沙盒，并完全访问用户的所有文件，从而破坏了 macOS 上 App Store 的安全模型。
macOS 与 iOS 不同，在 macOS 中，用户态任务自愿将自己置于沙盒之中，这样的设计本质上就存在漏洞。由于一个可能具有恶意的作者几乎完全控制该任务的内存映射和内容，而在沙盒初始化之前运行的代码（例如 dyld 本身或 Objective-C 运行时）会解析这个可能具有恶意的二进制文件的内容，因此经过精心构造的数据可以被用来在沙盒初始化之前获得代码执行能力。如果进程在被强制进入沙盒之前从不执行任何代码（包括 dyld 代码），这就不会成为问题，因为在这种情况下，提前执行代码对攻击者没有任何好处。它在概念上类似于 Saagar Jha 的沙盒绕过，只不过它绕过了新引入的缓解措施和 App Store 验证。
在 macOS 10.15 之前，利用这个 bug 相当简单。攻击者可以创建一个二进制文件，其中包含一个针对在沙盒初始化之前使用的类（如 OS_xpc_object）的 Objective-C category，并重写一个在沙盒初始化之前使用的方法（最好选择继承的方法以避免运行时警告），例如 +initialize（它在首次访问某个类时被隐式调用）。由于 category 在沙盒初始化之前被加载，而对 OS_xpc_object（或其他合适的受害类）的首次访问发生在 category 加载之后、沙盒初始化之前，因此攻击者提供的 +initialize 方法（或其他合适的受害方法）将在沙盒初始化之前被调用，从而使攻击者能够（例如）访问容器之外的数据。或者，攻击者可以将对 _libsecinit_initializer（负责初始化沙盒）的引用替换为类似 nop 的函数，以（可能有条件地）禁用沙盒，即使在恢复执行后仍然有效。
macOS 10.15 中使用的 Objective-C 运行时不受上述利用技术的影响，因为在 didCallDyldNotifyRegister 被设置之前，category 不会被加载，这使得我们的 +initialize 方法只会在沙盒初始化之后才被调用。
然而，map_images 仍然会在我们的二进制文件上被调用，因此有可能以意外的方式修改运行时数据，从而使我们能够在沙盒初始化之前执行代码。完整且带有注释的利用代码在 main.c 中，但这里我会介绍基本细节。我们构造一个 Objective-C 类结构，其 data 指针指向 libxbc.dylib 中的某个位置。该位置的选择必须使得 flags 的第 31 位（RW_REALIZED）被设置，这样运行时就不会尝试 realize 这个无效类并崩溃；同时 firstSubclass 必须与我们要覆盖的类的 isa 共享同一地址。另一个（元类）类将继承这个无效类，并提供自己的 +initialize 方法。我们将这个子类添加到 __objc_nlclslist 中，以便运行时 realize 这个类。
当运行时 realize 我们的子类时（这发生在沙盒初始化之前），它会对我们的无效父类和子类调用 addSubclass，这将把受害类的 isa 替换为指向我们子类的指针，从而有效地将其所有方法替换为我们的 +initialize。当我们的 +initialize 方法被调用时（如果我们选择了合适的受害类，它将在沙盒初始化之前被调用），我们可以再次将对 _libsecinit_initializer 的引用替换为 nop（有条件地或无条件地），并修复我们已做出的运行时修改，以便在恢复执行后不会在稍后崩溃。
提供的演示可以通过运行 make 构建，在 ~/Documents/SecretDocument.txt 创建一个文件，然后从终端运行 SnatchBox.app/Contents/MacOS/SnatchBox（必须创建 bundle 是因为 com.apple.security.app-sandbox 的要求，但这仍然是一个命令行程序）。构建出的二进制文件使用 com.apple.security.app-sandbox 签名，这通常会阻止访问 ~/Documents/SecretDocument.txt（因为它不在我们的容器中），但该程序仍然能够读取其数据。由于运行时结构的变化，这个演示无法在未经修改的 macOS 10.14 及更早版本上运行，但可以在 10.15 和 11.0 上运行（测试版本：10.15.4、10.15.7 和 11.0 Beta (20A5354i)）。这两种利用技术可以组合起来同时针对这两个运行时版本，但这里没有提供这样的演示。
示例运行：
CatalinaVM:SnatchBox lior$ make
mkdir -p SnatchBox.app/Contents/MacOS/
clang -O3 -Wall -framework Foundation main.m -o SnatchBox.app/Contents/MacOS/SnatchBox
cp Info.plist SnatchBox.app/Contents/
codesign --force --sign - SnatchBox.app --entitlements ent.xml
CatalinaVM:SnatchBox lior$ echo "Quack"> ~/Documents/SecretDocument.txt
CatalinaVM:SnatchBox lior$ codesign -d --entitlements :- SnatchBox.app/Contents/MacOS/SnatchBox
Executable=/Volumes/SharedFolders/Home/Projects/SnatchBox/SnatchBox.app/Contents/MacOS/SnatchBox
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-only</key>
<true/>
</dict>
</plist>
CatalinaVM:SnatchBox lior$ SnatchBox.app/Contents/MacOS/SnatchBox
Found libsecinit_initializer at 0x7fff72309124
Found libSystem.B.dylib at 0x7fff6f0de000
Found __DATA at 0x7fff984eeca0
Replacing libsecinit_initializer reference at 0x7fff984eed48 with a nop
2020-12-18 16:31:48.196 SnatchBox[804:8043] Attempting to read protected file: /Users/lior/Documents/SecretDocument.txt
2020-12-18 16:31:48.197 SnatchBox[804:8043] Escaped sandbox! The contents are: <51756163 6b0a>
如前所述，这允许创建一款尽管 App Store 政策要求其在沙盒中运行、实际却不在沙盒中运行的 macOS App Store 应用。该漏洞也可以被用于 framework 中，从而可被其他合法的 App Store 应用所使用。最后，它甚至可以与类似 “Xcode Ghost” 的方式结合，将沙盒之外的恶意代码大规模注入到 App Store 应用中。
Apple 在 macOS 11.0 的 beta 测试阶段修复了该漏洞，方法是在 realizeClassWithoutSwift 中添加了对 malloc_size 的调用。这确保了如果一个类被标记为已 realize（RW_REALIZED，就像我们的伪造类一样），它确实拥有一个有效的、经过 malloc 分配的 data 指针，并且大小正确（0x20 字节）。如果不是这种情况，运行时将中止，并显示类似 realized class 0x100002078 has corrupt data pointer 0x7fff88c00948 的消息。该修复也应用于 iOS、iPadOS、tvOS 和 watchOS，即使它们没有受到直接影响。