属性表文件(Plist)它是一种文件形式，通常用于存储用户设置或存储捆绑信息。这个功能是旧的Mac OS由资源分支提供。Plist存储的数据是抽象的，可以使用不止一种文件格式。
macOS它看起来很有趣，尤其是属性列表(plists)它是苹果操作系统中常见的存储序列化对象的文件，类似于微软Windows使用注册表存储配置数据。以下显示macOS基于应用程序自动器的应用程序xml属性列表示例。存储应用程序的版本信息和其他有用数据如下：
属性列表也可以采用二进制形式，否则称为bplist。顾名思义，这些是二进制格式的属性列表，它们使用了包括字典在内的附加对象类型和关系。以下是一个例子bplist，虽然可以使用其他标签来支持格式的其他版本，但可以使用bplist00标记此示例：
通过查看苹果的开源代码，我们可以更好地理解它bplist格式，我也发现这个参考很有用。苹果开源代码中定义的bplist格式如下：
二进制plist格式
属性列表为模糊测试提供了一个有趣的目标，因为它们很容易被操作系统的许多部分（包括更高特权的过程）创建和使用。苹果的开源代码允许我创建任何东西bplist，同时使用内置文件格式开始模糊文件格式macOS plutil命令行工具确保正确的语法。
我花了几天时间生成它bplist执行此格式，并很快发现某些对象类型是常见的macOS二进制文件(例如Finder)以及更高特权的二进制文件(包括Launch Services守护程序(LSD))分析会导致异常。系统崩溃日志显示Core Foundation框架中有漏洞，但正如我们稍后看到的，这个漏洞存在于多个位置。Core Foundation(简称CF)是一套Mac OS和iOS中的C语言API，由较低层的一些例程和封装函数组成。Apple最大的发布CF开源项目叫CFLite，基于CFLite可以开发跨Mac OS X，Linux和Windows平台应用。另一个第三方开源实现称为OpenCFLite它也有相同的功能。Core Foundation例程的对象通常遵循命名规则，例如：CFDictionary会出现在开头函数中CFDictionaryRef，这些对象通常是手动的CFRetain和CFRelease管理引用计数。Core Foundation也会把一些基本类型转化为基本类型Objective-C可用中可用的格式。
大多数崩溃似乎都是由Core Foundation解析bplist然后尝试使用所创建的对象。bplist的ObjectTable有非字符串类型的对象(Date、Data、Bool等）在调用不存在的字符串相关选择器时，解析过程会崩溃。结果是，任何使用Core Foundation读取属性列表的过程可能常，读取属性列表的过程可能会崩溃。以下是易受攻击的示例代码路径：
使用以下C与测试应用程序位于同一目录中的代码和名称Info.plist恶意属性列表可以轻松到达这个位置:
崩溃分析
可以编程或修改bplist放置在系统上自动分析漏洞的方法实际上是漏洞的最初迹象之一LSD在尝试使用修改后的属性列表注册应用程序时反复在我的系统上崩溃。
Objective-See有一篇很棒的博客文章，详细介绍了LSD应用程序注册和属性列表自动分析。
下图为控制台输出，显示在我的桌面上合法Info.plist身份修改后bplist对于导致崩溃的频率，请注意用户级和系统级的崩溃。
LSD崩溃
通过修改单个字节ASCII字符串对象(类型)0x5X)改为另一种对象类型，如DATE(类型0x33)，可以创造恶意bplist。修改后的bplist示例如下：
这个小字节变化现在可以用于macOS系统和iOS虽然该平台在这项研究中没有被测试，但它也会造成严重的损坏。这种方法也会影响包括Spotlight多个数据库，包括恶意数据库Info.plist即使在重启后，攻击也会反复导致崩溃。
漏洞是现漏洞？
我深入研究了这个漏洞的实际位置，因为它可以很容易地重建崩溃。跟踪这个漏洞的一个简单方法是检查崩溃过程的堆栈跟踪。以下是测试应用程序的崩溃日志，该日志使用Core Foundation读取恶意属性列表。
阅读本文以理解Core Foundation如何处理无法识别的选择器异常，并澄清堆栈跟踪_CF_forwarding_prep_0会很有帮助的。有了这些信息，我将以前的返回地址视为CFStringFind特别是调用异常的可能来源_CFStringGetLength之后。下面的反汇编说明了这个调用:
CFString查找反汇编
我逐渐完成了LLDB中的CFStringFind，直到调用_CFStringGetLength在检查寄存器之前。从苹果的_CFStringGetLength在文档中，我们知道第一个参数应该是字符串，所以我们可以使用以下参数LLDB命令检查RDI寄存器。
可以看出，第一个参数的对象类型不是字符串，而是恶意的bplist中的_NSDate对象_CFStringGetLength反编译解释了可能出错的地方：
_CFStringGetLength反编译
我们可以看到，长度选择器被调用到函数的第一个参数上，我们知道函数对_NSDate对象会失败，因为它没有这个选择器，理论也与崩溃日志相匹配。
如果我们继续执行这个函数，它最终将是Objective-C内部异常处理表明我们已经找到了这些崩溃的根本原因。
其他选择器
继续生成非字符串对象的生成bplists，并且可以从其他无法识别的选择器中使用Core Foundation其他崩溃是在中生成的。下面的崩溃日志是LSD使用恶意bplist和一个剩余的nscfdata对象后的崩溃日志：
此LSD倒塌的堆栈跟踪如下：
注意，在Objective-C在异常处理前，崩溃的位置不是来自CFStringFind，但实际调用_CFStringGetCStringPtrInternal的CFStringFindWithOptionsAndLocale，最后，由于调用错误的选择器_fastCStringContents崩溃。这样做的原因是剩下的nscfdata类型实际上有一个长度选择器，所以它成功地通过了我们以前看到的第一个崩溃位置，并进一步进入Core Foundation，直到它调用另一个未识别的选择器。
发现多个漏洞
在这项研究的早期阶段，我使用它plutil从恶意bplist生成崩溃，然后编写自己的代码以达到必要的代码路径。使用以下命令plutil作为目标过程和print plist设置一个标志LLDB会话，为了开始调试崩溃，该标志只会打印人类可读版本的属性列表。
几次执行后，很明显plutil事实上，它在其他位置崩溃，而不是在其他位置崩溃Core Foundation崩溃。下面的输出显示了它试图在__NSDate类型调用长度选择器，会导致无法识别的选择器异常，但这个漏洞存在于plutil中，不存在Core Foundation中。
似乎在许多macOS假设应用程序中有类似的漏洞，这些漏洞bplists只包括字符串对象的类型。LSD如下所示：
假如我们用GHIDRA来反汇编_LSPlistCompactString函数，则可以看到偏移量45或0x2D因此，我们调用了漏洞对象类型的另一个长度，可能是从我们现在开始LSD恶意的数据库bplist调用的：
我们可以通过_LSPlistCompactString设置断点并使用以下断点命令打印第一个参数来验证这一点：
下面的输出说明LSD正在从恶意bplist获取__NSDate对象：
这证实了我最初认为的一个漏洞实际上是多个漏洞macOS二进制文件中的许多漏洞都来自于bplist假设只包含字符串对象。
恶意影响
- 根级进程可能会在普通用户帐户中崩溃，并且如果操作系统重新生成了根级进程，则它们会反复崩溃(例如，LSD和MDS)。
- 特别是系统不稳定和拒绝服务Finder或其他与UI相关过程消耗恶意bplist崩溃过程需要崩溃0-click由于应用程序捆绑包，程序包等会在写入磁盘时自动处理。
- 有可能使普通用户帐户中与安全相关的进程崩溃，从而删除安全边界(XProtect等)，虽然本文没有全面讨论。
- 在自动分析bplist可远程使用。
- 受此漏洞影响的系统组件包括使用Core Foundation解析bplist在macOS 10.15.3快速搜索了1000多个已安装的二进制文件，导入了实现这一漏洞的函数。
- 通过了许多应用程序Core Foundation解析bplist数据，但也会在自己的代码中错误地访问生成的对象，这意味着漏洞可能会更大。
本文翻译自：https://objective-see.com/blog/blog_0x5A.html
【责任编辑:赵宁宁 TEL：（010）68476606】