作者：米奇金

https://www.trendmicro.com/en_us/research/22/d/macos-suhelper-root-privilege-escalation-vulnerability-a-deep-di.html

该漏洞被指定为CVE-2022-22639，如果成功利用，该漏洞可能允许 root 权限升级。发现漏洞后，我们向苹果公司报告，因此通过macOS Monterey 12.3 安全更新发布补丁

本报告深入探讨了守护进程，列举了它提供的所有服务，并讨论了其中发现的漏洞。

IPC 服务

daemon进程的核心逻辑是通过API bootstrap_check_in注册一个IPC服务，命名为com.apple.suhelperd。

客户端进程可以通过API bootstrap_look_up找到有名字的服务，然后通过IPC机制请求服务例程。（IPC 机制在“MacOS and iOS Internals, Volume I: User Mode”一书的第 11 章中有详细讨论。 ）

IPC 服务器提供了 45 个服务例程，其中一些如下图所示。我把所有的例程都改名为 IPC_NUMBER_XXX 格式，根据它们的功能和对应的权限，方便参考。

IPC 客户端已经在私有 SoftwareUpdate.framework 中实现。有 45 个导出的函数与它们各自的服务例程一一对应。

可以重用框架中的代码，而不是重新发明轮子。幸运的是，Objective-C 中有一个名为 SUHelperProxy 的类，它封装了所有可以直接使用的 IPC 客户端接口。 

以下是服务例程处理流程的示例。

客户授权

需要注意的是，并非所有 45 种服务都可供非特权客户端使用，并且服务器具有权限授权机制来验证服务请求是否来自合法客户端。 

首先，客户端需要通过 API AuthorizationCreate 生成一个授权对象，然后将其作为外部形式（32 字节数据）传递给服务器进行验证。

其次，服务器收到授权对象后，判断是否可以授予客户端特定的权限。在这个阶段，服务器检查客户端的授权对象和uid。

第三，当客户端请求一个特殊的服务例程时，服务器检查特定的权限是否先前被授予给客户端，否则拒绝该请求。

旧漏洞

如前所述，由于必需的客户端授权，并非所有服务例程都被允许。但是，由于服务器未在第三步验证权限，因此有一些基本例程未受到保护。 

例如，这里有两个旧漏洞，它们是由玄武实验室的研究人员发现的。 CVE-2021-30913可能允许恶意行为者编辑 NVRAM 变量。

该漏洞存在于函数“-[SUHelper setNVRAMWithKey:value:]”的调用者函数中。它的补丁在第 9 行添加了验证代码。

它验证值为 2 的客户端权限，因此我将调用函数重命名为 IPC_2_setNVRAMWithKey_value 以标记所需的权限。

接下来是CVE-2021-30912漏洞，该漏洞可以授予恶意行为者访问用户钥匙串项目的权限。

该漏洞存在于函数“-[SUHelper lookupURLCredentialInSystemKeychainForHost:port:]”的调用者函数中。

它的补丁在第 10 行添加了验证代码。

新发现：CVE-2022-22639

在查看了 45 个服务例程后，我过滤掉了带有验证码的那些，发现了一些名称以“IPC_0_”开头的。对这些例程的仔细检查表明，函数“-[SUHelper prepareInstallAssistantWithPath:(NSString *) path]”是可利用的。调用者函数 IPC_0_prepareInstallAssistantWithPath 没有验证客户端的权限，直接调用了真实的例程。

函数的实现如下，第三个参数（NSString *）是从客户端传过来的路径。

查看内部函数会发现它在第 70 行加载了一个包。

我调试并发现捆绑路径为 ${Assistant.app}/Contents/Frameworks/OSInstallerSetup.framework。一个重要的发现是${Assistant.app}其实是第三个参数（NSString *）路径，可以完全由客户端控制。

在正常情况下，${Assistant.app} 应该是“安装 macOS XXX.app”的真实路径。它是从从 Apple 服务器下载的 InstallAssistant.pkg 中提取的。但是，我发现用户可以利用此漏洞伪造 ${Assistant.app} 的路径和内容。

似乎我找到了一个将任何 dylib 加载到目标进程中以获得 root 特权和特殊权利的原语。但是，我无法直接加载自签名 dylib，因为我发现当 SIP 开启时，系统进程默认启用强化运行时，即使它没有使用运行时标志进行签名。但我可以将任意 Apple 签名的 dylib 加载到其中，即使它是一个旧的、易受攻击的 dylib。

也许还有其他方法可以利用这个问题。在这里，我让它加载原始的 OSInstallerSetup.framework。一旦 OSInstallerSetup.framework 被加载，它就会调用函数“-[OSISClient _startServer]”。在第 103 行，它通过 API SMJobSubmit 启动另一个 IPC 服务 com.apple.install.osinstallersetupd。从第 48 行可以看出，如果当前进程以 root 身份运行，那么新提交的作业也以 root 权限运行在系统域。 

现在，当前进程是 suhelperd，以 root 身份运行，作业可执行路径是 toolPath，它位于包 ${Assistant.app}/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupd 内。恶意行为者可以将有效负载直接放入 toolPath 以实现 root 权限升级。

完整的概念证明可以在这里找到，视频演示可以在这里观看。

修补

如前所述，Apple 已通过macOS Monterey 12.3 安全更新解决了 CVE-2022-22639 问题。这个补丁现在在第 9 行添加了验证代码。

poc: https://github.com/jhftss/CVE-2022-22639

安全建议

最终用户可以通过定期使用最新补丁更新系统和应用程序来降低风险，以确保安全漏洞不会被用于恶意活动。

参考来源：

https://www.trendmicro.com/en_us/research/22/d/macos-suhelper-root-privilege-escalation-vulnerability-a-deep-di.htmlhttps://twitter.com/cyber_advising/status/1512026801723355143https://www.youtube.com/watch?v=-vbkTLHh874

推荐阅读   

【入门教程】常见的Web漏洞--XSS

【入门教程】常见的Web漏洞--SQL注入

sql注入--入门到进阶

短信验证码安全常见逻辑漏洞

最全常见Web安全漏洞总结及推荐解决方案

常见的Web应用的漏洞总结（原理、危害、防御）

代码审计常见漏洞总结

Web安全漏洞的靶场演示

13 款 Linux 比较实用的工具

xss攻击、绕过最全总结

   学习更多技术，关注我：   

觉得文章不错给点个‘再看’吧