macOS已在线检查应用签名超过2年了

一周前，很大程度上是11月12日服务器问题的结果，人们对macOS使用Apple的OCSP服务检查证书以及引起私人数据泄漏的担忧引起了极大的关注。苹果公司迅速对日益增长的担忧做出了回应，并承诺在来年解决这些问题。自那以来，一直让我感到困惑的是，这些OCSP检查已经众所周知了两年了，直到现在才引起人们的注意。在大苏尔（Big Sur）发行后的紧要关头，本文追溯了它们的历史，并解释了它们的产生过程。

尽管macOS中的代码签名起源已经在时间的迷雾中迷失了，据我所知，它出现在2007年，但是直到2012年引入Gatekeeper才真正被重视，并在公证中变得更加重要，这是Mojave在2018年推出的新功能。

在此期间，在macOS签名和使用过程中发现了各种漏洞。与这个故事最重要和最相关的是乔什·皮茨（Josh Pitts）在2018年6月详细介绍的那些。这影响了许多知名的安全产品，包括LittleSnitch，以及更普遍的Facebook软件。事后看来，特别重要的是，这些漏洞利用了通用二进制文件，苹果公司内部知道这些二进制文件很快就会再次普及，并且具有潜在的重要性。

那年年底，我在这里报告说，macOS Mojave 10.14.2很高兴运行其开发者证书似乎已被撤销的应用程序。这激起了长时间的讨论，其中一位经验丰富的开发人员断言：“我不同意“签名问题”这一说法。代码签名是为Gatekeeper设计的。 Gatekeeper专为首次启动而设计。这些年来，网守已经发生了变化。已安装的应用程序上的旧签名无关紧要，这不是问题。”

安全研究人员对签名检查的价值表达了相反的看法：“由于macOS在首次运行后不检查代码签名，因此恶意软件可以感染系统上的许多应用程序，而无需root用户，并且您永远不会知道。只需运行一次错误的应用程序即可。另外，当然，当恶意软件被撤消时，它仍然可以在受感染的Mac上运行。”

我进行了更深入的研究，几天后，我描述了macOS 10.14.2在首次启动后如何开始更彻底地检查签名。我在那篇文章中发表的日志摘录中有一些引人入胜的条目：30.343884 SecTrustEvaluateIfNecessary 30.345255 com.apple.securityd异步获取客户端（lsd [355] / 0）的CRL（http://crl.apple.com/root.crl） ＃-1 LF = 0）30.345305 com.apple.securityd cert [2]：AnchorTrusted =（leaf）[force]> 0 30.346576 com.apple.securityd MacOS错误：-67030 30.346629 com.apple.securityd MacOS错误：-67030 30.361455 SecTrustEvaluateIfNecessary 30.362900 com.apple.securityd异步获取客户端（amfid [124] / 0＃-1 LF = 0）的CRL（http://crl.apple.com/root.crl）30.362964 com.apple.securityd cert [ 2]：AnchorTrusted =（叶子）[force]> 0 30.364183 com.apple.securityd MacOS错误：-67030 30.378125 com.apple.securityd MacOS错误：-67030 30.378189 com.apple.securityd MacOS错误：-67030 30.378271 com.apple .securityd MacOS错误：-67030 30.378316 com.apple.securityd MacOS错误：-67030 30.378356 com.apple.MobileFileIntegrity基本需求验证失败，错误：（空）30.37846 3 /Applications/SignetTest.app/Contents/MacOS/Signet签名无效：-67030 30.378478 AMFI：代码签名验证失败。 30.380499 SecTrustEvaluateIfNecessary 30.381862 com.apple.securityd异步获取客户端（amfid [124] / 0＃-1 LF = 0）的CRL（http://crl.apple.com/root.crl）30.381904 com.apple.securityd cert [ 2]：AnchorTrusted =（叶子）[force]> 0 30.383124 com.apple.securityd MacOS错误：-67030 30.383692 com.apple.MobileFileIntegrity ：签名损坏，团队ID致命。 30.383781 mac_vnode_check_signature：/Applications/SignetTest.app/Contents/MacOS/Signet：代码签名验证严重失败：验证/Applications/SignetTest.app/Contents/MacOS/Signet：代码包含团队ID，但验证其签名失败。请检查您的系统日志。 30.383800过程17245：为文件“ Signet”加载代码签名错误4 30.403372 com.apple.launchservices返回：{“ ApplicationType” =“ Foreground”，“ CFBundleExecutablePath” =“ / Applications / SignetTest.app / Contents / MacOS / Signet”， “ CFBundleIdentifier” =“ co.eclecticlight.Signet”，“ DeathTime” =现在-2018/12/21 09:18:30，“ LSBundlePath” =“ / Applications / SignetTest.app”，“ LSDisplayName” =“ SignetTest” ，“ LSExitStatus” = 9，“ pid” = 17245} 30.648151已保存Signet [17245]版本的崩溃报告？到Signet_2018-12-21-091830_Howards-iMac-Pro.crash

那是针对经过公证的应用程序，它没有设置隔离标志，甚至从未通过我的本地网络，更不用说从互联网上下载了。这些条目清楚地显示了com.apple.securityd使用OCSP和纯HTTP连接（以粗体显示）与Apple的证书吊销列表（CRL）服务建立的三个独立连接。在这种情况下，验证每次都将失败，因此该应用程序崩溃了并且不允许打开。当时，没有人对这些连接或使用纯HTTP提出任何担忧。

在2019年7月，我在这里解释了不同类型的签名检查如何工作，以及开发人员如何添加自己的代码完整性检查，其中包括使用Apple的OCSP服务进行的CRL检查。其中包括日志摘要，这些摘要再次清楚地显示了发生了什么。

直到2018-19年前，macOS似乎都在“ Gatekeeper”数据库中的/private/var/db/gkopaque.bundle中将本地有关证书吊销的信息存储在本地，苹果每两周一次更新。但是那些与macOS最新版本保持同步的Macs在2019年9月发布了macOS 10.15 Catalina之后停止访问该数据库。自2019年8月26日起，Apple尚未发布更新，任何安装了Big Sur的人都将安装真正的古老版本。正如我在此处指出的那样，“ Gatekeeper”数据库现已被废弃。

相反，卡塔琳娜（Catalina）和大苏尔（Big Sur）现在会在加载时检查所有可执行代码，并在使用开发人员证书对代码进行签名后，使用Apple的OCSP服务进行在线检查，这突然引起了很大争议。

自2012年推出Gatekeeper以来，Apple显然已吊销了许多受损的开发人员证书。我们看到了恶意软件的冰山一角，该冰山已经被Apple签名，检测到并很快被吊销了其证书。这已经发生在一些经过公证的恶意软件产品中，包括Shlayer和MacOffers。如果没有快速有效的方法来使用Apple的OCSP服务器检查签名证书的有效性，那么使用签名作为区分良性代码与恶意代码的方法就毫无意义。

那些认为Apple当前的在线证书检查是不必要的，具有侵入性或控制性的人，应该熟悉它们的产生方式以及它们对macOS安全性的重要性。他们还应该解释，享受了两年的利益后，他们突然发现自己毕竟是一个坏主意，应该用什么替代。