苹果修复缓存漏洞:这个漏洞能让警方恢复“已删除”iPhone聊天记录


你以为删掉的消息,苹果帮你存了一个月!苹果修复了一个漏洞,该漏洞让警方能从已删除的聊天记录中恢复信息。问题出在iOS系统会把通知内容缓存到本地数据库,即使应用内消息已删除,这些缓存仍可能保留长达一个月。

这件事本质上是一场“你以为删干净了,但手机偷偷帮你记了账”的闹剧。苹果推送了一个安全补丁,修补的漏洞非常离谱:警方通过取证工具,从嫌疑人的iPhone里捞出了早就该消失的Signal消息。

原因不是Signal加密被破解,而是iOS系统把通知栏里显示过的消息内容,悄悄存进了一个本地数据库。这个缓存最长能保留一个月。换句话说,你删了对话,清了应用,甚至把手机恢复出厂设置的一部分数据清掉了,但那条“你在吗”或者更敏感的信息,依然躺在手机某个角落里,像一张被遗忘的便利贴。

苹果在安全公告里轻描淡写地承认:“标记为删除的通知可能会意外保留在设备上。”这个“意外”持续了多久?没人知道。但已知的是,FBI已经熟练地利用这个漏洞来提取证据。

Signal的总裁Meredith Whittaker公开表示,他们已经请苹果修复这个问题。她的话翻译成人话就是:你操作系统的问题,别甩锅给我们应用。

漏洞本质:通知缓存成了“永不消逝的电波”

我们得先搞清楚这个漏洞到底是怎么运作的。很多人以为,消息一旦在应用里点击删除,或者设置了阅后即焚,那些文字就该灰飞烟灭。这个想法在理想的安全模型里是对的。但在实际操作中,有一个巨大的灰色地带:通知栏。

当你收到一条Signal或WhatsApp消息,手机屏幕亮起,弹出一条通知,上面写着“张三:今晚老地方见”。这条通知是由iOS系统负责显示和管理的,不是Signal应用直接画在屏幕上的。为了让通知能在锁屏界面显示,能在通知中心留存,能被你滑动清除,iOS系统必须把这条通知的内容临时存储起来。

这个存储位置是一个系统级的数据库,或者日志文件,或者某种缓存结构。它独立于Signal应用自己的加密数据库。Signal可以把自家地盘上的消息删得干干净净,连碎片都给你擦掉。但iOS系统说:不,这条通知我还没处理完呢,我得先存着。

正常逻辑下,当你清除通知、或者删除对应的应用时,系统应该把这些缓存一并清理掉。但苹果这次修复的漏洞表明:系统没有做到。通知被标记为“待删除”,但实际上一动不动地躺在那里。FBI的取证工具,比如Cellebrite之类的,根本不需要破解Signal的端到端加密。他们只需要物理访问这部iPhone,运行取证软件,然后去那个通知缓存数据库里直接读取明文。

这就是整个事件最讽刺的地方。最安全的端到端加密应用,输给了手机操作系统的一个“小习惯”——喜欢记日记。

警方操作手法:取证工具直接读取系统缓存

那么警方具体是怎么操作的呢?根据404 Media的报道,FBI从一名嫌疑人的iPhone里提取了已删除的Signal消息。他们用的不是神秘的量子破解技术,也不是在Signal服务器上开了后门。他们用的是非常传统的手段:数字取证。

这类取证工具,比如Cellebrite UFED或GrayKey,它们的工作方式并不是像电影里那样输入一串代码然后密码就破解了。它们更像是一套极其精细的考古工具。当执法人员拿到一部iPhone,他们首先会尝试绕过锁屏密码,或者利用已知漏洞提取文件系统的镜像。一旦获得文件系统的访问权限,取证软件就会开始扫描所有可能存储数据的角落。

这个过程中,取证软件根本不需要关心Signal的加密数据库。它直接去翻iOS的系统日志、plist文件、以及像Biome或CoreDuet这类系统服务的数据库。在这些地方,通知的原始标题和正文往往以纯文本形式存在。有安全研究人员在X上指出,具体路径包括:
/private/var/mobile/Library/Biome/streams/.../Notification_/segments/
以及
/var/mobile/Library/BulletinBoard/ 下的 .json 和 .plist 文件
还有
/var/mobile/Library/CoreDuet/coreduetdClassD.db 这个SQLite数据库

这些地方存储的信息,对于取证人员来说就是金矿。他们不需要知道Signal的加密密钥,不需要破解任何密码。只要嫌疑人的手机曾经在锁屏界面上显示过“消息内容”,只要嫌疑人没有在系统设置里彻底关闭通知预览,那么这些消息内容就会被iOS忠实地记录下来。即使嫌疑人删除了Signal应用,这些系统级的缓存依然可能残留。

这不是苹果故意给警方留后门,但它客观上造成了一个长达一个月的“证据保留期”。

