谷歌 Project Zero 团队的两名研究员 Natalie Silvanovich 和 Samuel Groß公开了6个“无交互”安全漏洞中的5个漏洞的详情和 PoC。它们影响 iOS 操作系统,可经由 iMessage 客户端利用。
所有的6个漏洞已于上周即7月22日在苹果发布的 iOS12.4 版本中修复。Silvanovich 表示,其中1个漏洞的详情并未公开,因为 iOS 12.4版本的补丁并未完全修复该问题。
4个无需用户交互的 RCE 漏洞
Silvanovich 指出,其中4个漏洞可导致在远程 iOS 设备上执行恶意代码,且无需用户交互。攻击者需要做的就是将恶意信息发送至受害者手机,一旦用户打开并查看收到的项目,恶意代码就会执行。这4个漏洞是CVE-2019-8641(详情未公开)、CVE-2019-8660 和 CVE-2019-8662。第5个和第6个漏洞CVE-2019-8624 和 CVE-2019-8646 可导致攻击者泄露设备内存信息并读取远程设备文件,且均无需用户交互。
01、CVE-2019-8647 (高危)
该漏洞是释放后使用漏洞,存在于 iOS 的 Core Data 框架中,由于使用 NSArray initWithCoder 方法时发生不安全的反序列化,因此可导致任意代码执行的后果。它可经由 iMessage 客户端远程触发。具体而言:当通过 initWithCoder 反序列化一个类时,该类的子类也被反序列化,前提是子类没有覆盖 initWithCoder 并实现了要求具体实现的所有方法。_PFArray 就是NSArray 的这种子类。当反序列化 _PFArray 时,它通过 [NSArray initWithCoder:] 被反序列化,最终调用了 [_PFArray initWithObjects:count:]。该方法通过 NSKeyedUnarchiver 提供的对象初始化数组,但并未保留对这些对象的引用,因此当发布 NSKeyedUnarchiver 时,数组中的对象也被发布,即使这些反序列化对象的用户仍然在使用它们。该问题可经由 iMessage 客户端远程实现,并且在无用户交互的情况下导致 Springboard 崩溃。通过 pfarray.zip 文件的复现步骤:
(1) 安装frida (pip3 安装frida)
(2) 打开sendMessage.py,并用目标设备的电话号码或电子邮件替代样本接收器(3) 在injectMessage.js 中,用 obj 文件的路径替换标记“PATH”(4) 在本地目录中运行:python3 sendMessage.py
Pfarray.zip 文件下载地址:https://bugs.chromium.org/p/project-zero/issues/attachment?aid=394583&signed_aid=anzLJpyG1iuf8txb5Xi9Zw==
02、CVE-2019-8660 (中危)
它是存在于 Core Data 框架和 Siri 组件中的内存损坏问题,如遭利用,可导致远程攻击者引发应用程序异常终止或任意代码执行的后果。具体而言:它是在解码类NSKnownKeysDictionary1的对象时产生的内存损坏漏洞。该类解码NSKnownKeysMappingStrategy1类型的对象,该对象解码应该表示字典的键的长度的长度member。但是,该 member是在在解码键之前解码的,因此如果键也在使用 NSKnownKeysMappingStrategy1实例的NSKnownKeysDictionary1的实例,则将在检查长度之前使用映射策略。NSKnownKeysDictionary1实例使用此长度来分配缓冲区,并且在此分配期间,在未进行整数溢出检查的情况下,长度乘以8。然后,代码将尝试使用未经过相乘的长度将values数组(另一个已解码的参数)复制到缓冲区中。在这个bug中我们无法控制复制的值,因为getObjects:range会以非常大的范围被调用并抛出异常。但是,如果解码值数组为null,则getObjects:range将不执行任何操作,然后代码将经历一个循环,将values数组中的条目复制并保留到基于长度 member 分配的缓冲区中,远远超过两次分配的结束。由于这些副本不受控制,因此这个问题可能非常难以利用。使用knownkeydict在iMessage中复现此问题:
(1) 安装frida (pip3 安装frida)
(2) 打开sendMessage.py,并用目标设备的电话号码或电子邮件替代样本接收器(3) 在injectMessage.js 中,用 obj 文件的路径替换标记“PATH”(4) 在本地目录中运行:python3 sendMessage.py
knownkeydict 文件下载地址:https://bugs.chromium.org/p/project-zero/issues/attachment?aid=398583&signed_aid=aRa647CnzpRUCj7nXIOEKA==
03、CVE-2019-8662 (高危)
该漏洞类似于 CVE-2019-8647,存在于 iOS 的 QuickLook 组件中,也可经由 iMessage 客户端远程触发。具体而言:使用NSArchiver API反序列化NSObject时,可以提供允许取消归档的类的白名单。在这种情况下,归档中其类未列入白名单的任何对象都不会被反序列化。这样做还会导致NSKeyedUnarchiver ”requireSecureCoding”,确保归档类在反序列化之前符合NSSecureCoding协议。这样就可以以安全的方式对不受信任的档案进行反序列化。但是,如果满足下列条件之一,则NSKeyedUnarchiver中的白名单中的类的子类也将被反序列化(请参阅Foundation.framework中的 [NSCoder _validateAllowedClass:forKey:allowingInvocations:] 获取确切的逻辑):
(i) 它实现initWithCoder:和supportsSecureCoding,并且调用supportsSecureCoding方法返回true。
(ii) 它没有实现initWithCoder,而第一个实现 initWithCoder: 的超类还实现了supportsSecureCoding并返回true
在后一种情况下,反序列化这样的对象将调用超类的initWithCoder:,然后可能最终调用子类的方法。其中一个例子是OfficeImport框架中的OITSUIntDictionary。该类继承自NSDictionary,其initWithCoder:将在unarchiving期间被调用。然后发生以下情况:
(i) initWithCoder 使用归档中的键值对数调用initWithCapacity:,最终导致调用[OITSUIntDictionary initWithCapacity:] ,它将dict的后备存储设置为`CFDictionaryCreateMutable(0LL,v3, 0LL, 0LL)`的结果。注意,既没有提供键值也没有值回调(参数#3和#4)。因此,不会保留存储在字典中的元素。这应该是因为字典只应存储未参考计数的整数造成的。
(ii) 接着,initWithCoder为存档的每个键值对调用setObject:forKey。现在,它将把键和值存储在OITSUIntDictionary 中,而不保留它们,因此它们的引用计数仍为1,它们仅由NSKeyedUnarchiver实例保持活动状态。(iii) 取消归档完成后,NSKeyedUnarchiver被销毁,并释放对反序列化对象的所有引用。然后释放这些对象,反序列化的OITSUIntDictionary现在包含过时的指针。
访问反序列化字典的元素之后导致使用后释放的问题。OfficeImport库似乎由QuickLook.framework按需加载(在_getOfficeImportLibrary()中),而QuickLook被加载到Springboard进程中。因此,可能存在在Springboard中加载OfficeImport的情况,使得此错误可通过iMessage远程触发,而无需任何用户交互。在任何情况下,即使在取消归档期间强制执行secureCoding,任何加载了OfficeImport库并反序列化不受信任的NSDictionaries的进程都是易受攻击的。从某种程度上讲,这些类型的错误可自动找到:当附加的IDAPython脚本在加载了iOS dyld_shared_cache的IDA Pro中运行时,将枚举所有系统库并确定从其中一个列入白名单的类继承的类。然后,它会将所有候选项(允许通过NSMeyedUnarchiver反序列化的类以及iMessage解析中存在的白名单)写入磁盘。之后,可以通过首先归档有效的父类(例如NSDictionary)并将父类的名称替换为序列化归档中子类的名称,然后再次反序列化归档并调用一些常用方法来取消归档这些类。结果对象,例如“count”或”objectForKey:”。这样,当出现反序列化错误的子类时,程序可能会崩溃(就像PFArray和OITSUIntDictionary的情况一样)。附加的archiveDict.m程序可以生成一个有效的NSDictionary存档,然后可以将其转换为xml格式,以便使用`plutil -convert xml1 archive`进行编辑。unarchiveDict.m之后可以再次将存档反序列化为NSDictionary实例。但是,这种方法要求在目标进程中加载的所有库也都加载到unarchiveDict中,否则将无法找到某些类,因此无法反序列化。复现代码下载地址:https://bugs.chromium.org/p/project-zero/issues/attachment?aid=394697&signed_aid=5uFIpHlPCfZIwX_Or7gX0w==
04、CVE-2019-8646 (高危)
该漏洞也位于 Siri 和 Core Data iOS 组件中,可导致攻击者在无需用户交互的情况下远程读取存储在 iOS 上的文件内容,例如无沙箱的用户手机。具体而言:即使启用了安全编码,也可以反序列化_NSDataFileBackedFuture类。此类是文件支持的NSData对象,在调用[NSDatabytes]选择器时将本地文件加载到内存中。这样就会产生两个问题:首先,如果反序列化缓冲区的代码共享该类,它可能会允许访问本地文件(它更可能导致使用序列化对象进行本地通信的组件出现问题而不是iMessage 出现问题)。其次,它允许创建一个NSData对象,其长度不同于其字节数组的长度,从而违反了应始终适用于NSData对象的非常基本的属性,从而导致越界读取,且还可能导致越界写入,原因是现在能够创建大小非常大的 NSData 对象,而如果备份了缓冲区则不可能发生这种情况。使用filebacked.zip在iMessage中复现此问题:
(1) 安装frida (pip3 安装frida)
(2) 打开sendMessage.py,并用目标设备的电话号码或电子邮件替代样本接收器(3) 在injectMessage.js 中,用 obj 文件的路径替换标记“PATH”(4) 在本地目录中运行:python3 sendMessage.py
注意,该 PoC 仅适用于 iOS 12 或后续版本,仅为简单演示之用,实际后果可能更加严重。Filebacked.zip 下载地址:https://bugs.chromium.org/p/project-zero/issues/attachment?aid=393862&signed_aid=F_uB8SyL0O1hL6k--xEcgQ==
05、CVE-2019-8624(中危)
该漏洞存在于 watchOS 的 Digital Touch 组件中,影响 Apple Watch Series 1及后续版本。苹果已在本月发布 watchOS 5.3 解决了该问题。具体而言:如果格式错误的Tap消息包含points 阵列和delta阵列短的颜色数组,则Digital Touch iMessage扩展可越界读取。[ETTapMessage initWithArchiveData:]方法检查points数组的长度是增量数组的两倍,但只检查colors数组的长度是否超过8个字节,即使每个被处理的 point-delta对都需要一种颜色。使用tapcrash.zip在iMessage中复现此问题:
(1) 安装frida (pip3 安装frida)
(2) 打开sendMessage.py,并用目标设备的电话号码或电子邮件替代样本接收器(3) 在injectMessage.js 中,用 obj 文件的路径替换标记“PATH”(4) 在本地目录中运行:python3 sendMessage.py
它将导致在无需用户交互的情况下,SpringBoard 产生崩溃。Tapcrash.zip 下载地址:https://bugs.chromium.org/p/project-zero/issues/attachment?aid=390454&signed_aid=eD7g-gx9F9QzUw4DJvHBDA==
由于这些漏洞的 PoC 已发布,因此用户应立即安装 iOS12.4 版本。
价值至少500万美元
Silvanovich将在下周于拉斯维加斯举办的黑帽安全大会上做出关于远程和无交互 iPhone 漏洞的演讲。演讲概述为,“一直都有人在说无需用户交互的远程漏洞可用于攻击 iPhone,但关于现代设备遭受此类攻击的技术内容信息有限。这次演讲探索的是远程的无需交互的 iOS 攻击面,它探讨的是 SMS、MMS、Visual Voicemail、iMessage 和 Mail 中潜在的漏洞情况,并解释了如何设置工具测试这些组件,同时还会给出通过这些方法发现的两个漏洞案例。”Silvanovich 的演讲内容必然在下周引发很多关注。在此之前,无用户交互的 iOS 漏洞通常出现在利用供应商和合法拦截工具以及监控软件的武器库中。这类漏洞是任何攻击者的梦想,因为他们可借此悄无声息地入侵受害者设备。从Zerodium 给出的价格表来看,这类漏洞在利用市场上的价格超过100万美元。也就是说,Silvanovich 公开的这些详情,毫不夸张地说,价值超过了500万美元,很可能价值1000万左右。而漏洞供应商Crowdfense 表示,鉴于无需点击的工具链以及它们适用于最新版本的 iOS,因此每个漏洞的价值应该在200万至400万美元之间,也就是说总价值在2000万至2400万之间。
推荐阅读
苹果修复 Windows 版本 iTunes 和iCloud 中的 SQLite和 WebKit 漏洞
原文链接
https://bugs.chromium.org/p/project-zero/issues/detail?id=1873
https://bugs.chromium.org/p/project-zero/issues/detail?id=1874
https://bugs.chromium.org/p/project-zero/issues/detail?id=1858
https://bugs.chromium.org/p/project-zero/issues/detail?id=1884
https://bugs.chromium.org/p/project-zero/issues/detail?id=1828
题图:Pixabay License
本文由奇安信代码卫士编译,不代表奇安信观点,转载请注明“转自奇安信代码卫士 www.codesafe.cn”。