许多“果粉”对iPhone的忠实，都来自于对iOS优质体验和安全性的信任。但，这个曾被公认为最安全的主流操作系统，在过去几个月却经历了一波声誉打击：据黑客安全大会披露，攻击者能够在用户没有任何点击操作的前提下完成六次足以劫持iPhone设备的无交互攻击。此外，还有五种iOS漏洞利用链现身恶意网站，攻击者已经借此入侵了数十台设备。零日漏洞经纪公司甚至抱怨称，由于黑客大肆通过iOS攻击攫取市场，他们手中的漏洞资源已经遭遇大幅贬值。

随着iPhone 11的发布，许多人又开始了新的担忧：苹果公司不能再单纯地对已经曝光的个人安全漏洞加以修复，而应该真正自查iOS当中引发这些缺陷的更深层次问题。有长期关注iOS的安全研究人员称，这意味着苹果公司首先需要着眼于iPhone中的两大内部要素：Safari与iMessage。

虽然两个应用的漏洞只会为黑客提供指向iOS设备的初步立足点（攻击者必须找到其它漏洞才能更深入地渗透至目标操作系统当中），但这些表面级别的漏洞仍在最近出现的一系列攻击活动中发挥了重要作用。而苹果公司，则拒绝对此发表任何评论。

独立安全研究员Linus HenzeHenze在今年早些时候曾发布过一项名为KeySteal的MacOS漏洞。他表示，“如果大家想要入侵iPhone，Safari与iMessage就是最好的入口。”他还在与其他iOS研究人员的讨论中指出，iMessage以及WebKit（这款浏览器引擎不仅是Safari的基础，同时也是所有iOS浏览器的基础），苹果公司一直把对内部代码的信任度放在高于其他公司代码的位置上，而这也正是问题的真正根源。Henze解释称，“相较于其他人提供的代码，苹果公司更信任自己的代码。他们明显不愿接受自己的代码也有bug这一事实。”

>>> WebKit中的发现

举例来说，苹果公司要求所有iOS网络浏览器——包括Chrome、Firefox、Brave以及其它各类方案——都必须与Safari一样以WebKit引擎为基础。Henze表示：“这基本上相当于只允许各厂商为Safari开发拥有不同界面的同内核版本。”在他看来，苹果之所以要求各类浏览器尽皆使用WebKit，是因为为了缩短处理时长，运行网站中JavaScript代码时往往涉及复杂的即时编译技术（JIT）。虽然在iOS设备上运行的程序往往需要由苹果或者经过批准的开发商进行加密签名，但浏览器的JIT速度优化则不在受审范围之内。

由此带来的结果就是，苹果坚持只允许利用WebKit引擎处理那些不具备签名的代码。“他们明显更信任自己的代码。如果他们给Chrome开了特殊通道，那就得为所有其他浏览器开设特殊通道。”Henze指出。

根据安全研究人员们的想法，强制使用WebKit之所以会带来麻烦，是因为苹果的这套浏览器引擎在某些方面的安全性上不及Chrome等其他浏览器。安全厂商Ret2公司创始人Amy Burnett一直负责Chrome与WebKit开发方面的培训，她表示，目前虽然不清楚这两种浏览器哪一种更易受到攻击，但Chrome的bug修复速度往往更快——这主要是因为谷歌公司一直在努力主动寻找并消除代码中的安全漏洞，而且广泛采用模糊测试等自动化技术。

此外，谷歌公司还为Chrome漏洞设立了Bug赏金计划，用以激励正义黑客们发现问题并上报问题。而苹果方面除了通过WebKit给iOS引入安全隐患之外，再没有其它任何保障性作为。Burnett指出，“大家可能会在这两种浏览器当中找到类似的bug，但问题在于谁能够抢先一步解决问题。谷歌在这方面似乎表现得更好。”她还补充称，Chrome利用沙箱技术将浏览器与操作系统其余部分隔离开来的做法，也起到了良好的效果。如我们所知，这种沙箱隔离出了名的难以绕过——门槛远高于WebKit——因此Chrome中存在的任何漏洞可能都不足以帮助攻击者进一步入侵操作系统中的其它组件。

>>> 引用风险