Signal的尴尬处境:加密再强也管不住邻居偷看

这个漏洞把Signal推到了一个非常尴尬的位置。Signal一直以强大的端到端加密和保护隐私著称。它的加密协议被业界广泛认可,甚至被WhatsApp等巨头采用。但这次事件证明了一个残酷的事实:应用层的加密再强,也管不住操作系统层的“猪队友”。

我们可以把手机比作一栋公寓。Signal是其中一户住户,他在自己家里装了最坚固的防盗门、保险柜,还把窗户全封死了。但是,这栋公寓的物业管理公司——也就是iOS——在大厅里装了一个公告栏。每次有人按Signal家的门铃,物业就会在公告栏上贴一张纸条,写着“谁谁谁来找你了,说了什么话”。这个公告栏是公共区域,物业自己管理。Signal住户可以把自己家门口的纸条撕掉,但他管不了物业是不是在背后把纸条又抄了一份,放进自己的档案柜里。

这次修复的漏洞,就是物业的那个档案柜。柜子里存满了纸条,而且即使住户搬家了(删除了应用),那些纸条还在。警方来了,物业说:档案柜在这里,你们随便查。Signal总裁的话说得很直白:“已删除消息的通知不应保留在任何操作系统通知数据库中。”这句话的潜台词是:这是我们应用开发者无法控制的系统级问题,我们也很无奈。

对于普通用户来说,这意味着什么呢?意味着你即使用了Signal,并且开启了阅后即焚,只要你没有同时关闭通知中的消息内容预览,你的那些“阅后即焚”的消息,在被阅读的那一刻,就已经在系统通知缓存里留下了副本。这个副本的生命周期由iOS决定,而不是由你或Signal决定。

解决方案与误区:关闭预览到底该在哪里关

讨论中反复出现一个关键点:如何真正避免这种缓存泄漏。很多人第一反应是去iPhone的“设置” -> “通知” -> 找到Signal应用,然后把“显示预览”改成“永不”。这个操作确实会让锁屏和通知中心不再显示消息的具体内容。但问题在于,这个设置仅仅是告诉iOS不要在界面上显示文字。它并没有阻止Signal应用本身去生成一条包含消息内容的通知请求。

这里存在一个非常容易混淆的细节。当Signal收到一条新消息,它可以选择两种方式来处理通知。第一种方式是,Signal的服务器直接通过苹果的推送通知服务(APNs)发送一个空的推送,只告诉手机“有消息了,快醒醒”。手机收到这个推送后,Signal应用在后台被唤醒,然后自己去服务器取回消息,再在本地生成一条包含消息内容的通知,交给iOS系统去显示。第二种方式是,Signal的服务器直接把消息内容(加密后)塞进推送通知的负载里,手机收到后,由Signal的一个扩展组件在本地解密,再交给iOS显示。

无论哪种方式,最终交给iOS去显示的通知,如果是包含消息内容的,iOS就会把它存进缓存。那么,在iPhone系统设置里关闭“显示预览”,只是让iOS在显示的时候把文字遮盖住或者不显示。但iOS系统内部的那个缓存流程,依然可能记录下完整的文字。有讨论者指出,真正有效的做法,是在Signal应用内部的设置里关闭消息预览。Signal应用自己的设置,可能会控制它生成通知时,是否真的把消息内容传给iOS。如果Signal内部关闭了预览,那么它传给iOS的通知负载可能就是空的或者只包含“您有一条新消息”。这样,iOS的缓存里自然就没有具体内容。

这听起来很反直觉。用户以为在系统设置里关掉预览就万事大吉,但实际上,这两个开关背后的机制完全不同。一个只是控制显示(盖上一块布),另一个才是控制数据源头(不提供内容)。很多用户根本不知道这个区别。这个设计本身就充满了逻辑反差:苹果提供了一个全局的、看起来很直观的“关闭预览”开关,但这个开关并不能真正阻止数据被缓存。真正有效的开关,却藏在每一个应用的单独设置里,而且用户还需要知道这个原理。

行业讨论:谁该为通知缓存负责

Hacker News的讨论区里,各路技术人员展开了激烈辩论。核心争议点在于:这个漏洞到底算谁的?是苹果的锅,还是Signal的锅,还是两者都有?

一部分人认为,这是苹果的系统设计问题。操作系统不应该以明文形式长期存储通知内容,尤其是在应用已经被删除的情况下。他们指出,iOS应该提供一种机制,让应用可以明确标记某条通知为“敏感”或“阅后即焚”,系统在显示后应立即从所有缓存中彻底清除。目前iOS没有提供这种细粒度的控制。另一部分人则认为,Signal这样的应用明知通知会被系统缓存,就应该默认关闭消息内容预览,并在用户尝试开启时给出严厉警告。他们指出,Signal确实提供了关闭预览的选项,但并没有在用户开启时明确告知系统缓存的风险。

