MetaMask修复隐私漏洞:用户关闭数据共享后外部服务器仍保持连接

运行中的Snaps持续联网

MetaMask存在一处隐私缺陷,用户关闭钱包的数据共享功能后,部分外部服务器连接仍在继续,开发团队已于11月12日在GitHub上发布了修复代码。问题的核心是“基础功能”开关,它控制着MetaMask是否为获取价格、余额等数据而访问外部服务器,想减少对外请求的用户可以将其关闭。而MetaMask提交的代码变更把结果写得直截了当:即便基础功能已被禁用,一些外部服务器仍然在被访问。

缺陷的根源在于Snaps,也就是MetaMask的扩展框架。这个框架允许钱包运行第三方程序,从而支持其他区块链,其中包括比特币和Stellar。按照旧的行为逻辑,用户关闭基础功能后,Snaps发起的新请求会被拦截,但已经处于运行状态的程序不受影响,它们继续与各自的网络端点通信。正是这种“只管新、不管旧”的划分让缺陷得以存在:开关管住了新启动的活动,而驻留在内存中的进程却不听任何指令。连接比特币网络的服务器和提供数字资产价格数据的服务器因此始终可达。一个把钱包设置为隐私模式的用户,实际上仍在向这个设置本应切断的服务发起连接。

修改后的代码终结了这一状态。基础功能被关闭时,MetaMask现在会直接停止运行中的Snaps,并切断它们的外部连接,而不是任由其继续。补丁等于把“总开关”下沉了一层:仅仅拦截新的Snaps已经不够,因为真正持有连接的恰恰是已经载入内存的程序。开发者在修复前的测试中复现了四次错误,四次全部出现非预期连接;修复之后,四次运行全部正常,开关一关,连接立即中断。

十月已有一次披露

这并非同一承诺的首次失守。10月29日,MetaMask自己披露过一次:在基础功能关闭的情况下,钱包仍向多个外部服务器发送了请求,这已经是用户明确退出后仍对外通信的一例。由于是公司主动公布,此事才进入公开记录。11月12日的代码变更专门针对Snaps的行为,而MetaMask没有说明该修复是否覆盖十月披露中提出的全部问题,这个空白正是本事件尚未闭合的部分。读过十月公告的用户无法确认补丁已关闭当时描述的所有情形,能确认的只有一点:已复现的Snaps故障在测试中已清零。

此事发生在一个原本完全不与比特币对话的钱包上。MetaMask起步时只是一个以太坊钱包,Snaps正是它触达其他链的机制,比特币和Stellar都在其列。在以太坊钱包内自托管比特币,历史上要借助包装比特币,也就是在另一条链上发行的代币化替代品,而Snaps把这条路拓宽为对更多网络的直接支持。这种跨链曾招致比特币至上主义者的反对,该立场主张比特币应当独立存在;如今它意味着比特币网络流量进入了许多比特币持有人从未安装过的钱包。Snaps也承载着该钱包进军比特币DeFi的入口,即建立在比特币而非以太坊技术栈之上的借贷、交易和收益服务,这也解释了这个框架为何需要持续运行访问外部服务器的进程。

对受影响的用户而言,实际影响范围窄但具体。设置在界面上始终显示为关闭状态,而钱包仍保持着与比特币网络基础设施及价格服务器的连接。披露文件记录的是一处连接层面的故障,而非资金的移动;记录所呈现的是违背设置而持续存在的流量,而不是面临风险的余额。

补丁没有说明的事

我们的判断从一手记录出发:MetaMask自家代码仓库中的这次变更明确写着,禁用基础功能后将停止运行中的Snaps并关闭其连接,且在开发者的测试中通过了四次复现。披露文件没有确认的,是十月披露中的情形是否已被覆盖,而对任何依赖这个设置的人来说,这份沉默才是承重的事实。非预期的服务器调用不会像漏洞利用或重放攻击那样转移资金,此处的损害在于一个用户以为已经生效的隐私控制。能让此事重新成为活新闻的,是MetaMask出面声明补丁已关闭所有未决情形。截至目前,这样的声明并未出现。