我发现了一个影响似乎所有谷歌Pixel手机的漏洞如果你把任何锁定的Pixel设备给我我可以把它解锁还给你。这个漏洞刚刚在2022年11月5日的安全更新中得到修复。

　　该问题允许有物理权限的攻击者绕过锁屏保护指纹、PIN等并获得对用户设备的完全访问权。该漏洞被追踪为CVE-2022-20465它也可能影响其他安卓供应商。你可以在到我的补丁公告和我发给谷歌的原始漏洞报告。

　　我真的很高兴这个漏洞现在得到了修复。这是我目前发现的最有影响的漏洞对我来说它越过了一条线c;我真的开始担心修复的时间表甚至只是担心自己把它作为一个 秘密。我可能反应过激了但我的意思是不久前联邦调查局还在为几乎同样的事情与苹果公司争吵。

　　我在旅行24小时后发现了这个错误。回到家时我的Pixel 6只有1%的电量。我正在发送一系列短信的时候它就死了。我想这是某种玩笑我无法正常完成所以感觉相当尴尬。我急忙跑到充电器旁把手机重新启动。

　　Pixel启动后要求输入SIM卡的PIN码。我通常知道这个密码但这次我没能正确记住。我希望自己能搞清楚所以我尝试了几种组合但最后我输入了3个错误的PIN码SIM卡自己锁住了。现在它需要PUK码来解锁并再次工作。

　　我跳进衣柜不知怎么找到了SIM卡的原始包装我刮开了背面得到了PUK码。我在Pixel上输入PUK码它要求我设置一个新的PIN。我照做了成功完成这一过程后我进入了锁屏状态。但有一点不对劲。

　　这是一次新的启动显示的不是通常的锁屏图标而是指纹图标。它接受了我的手指这不应该发生因为在重启后你必须至少输入一次锁屏密码才能解密设备。

　　我在心里指出这很奇怪这可能有一些安全方面的影响所以我以后应该看看。说实线c;我不太喜欢在我没有明确寻找的时候发现这样的行为因为当这种情况发生时我很容易感到有强迫性的责任去调查。我开始觉得我必须确保在引擎盖下没有别人漏掉的严重问题。在这种情况下嗯有的。

　　我在这个过程中玩了多次有一次我忘了重启手机只是从正常的解锁状态开始锁定设备热插拔SIM卡托盘并进行SIM卡密码重置过程。我甚至没有意识到我在做什么。

　　这真是令人不安的怪事。我又做了一次。锁定手机重新插入SIM卡盘重置PIN码......而我又一次出现在主屏幕上。什么

　　在我冷静下来后我意识到这确实是一个该死的全锁屏绕过在完全打过补丁的Pixel 6上。我拿起我的旧Pixel 5也试图在那里重现这个错误。它也成功了。

　　由于攻击者可以只带他/她自己的PIN锁的SIM卡所以除了物理访问外不需要其他的东西来进行利用。攻击者只需调换受害者设备中的SIM卡然后用一张有PIN锁的SIM卡进行攻击而攻击者知道正确的PUK码。

　　谷歌更确切地说是安卓的VRP在37分钟内就分流并提交了一个内部错误。这真是令人印象深刻。不幸的是在这之后回复的质量和频率开始下降。

　　在这个bug的有效期内由于官方bug ticket的反应不是很好我有时会从Googlers那里得到一些半官方的信息。其实我更愿意只在官方渠道获得更新也就是bug ticket我可以公开但是因为我和一些员工聊天所以我捡到了一些零碎的东西。

　　另外这里值得一提的是在报告之前我查看了安卓VRP奖励表其中指出如果你报告的锁屏绕过会影响多个或所有[Pixel]设备你最多可以获得10万美元的赏金。由于我勾选了所有必要的方框所以我认为这个漏洞很有可能线万美元的奖励。

　　在它被分流后基本上有一个月的时间是沉默的。我听说它实际上可能作为一个重复的问题被关闭。显然有人已经事先报告了它尽管是我的报告使他们真正采取了行动。在处理最初的报告时似乎出了问题。事实上在报告31天后我醒来时看到了一封自动邮件说 安卓安全团队认为这是一个重复的问题之前是由另一个外部研究人员报告的。 这有点像签名式的Bug赏金时刻一个Bug从10万美元变成了0美元。我真的不能做什么只能接受这个Bug现在是重复的事实不会支付。

　　在我的报告之后差不多两个月过去了只是一片寂静。在第59天我呼唤该票要求更新状态。我得到了一个模板回复说他们仍在进行修复工作360行车记录仪 华为vpn。