还有人讨论到技术实现细节。苹果和谷歌的推送通知服务器(APNs和FCM)本身是加密通道,但问题不在于传输过程,而在于到达设备后的本地存储。有人提到,Signal其实可以使用“通知服务扩展”来加密通知负载,到设备上再解密。但即使用了这个技术,解密后的明文在交给iOS系统显示时,依然可能被系统缓存。所以问题的根源还是回到了操作系统如何处理显示过的通知。

更有意思的是,有人对比了Android的情况。在Android上,通知同样会被系统缓存,但Android提供了一个官方的“通知历史”功能,用户可以主动查看。这个功能是透明的,用户知道它在记录。而在iOS上,这个缓存是隐形的,用户无法直接查看,但取证工具可以读取。这就造成了一种“你感觉它没存,但它真的存了”的诡异局面。

更新策略争议:iOS 18用户被迫升级的烦恼

除了漏洞本身,这次安全更新还引发了另一场风波。苹果将修复补丁同时推给了iOS 26和iOS 18的用户。表面上看,这很好,照顾了老版本用户。但问题出在更新的附加效果上。

多位用户在讨论中抱怨,当他们安装了针对iOS 18.7.8的安全更新后,系统悄悄地重新开启了“自动更新”功能。这意味着,如果不手动去设置里再次关闭,他们的iPhone会在某个夜晚自动下载并安装iOS 26。而iOS 26,根据一些用户的反馈,存在不少问题,包括卡顿、相机应用崩溃、键盘响应异常等。

有用户直接喊话:“避开iOS 26,不惜一切代价。”还有用户描述了自己的遭遇:因为需要恢复出厂设置,被迫升级到iOS 26,结果手机连最基本的打开相机或关闭键盘都会卡死。他们认为这是苹果的一种“阴险战术”:利用安全补丁作为诱饵,然后悄悄打开自动更新的开关,诱使那些坚守iOS 18的用户“自愿”升级到最新的、可能尚未稳定的iOS 26。

更令人困惑的是,不同用户的体验还不一样。有人说在之前的18.7.7版本中,自动更新就被重新打开了。也有人说,从18.7.7升级到18.7.8后,自动更新反而保持关闭状态。这种不一致性让用户感到无所适从。有人猜测,这可能是一个一次性的标志位问题,或者取决于之前是否手动干预过。

这件事反映出用户对操作系统强制更新的普遍不信任。一方面,安全漏洞确实需要紧急修复。另一方面,用户希望保留在某个稳定、熟悉的系统版本上的意愿也应该被尊重。苹果在这里的平衡术显然没有做好,反而因为一个看似不起眼的设置被重置,引发了额外的信任危机。用户调侃道:“你可以信任苹果帮你修漏洞,但你得时刻提防它顺手帮你换个新系统。”

隐私底线与用户建议:我们能做什么

回到最实际的问题:作为一个普通用户,或者说一个对隐私有较高要求的用户,我们该怎么办?

第一,也是最直接有效的办法,是在你使用的每一个通讯应用内部,关闭消息内容预览。不要依赖iOS系统设置里的那个开关。去Signal、WhatsApp、Telegram的设置里,找到通知相关选项,把“显示消息内容”、“显示预览”之类的选项全部关闭。让通知只显示“您有一条新消息”或者发件人名字,绝不显示正文。

第二,如果你必须看到消息预览才能决定是否回复,那你需要接受一个风险:任何显示在锁屏界面上的文字,都有可能被iOS缓存下来,并且有可能被拥有物理访问权限的人用取证工具读取到。这不是危言耸听,这是已经被证实的现实。

第三,定期重启手机。虽然不能完全清除所有缓存,但有些临时日志和缓存会在重启后被清理或重建。这算是一个低成本的心理安慰加轻度防护。

第四,对于那些真正需要高度保护的用户,比如记者、活动人士、律师,你应该考虑使用专门的、经过安全加固的操作系统,或者至少启用iPhone的“锁定模式”。锁定模式会禁用很多可能被利用的攻击面,虽然会影响部分使用体验,但安全性会大幅提升。

第五,永远不要以为“删除”就是真的删除。在数字世界里,删除通常只是打上一个标记:“这块地方可以覆盖了。”在它被新数据真正覆盖之前,它可能一直存在。而取证工具擅长的,就是找到这些还没被覆盖的“标记”。

这次漏洞的核心教训是:你的手机操作系统是一个比你想象的更“健忘”但同时又更“记仇”的伙伴。它健忘,是因为它经常不按你的指令彻底删除。它记仇,是因为它会悄悄记下你的一举一动,然后在一个月后交给警察。

总结

苹果修复通知缓存漏洞,该漏洞让警方能提取已删消息。用户需在应用内关闭预览,勿信系统设置。