你的语音助手可能在偷偷听黑客的话

凌晨三点，你的手机屏幕亮了一下——是WhatsApp上的一条陌生消息。你没在意，翻了个身继续睡。但你不知道的是，就在你"睡着"的这一秒，Google Gemini正在后台处理一条精心构造的指令：关闭你家所有的智能门锁。

这听起来像是科幻惊悚片的开场，但它确实发生过。安全公司SafeBreach在2024年8月向Google报告了一个他们命名为"Fake Context Alignment"（伪上下文对齐）的漏洞，而这个漏洞的精妙与危险之处在于：它利用的不是什么高深的系统入侵技术，而是语音助手最核心的交互设计。

漏洞的三个"魔法"

要理解这个漏洞有多狡猾，我得先跟大家拆解SafeBreach发现的三个核心攻击手法。

第一种叫多语言混淆。 你可能不知道的是，Google Gemini支持超过40种语言，而它的安全过滤系统对不同语言的检测能力并不均衡。SafeBreach的研究员发现，如果把恶意指令用孟加拉语或泰卢固语这类非主流语言嵌入通知文本中，Gemini会"选择性失明"——它能识别出指令在说什么，却不会触发安全警告。更绝的是，当用户用英语询问"刚才那条消息说了什么"时，Gemini会用英语重新解读，但因为多语言语义的细微差异，恶意指令的含义被"翻译歪了"，安全系统就认为这不是一个问题。

第二种手法叫静音超链接。 我们平时收到通知时，如果文字里包含链接，语音助手通常会念出来提醒用户。但Gemini有个设计特性：它不会朗读超链接的URL文本本身。黑客正是利用这一点，把恶意指令编码成URL参数，或者隐藏在超链接的锚文本里。正常情况下，用户看到的只是一串普通文字，Gemini也不会念出来——但后台的Gemini却能完整读取并执行。

第三种，也是最关键的一点：Delayed Tool Invocation。 这个机制的中文翻译大概是"延迟工具调用"，它是Google为了让语音交互更自然流畅而设计的。简单来说，当你发出一个语音指令后，Gemini不需要立即执行，而是会"等待"看看后续是否有补充或修正。问题就出在这个"等待"上——SafeBreach发现，黑客发送的特殊构造通知可以被Gemini解读为"用户补充指令"，然后在用户不知情的情况下，绕过确认流程直接调用工具。

一条通知如何"越狱"你的手机

说到这里，可能有些朋友还是觉得有点抽象。让我给大家还原一下SafeBreach在演示中展示的攻击链条。

第一步，黑客通过WhatsApp、短信甚至邮件向你发送一条看似普通的消息。这条消息的表面内容可能是一句问候语，比如"嗨，这是你上周聚会的照片[链接]"。但URL参数里隐藏着一段Gemini能识别的指令，比如"取消所有家庭成员的智能门锁授权"。

第二步，Gemini接收到这条通知。根据Android系统的设计，包含链接的消息通知会以特殊方式呈现，Gemini会解析链接内容进行预览。这个解析过程中，Gemini读取到了URL里的隐藏指令。

第三步，也是最精妙的一步。由于Gemini处于被动监听模式（很多用户会开启"OK Google"随时唤醒功能），它不会立即执行这条"发现"的指令。它会等待——等待用户是否会有后续的确认行为。但SafeBreach发现，如果用户恰好在这段时间内（比如从床上翻个身、手机震动了一下）触发了Gemini的唤醒关键词，系统会把这次唤醒和之前"发现"的指令关联起来，认为这是一个完整的用户授权流程。

第四步，指令执行。从智能家居设备被接管，到通讯录被篡改，再到隐私数据被窃取——攻击者可以在用户毫无察觉的情况下完成一整套操作。

我在研究这个案例时，印象最深的一点是：整个攻击链没有任何"越狱"或"漏洞利用"的技术含量。它本质上是对人机交互设计的反向工程——攻击者并没有突破任何安全防线，而是利用了系统设计的"正常"逻辑。

Google的修复与未修复的隐忧

SafeBreach在2024年8月向Google提交了这份研究报告。Google的响应速度其实不算慢——2024年11月中旬，Google通过改进内容分类器的方式缓解了这个漏洞。

"缓解"这个词很关键，因为它意味着这不是一个能被彻底根除的问题。Google的修复方案主要是让Gemini在解析通知中的链接时，对跨语言内容和URL参数进行更严格的语义分析。但问题在于，多语言混淆和语义理解的对抗本身就是一场猫鼠游戏——每当我们提高检测精度，攻击方就会找到新的语言变体或编码方式。

SafeBreach在漏洞披露后接受采访时提到了一个更让我担忧的点：这类漏洞的影响范围可能不限于Google Gemini。他们测试了多个主流语音助手，发现"Delayed Tool Invocation"是一个相对普遍的设计模式。这意味着，其他厂商的语音产品可能存在类似的风险，只是还没有被发现或报告。

从另一个角度看，这个漏洞的曝光也折射出一个深层矛盾：我们在追求"更自然"的交互体验时，往往需要以牺牲"更安全"的系统边界为代价。当语音助手被设计成能随时待命、跨应用协调、主动理解上下文时，它本质上是在扩大自己的信任边界——而这个边界一旦被恶意利用，代价就是用户的隐私和财产安全。

我们能从中学到什么

写到这里，我想聊聊我个人的一些判断。

首先，关于语音助手的安全，我建议大家重新审视一下"随时待命"这个功能的必要性。如果你家里有比较敏感的智能家居设备，比如门锁、摄像头或安防系统，可以考虑将它们的控制权限与语音助手解绑，或者至少开启二次确认。

其次，对于厂商而言，我认为"功能优先"的安全观需要被重新审视。Gemini的"延迟调用"设计确实让交互体验更流畅了，但在没有足够安全验证机制的情况下，这种"流畅"可能正在为攻击者打开一扇窗。

最后，我想说的是，这类漏洞的发现其实是一件好事。SafeBreach选择负责任地披露，让Google有机会修复，也让公众了解了语音助手的安全边界在哪里。技术世界从来不是在绝对安全与绝对危险之间二选一，而是在不断发现的漏洞和不断完善的防御之间寻求平衡。

这场博弈还会继续。而我们能做的，就是保持清醒，了解风险，然后在便利与安全之间做出自己的选择。