　　快进到九月我的报告三个月后。我当时在伦敦参加谷歌的错误猎手活动名为ESCAL8。2022年9月的补丁刚刚出来我更新了我的手机有一天晚上我在酒店房间里试图重现这个错误。我希望他们可能已经修复了它。没有我仍然能够解锁手机。

　　这次酒店房间事件真的把我吓坏了。我觉得我对这个问题的担心和关心程度远远超过了谷歌本身。这不应该是这样的。即使我是反应过度。因此那天晚上我开始联系和我们一起参加活动的其他谷歌员工。

　　第二天我向许多人解释了我的情况我甚至在谷歌的办公室里用一些Pixels做了一个现场演示。那是一种体验。我们没有SIM卡弹出工具。首先我们试图使用针头不知怎的我的手指被割伤了多处我的手开始流血。我让谷歌的工程师给我的手指贴了创可贴。(还有谁能这么说呢)由于针头不起作用我们开始四处打听一位非常好心的女士把她的耳环给了我们让我们用它试试。它起作用了! 我们交换了SIM卡并设法在一些困难中解锁了设备。现在我感觉好多了人们似乎在关心这个问题。

　　我把披露的最后期限定在10月15日但安卓的VRP团队回应说这个错误在10月还不会被修补。他们的目标是12月。考虑到影响这对我来说似乎太远了。我决定坚持我的十月最后期限。

　　在与一些Googlers讨论了这个10月的最后期限后Android VRP团队的一名成员亲自评论了这个bug ticket并要求我建立一个电话来讨论这个bug并分享反馈。我们和多人进行了一次见面电线c;他们非常好听了我的整个故事说我被蒙在鼓里好几个月只得到模板回复即使是10万美元-0美元的重复总体感觉我比谷歌更关心这个错误。他们说现在计划在11月而不是12月进行修复。不过我的最后期限还是定在了10月。

　　在我们通线c;我收到了一条新消息证实了我原来的信息。他们说尽管我的报告是重复的但只是因为我的报告他们才开始进行修复工作。由于这个原因他们决定破例对锁屏绕过的人奖励7万美元。我也决定甚至在悬赏之前我太害怕了不敢真正放出活的bug而且由于修复的时间不到一个月反正也不值得。我决定等待修复的到来。

　　总而言之尽管这个bug一开始对我这个黑客来说是一个不太好的经历但在我开始足够大声地 尖叫 之后他们注意到了并且真的想纠正出错的地方。希望他们也能公平地对待原始报告人。最后我认为谷歌做得很好虽然修复的时间对我来说仍然很长。

　　由于Android是开源的修复这个问题的提交以及所有的代码修改都是公开可见的。

　　当我第一次看到这个提交时首先让我感到惊讶的是改变的文件数量。我之前以为这个错误只会有一个简单的修正即删除负责触发解锁的错误的一行代码。但事实并非如此简单。

　　在阅读了提交信息和代码修改之后我想我能够大致了解在引擎盖下发生了什么。请记住我不是一个安卓工程师所以我想保持这个高水准。

　　由于.dismiss()函数只是解除了当前的安全屏幕它很容易受到竞赛条件的影响。想象一下如果在PUK重置组件进入.dismiss()调用之前后台有什么东西改变了当前的安全屏幕会发生什么当PUK组件最终调用.dismiss()时它是否会解雇一个不相关的安全屏幕

　　这似乎正是所发生的事情。系统的某些其他部分在后台监控SIM卡的状态当它检测到一个变化时它就会更新哪个安全屏幕是当前激活的。似乎这个后台组件将正常的例如指纹屏幕设置为激活的安全屏幕甚至在PUK组件能够进入自己的.dismiss()函数调用之前。当PUK组件调用.dismiss()函数时它实际上是在解雇指纹安全屏幕而不是像它最初设想的那样只解雇PUK安全屏幕。而在指纹安全屏幕上调用.dismiss()则会导致手机解锁。

　　安卓工程师似乎决定重构.dismiss()函数并使其需要一个额外的参数调用者可以指定它想解雇的安全屏幕类型。在我们的例子中PUK组件现在明确地调用.dismiss(SecurityMode.SimPuk)以只解除类型为SimPuk的安全屏幕。如果当前激活的安全屏幕不是一个SimPuk屏幕因为可能有一些后台组件改变了它就像我们的例子一样那么解雇函数就不会做任何事情。

　　在我看来这似乎是一个相当优雅和稳健的解决方案可以抵御这种情况以及未来的竞赛条件。我没有想到会因为这个bug在安卓系统中引起这么大的代码变化。