usdt钱包支付（www.caibao.it）：深入分析macOS署名验证权限com.apple.private.security.clear-library-validation

USDT第三方支付API接口

菜宝钱包（caibao.it）是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

0x00 概述

在macOS 10.15.2版本上，Apple引入了com.apple.private.security.clear-library-validation权限（entitlement），该权限正在逐渐取代以前在系统二进制文件上使用的com.apple.security.cs.disable-library-validation权限。只管二者的影响大致相同，但它们的事情原理却存在差异。只管使用com.apple.security.cs.disable-library-validation和com.apple.private.security.clear-library-validation会自动禁用库验证，但应用程序必须通过csops系统挪用将其禁用。

0x01 简介

在Big Sur版本公布后，我注意到许多系统二进制文件都具有新的权限，其中的com.apple.private.security.clear-library-validation是我此前没有接触过的。这些应用程序之前使用的是com.apple.security.cs.disable-library-validation，看来它们似乎已经被一个新的权限替换。由于二者的名字对照相似，而且经由测试也证实了这些二进制文件仍然可以加载非Apple开发人员署名的第三方插件。这意味着，这些权限具有相同的影响。然则，二者的内部事情原理是差别的。

0x02 csops系统挪用

在遇到下面列出的新csops操作代码后，我最先深入研究这一新的权限，可以在xnu-7195.50.7.100.1/bsd/sys/codesign.h中找到该代码。

，define CS_OPS_CLEAR_LV     15  /* clear the library validation flag */

csops是一个系统挪用，可以用于对历程执行种种与代码署名相关的操作。我们可以查询历程的状态，在运行时设置种种标志，查询其代码署名blob等等。这是我以前没有发现过的新功效，因此我最先对其举行剖析。

凭据这个常量的说明，我们可以使用这个操作代码来消灭历程的库验证标志。这意味着，若是我们可以在某个历程上运行它，则在挪用乐成的情况下，可以将第三方库加载到该历程中。

这个常量仅在xnu-7195.50.7.100.1/bsd/kern/kern_proc.c源文件中引用，该文件中包罗csops_internal函数的源代码。这是在举行系统挪用时将会运行的函数。下面是与CS_OPS_CLEAR_LV操作相关的部门源代码。

