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

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

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

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

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

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

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

        在接受我的手指后，它卡在一个奇怪的 "Pixel正在启动...... "信息上，并停留在那里，直到我再次重启它。

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

        正如我向自己承诺的那样，第二天我又开始关注这一行为。在重启手机，三次输入错误的PIN码，输入PUK，并选择新的PIN码后，我得到了同样的 "Pixel正在启动...... "状态。

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

        像以前一样，我输入了PUK码并选择了一个新的PIN码。这一次，手机闪了一下，我进入了我的个人主屏幕。什么，它之前是被锁住的，对吗？

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

        这时我的手开始发抖。这他妈是怎么回事？它自己解锁了？

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

        下面是解锁过程的实际情况。

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

        我提交了报告。我认为这是我目前最短的报告。只花了5个简单的步骤。

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

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

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

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

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

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

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

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

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

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

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

        你可以在feed.bug.xdavidhu.me上阅读完整的对话。

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

        但我会让你来评判它。
                                                            第四章
        是什么导致了这个错误？

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

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

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

        看起来，在安卓系统中，有一个 "安全屏幕 "的概念。一个安全屏幕可以是多种东西。PIN输入屏幕，指纹扫描屏幕，密码输入屏幕，或者，在我们的案例中，SIM PIN和SIM PUK输入屏幕。

        这些安全屏幕可以相互 "叠加"。因此，举例来说，当手机被锁定，并且SIM PIN输入是可见的，它有一个SIM PIN安全屏幕在一个 "指纹安全屏幕 "之上。

        当SIM PUK被成功重置时，一个.dismiss()函数被 "安全屏幕堆栈 "上的PUK重置组件调用，导致设备取消当前的安全屏幕，并显示堆栈中 "在其之下 "的安全屏幕。在我们的例子中，这是一个指纹安全屏幕。

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

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

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

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

原文：Accidental $70k Google Pixel Lock Screen Bypass - bugs.xdavidhu.me