独立安全研究员Luca Todesco表示，WebKit浏览器架构当中的另一个特殊元素也有可能引发潜在攻击，这就是文档对象模型WebCore。WebKit浏览器会利用WebCore进行网站渲染，而WebCore要求浏览器开发商追踪会引用其它对象的数据“对象”（可能是一串文本，也可能是数据数组）。这一过程被称为“引用计数”，一旦发生错误，某项引用就有可能指向这个缺失的对象。而黑客当然能够利用自己选定的对象填补这个空白，这相当于一个间谍在会议登记表上填写他人姓名。

相比之下，Chrome自己的WebCore版本当中包含了一项被称为“垃圾收集器”的安全措施，能够消除指向缺失对象的指针。如此一来，WebCore就不会错误地为这些对象保留未分配状态并被攻击者所利用。当然，WebKit也使用了一套被称为“智能指针”的自动引用计数系统，但Todesco认为这仍不足以彻底消除隐患。他表示，“在WebCore当中可能发生很多情况，浏览器开发商必须跟踪所有可能性，而这本身就是一项不可能完成的任务。”

为了“挽救”苹果在安全方面的信誉，苹果在过去一年多当中已经为iOS实施了一项重要的缓解措施，也就是“isoheaps”，也称为「隔离堆」。其作用是确保引用计数中的错误无法被利用。对此，iPhone XS、XS Max以及XR的硬件漏洞得到了一定缓解。然而，Todesco与Burnett都注意到，虽然「隔离堆」机制大大提高了WebCore的安全性，但却仍未能彻底阻断对WebCore的攻击，因为许多黑客会转而攻击WebKit的其它组件。Todesco表示，自2018年推出「隔离堆」机制以来，已出现多次对引用计数错误的利用活动。Ret2公司的Burnett也赞同称，“看起来问题还是没有真正得到解决。”

虽然存在诸多问题，WebKit的缺陷也确实一次又一次成为iOS攻击的切入点，但WebKit本身的安全性是否显著弱于Chrome还是存在争议。在Zerodium（一家销售零日黑客技术的公司）公布的产品价格表上，明确列出了直接指向Chrome与Safari的攻击方法。而另一家零日漏洞经纪商Maor Shwartz则在采访中明确表示，由于WebKit的安全性确实要差于Chrome，所以目前Android漏洞的最高价格已经反超iOS。Shwartz强调称，“Chrome是目前最安全的浏览器，漏洞的市场价格已经体现了这一点。”

>>> iMessage的问题

iMessage中的可利用漏洞要远比WebKit更少，但这些漏洞的严重程度却更高，因为黑客完全可以将此作为初始跳板，并在没有用户交互的前提下接管目标手机。就在上个月，谷歌Zero项目团队研究员Natalie Silvanovich就展示了一系列令人稀奇的iMessage零日漏洞。事实证明，这些漏洞确实能够实现对目标iPhone的远程零点击接管。

比这些bug更令人不安的是，它们全都源自相同的安全问题——即iMessage会向攻击者公开其“反序列化器”。该组件负责对通过iMessage发来的各类数据进行解包。专注关注苹果产品的安全厂商Jamf公司安全研究员Patrick Wardle对这个漏洞做出了这样的描述——这就像是盲目打开一个装满组件的盒子，却在没有进行任何检查的情况下马上着手组装。Wardle表示，“我们可以把炸弹的组件放在盒子里。由于苹果允许我们对所有对象进行反序列化，这无疑会带来巨大的攻击面。”

更重要的是，iMessage在iOS当中拥有一系列其它消息应用所不具备的天然特权。比如，非苹果应用必须运行在严格的沙箱环境当中，从而与操作系统的其它组件彼此隔离。这意味着，如果像WhatsApp这样的第三方应用程序遭到入侵，攻击者还需要采取新的方式进一步突破沙箱，才能获得对目标设备的深层控制。然而，iMessage中的某些易受攻击的组件与SpringBoard集成，而后者属于管理设备主屏幕的iOS程序。该程序根本就没有自己的沙箱环境。

Linux Henze在评论iMessage时也说道：“我个人无法理解他们为什么不全面采用沙箱化机制。他们应该假设自己的代码也会有bug，并确保与其他应用程序采取同样的沙箱保护措施，例如WhatsApp、Signal以及任何其他应用程序。”

苹果之所以能够为iPhone建立起良好的安全声誉，靠的就是对在App Store上线的一切应用程序进行全面审查和严格隔离。