static int
csops_internal(pid_t pid, int ops, user_addr_t uaddr, user_size_t usersize, user_addr_t uaudittoken)
{
(...)
       if (pid == 0) {
              pid = proc_selfpid();
       }
       if (pid == proc_selfpid()) {
              forself = 1;
       }
 
 
       switch (ops) {
       case CS_OPS_STATUS:
       case CS_OPS_CDHASH:
       case CS_OPS_PIDOFFSET:
       case CS_OPS_ENTITLEMENTS_BLOB:
       case CS_OPS_IDENTITY:
       case CS_OPS_BLOB:
       case CS_OPS_TEAMID:
       case CS_OPS_CLEAR_LV:
              break;          /* not restricted to root */
       default:
              if (forself == 0 && kauth_cred_issuser(kauth_cred_get()) != TRUE) {
                     return EPERM;
              }
              break;
       }
 
       pt = proc_find(pid);
       if (pt == PROC_NULL) {
              return ESRCH;
       }
(...)
，if CONFIG_MACF
       switch (ops) {
       case CS_OPS_MARKINVALID:
       case CS_OPS_MARKHARD:
       case CS_OPS_MARKKILL:
       case CS_OPS_MARKRESTRICT:
       case CS_OPS_SET_STATUS:
       case CS_OPS_CLEARINSTALLER:
       case CS_OPS_CLEARPLATFORM:
       case CS_OPS_CLEAR_LV:
              if ((error = mac_proc_check_set_cs_info(current_proc(), pt, ops))) {
                     goto out;
              }
              break;
       default:
              if ((error = mac_proc_check_get_cs_info(current_proc(), pt, ops))) {
                     goto out;
              }
       }
，endif
       switch (ops) {
(...)
       case CS_OPS_CLEAR_LV: {
              /*
               * This option is used to remove library validation from
               * a running process. This is used in plugin architectures
               * when a program needs to load untrusted libraries. This
               * allows the process to maintain library validation as
               * long as possible, then drop it only when required.
               * Once a process has loaded the untrusted library,
               * relying on library validation in the future will
               * not be effective. An alternative is to re-exec
               * your application without library validation, or
               * fork an untrusted child.
               */
，if !defined(XNU_TARGET_OS_OSX)
              // We only support dropping library validation on macOS
              error = ENOTSUP;
，else
              /*
               * if we have the flag set, and the caller wants
               * to remove it, and they're entitled to, then
               * we remove it from the csflags
               *
               * NOTE: We are fine to poke into the task because
               * we get a ref to pt when we do the proc_find
               * at the beginning of this function.
               *
               * We also only allow altering ourselves.
               */
              if (forself == 1 && IOTaskHasEntitlement(pt->task, CLEAR_LV_ENTITLEMENT)) {
                     proc_lock(pt);
                     pt->p_csflags &= (~(CS_REQUIRE_LV | CS_FORCED_LV));
                     proc_unlock(pt);
                     error = 0;
              } else {
                     error = EPERM;
              }
(...)
}

我们将一步一步举行先容。其中，有三个地方会对其举行检查。我们首先来看第一个swtich条件语句。

switch (ops) {
       case CS_OPS_STATUS:
       case CS_OPS_CDHASH:
       case CS_OPS_PIDOFFSET:
       case CS_OPS_ENTITLEMENTS_BLOB:
       case CS_OPS_IDENTITY:
       case CS_OPS_BLOB:
       case CS_OPS_TEAMID:
       case CS_OPS_CLEAR_LV:
              break;          /* not restricted to root */
       default:
              if (forself == 0 && kauth_cred_issuser(kauth_cred_get()) != TRUE) {
                     return EPERM;
              }
              break;
       }

在这里，系统将允许非root执行switch条件中列出的操作，其中的一项是我们关注的重点。这表明，纵然我们没有以root用户身份运行，也可以使用CS_OPS_CLEAR_LV操作挪用csops。

接下来，我们来剖析另一个switch条件。

，if CONFIG_MACF
       switch (ops) {
       case CS_OPS_MARKINVALID:
       case CS_OPS_MARKHARD:
       case CS_OPS_MARKKILL:
       case CS_OPS_MARKRESTRICT:
       case CS_OPS_SET_STATUS:
       case CS_OPS_CLEARINSTALLER:
       case CS_OPS_CLEARPLATFORM:
       case CS_OPS_CLEAR_LV:
              if ((error = mac_proc_check_set_cs_info(current_proc(), pt, ops))) {
                     goto out;
              }
              break;
       default:
              if ((error = mac_proc_check_get_cs_info(current_proc(), pt, ops))) {
                     goto out;
              }
       }
，endif

在这里，我们使用mac_proc_check_get_cs_info函数举行了MACF计谋挪用。若是乐成，MACF计谋挪用将返回0，这就是对条件的检查。在xnu-7195.50.7.100.1/security/mac_process.c内部实现了mac_proc_check_get_cs_info函数。我们跟踪这个函数。

int
mac_proc_check_set_cs_info(proc_t curp, proc_t target, unsigned int op)
{
       kauth_cred_t cred;
       int error = 0;
 
，if SECURITY_MAC_CHECK_ENFORCE
       /* 21167099 - only check if we allow write */
       if (!mac_proc_enforce) {
              return 0;
       }
，endif
       if (!mac_proc_check_enforce(curp)) {
              return 0;
       }
 
       cred = kauth_cred_proc_ref(curp);
       MAC_CHECK(proc_check_set_cs_info, cred, target, op);
       kauth_cred_unref(&cred);
 
       return error;
}

该函数最终将使用MAC_CHECK宏举行MACF挪用，我在针对CVE-2020-9771补丁的逆向剖析历程中已经讨论过。它将遍历MACF计谋挂钩，该挂钩对proc_check_set_cs_info举行检查。现在，它仅仅被沙箱挂钩，如下所示。

void _hook_proc_check_set_cs_info(int arg0, int arg1) {
    ___bzero(&var_1A0, 0x188);
    *(int32_t *)(&var_1A0 + 0xa8) = 0x4;
    *(&var_1A0 + 0xb8) = arg1;
    _cred_ *** _evaluate(arg0, 0x65, &var_1A0, rcx, r8, r9);
    return;
}

在这里，将使用操作码0x65对_cred_ *** _evaluate举行内部挪用，我在上一篇文章中也对此举行了讨论。

回到我们的csops挪用中，岂论挪用历程允许或不允许这个操作，都市运行MACF计谋检查。

,

usdt支付接口

菜宝钱包（caibao.it）是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

假设允许这个操作，那么我们继续，最后到达现实执行该操作的位置。

       case CS_OPS_CLEAR_LV: {
              /*
               * This option is used to remove library validation from
               * a running process. This is used in plugin architectures
               * when a program needs to load untrusted libraries. This
               * allows the process to maintain library validation as
               * long as possible, then drop it only when required.
               * Once a process has loaded the untrusted library,
               * relying on library validation in the future will
               * not be effective. An alternative is to re-exec
               * your application without library validation, or
               * fork an untrusted child.
               */
，if !defined(XNU_TARGET_OS_OSX)
              // We only support dropping library validation on macOS
              error = ENOTSUP;
，else
              /*
               * if we have the flag set, and the caller wants
               * to remove it, and they're entitled to, then
               * we remove it from the csflags
               *
               * NOTE: We are fine to poke into the task because
               * we get a ref to pt when we do the proc_find
               * at the beginning of this function.
               *
               * We also only allow altering ourselves.
               */
              if (forself == 1 && IOTaskHasEntitlement(pt->task, CLEAR_LV_ENTITLEMENT)) {
                     proc_lock(pt);
                     pt->p_csflags &= (~(CS_REQUIRE_LV | CS_FORCED_LV));
                     proc_unlock(pt);
                     error = 0;
              } else {
                     error = EPERM;
              }

在这里，Apple添加了异常详细的注释，对所有内容都举行了说明。若是满足要求，它将消灭目的历程的库验证标志(pt->p_csflags &= (~(CS_REQUIRE_LV | CS_FORCED_LV));)。

条件异常严酷。该操作只能由历程自身（forself == 1）以及具有由常量CLEAR_LV_ENTITLEMENT界说的权限的历程挪用。这是在xnu-7195.50.7.100.1/bsd/sys/codesign.h中举行的界说。

，define CLEAR_LV_ENTITLEMENT "com.apple.private.security.clear-library-validation"

在循环竣事后，我们就获得了以前曾见到过的权限。

综上所述，我们可以确定，拥有com.apple.private.security.clear-library-validation权限的历程可以使用CLEAR_LV_ENTITLEMENT挪用csops系统挪用，以消灭自身的库验证代码署名标志。纵然该历程未以root用户身份运行，这个方式也是有用的。

0x03 SSH

为了确认这个发现，我将具有这个权限的SSH加载到Hopper中，并验证它是否使用csops禁用了库验证。

int sub_10016d41f(int arg0, int arg1, int arg2, int arg3, int arg4, int arg5) {
(...)
loc_10016d67b:
    rax = getpid();
    rax = csops(rax, 0xf, 0x0, 0x0);
    if (rax == 0x0) goto loc_10016d6d6;
 
loc_10016d694:
    rdx = 0x0;
    rcx = 0x0;
    rbx = 0x0;
    sub_10014e556("csops(CS_OPS_CLEAR_LV) failed: %d", rax, rdx, rcx, r8, r9, stack[-136]);
(...)

简直，我们可以找到使用操作码0xf挪用csops的函数，也就是CS_OPS_CLEAR_LV操作。若是该挪用失败，我们还能获得一个详细的错误新闻。

0x04 历史

只管我仅仅在Big Sur版本中发现了这个转变，然则这个功效是较早之前引入的。在xnu-6153.51.1中引入了用于消灭库验证标志的详细csops操作，该操作已经在macOS 10.15.2中使用。然则使用该权限的二进制文件仅在macOS 10.15.4版本以后泛起，只涉及四个应用程序——su、screen、login和passwd。

从Big Sur（macOS 11.0）最先，有20个二进制文件最先具有这个新的权限，因此Apple逐渐将其迁移到这个新方式上。

0x05 新权限的优势

我们异常好奇，与之前的方式相比，这种方式有哪些优点。在这里我仅仅是推测，但确实发现了一些优势所在。使用新的方式，在加载应用程序时会强行执行库验证，这意味着攻击者无法对这类二进制文件举行dylib挟制或署理攻击。这种攻击方式是异经常见的，特别是针对第三方应用程序。

我们仍然可以将代码注入到这类应用程序中，但只能通过插件的方式，而不能通过其他方式。只管插件的攻击方式并不比尺度dylib方式难，但这种改善已经向更好的设计迈出了一步。遗憾的是，它只适用于Apple自己的文件，若是我们实验在自己的二进制文件中使用它，则会泛起错误。

mac_vnode_check_signature: /tmp/launch: code signature validation failed fatally: When validating /tmp/launch:
  Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements:

0x06 总结

我们看到Apple在macOS 10.15.2中引入了新的权限com.apple.private.security.clear-library-validation，它允许历程使用csops系统挪用消灭自身的库验证标志。Apple正在将应用程序从旧的com.apple.security.cs.disable-library-validation权限缓慢迁移到新的权限，从而在设计层面上增添安全性。

本文翻译自：​https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/：