谷歌漏洞

2018年10月，Google+ 被曝出 API 漏洞，谷歌漏洞约 50 万用户的谷歌漏洞姓名、邮箱、谷歌漏洞职业等隐私数据暴露。谷歌漏洞谷歌当时的谷歌漏洞选择是：不公开。内部备忘录显示，谷歌漏洞管理层担心监管审查和声誉受损，谷歌漏洞决定保持沉默。谷歌漏洞直到《华尔街日报》捅出来，谷歌漏洞谷歌才在第二天宣布关闭消费者版 Google+。谷歌漏洞这个漏洞本身不算多复杂——一个 people.get 接口的谷歌漏洞权限校验失误，但真正的谷歌漏洞问题在于：谷歌知道它存在，却选择不说。谷歌漏洞

我写这篇文章不是谷歌漏洞要翻旧账。而是因为最近又看到类似的事情在发生。2024年底，Google 搜索的 site: 操作符出现异常，大量站点索引消失，持续了将近一周。官方状态面板上没有任何记录，直到 SEO 社区炸锅，谷歌才轻描淡写地承认“一个配置问题”。这让我想起一个老谷歌工程师说过的话：“我们的系统太庞大了，有时候我们自己也搞不清楚哪里坏了。”

这不是玩笑。谷歌的基础设施规模决定了它的漏洞形态和别家不一样。AWS 出问题通常是某个区域挂了，微软通常是某个服务崩了，而谷歌——你很难说清楚到底哪个环节出了毛病。2020年12月，谷歌全球认证系统宕机，导致 Gmail、YouTube、Google Drive 全部瘫痪。官方解释是“内部存储配额问题”。听起来很简单对吧？但一个内部存储配额问题能拖垮整个 Google 账号体系，说明这个系统的耦合程度已经超出了任何人能完整理解的范围。

我有个在谷歌做 SRE 的朋友，他跟我说过一个细节。他们内部有个叫 Buganizer 的系统，用来追踪所有已知问题。这个系统里有一个标签叫 Known Issue，意思是“我们知道它有问题，但我们暂时不修”。这个标签下挂着多少条目？他没说具体数字，但笑了笑：“比你想的多得多。”这其实是所有大公司的常态，谷歌不特殊。特殊的是，谷歌的产品渗透到了几十亿人的日常生活里，所以它的“已知问题”影响面特别大。

再说一个更近的例子。2025年2月，有安全研究员发现 Google Cloud 的一个 IAM 配置漏洞，允许跨项目权限提升。谷歌的回应很快，48小时内修复。但问题是，这个漏洞在修复之前已经存在了多久？没人知道。谷歌的安全团队很强，这毋庸置疑。但强不等于没有盲区。盲区往往出现在产品线交接的地方——比如 Google Workspace 和 Cloud Identity 的权限边界，或者 Firebase 和 GCP 的认证衔接处。这些地方代码归属不清，测试覆盖不全，出问题只是时间问题。

我并不是要唱衰谷歌。恰恰相反，我觉得谷歌对漏洞的处理方式，比很多公司都透明。它有专门的安全博客，有 CVE 编号，有赏金计划。但透明是选择性的。商业产品线的漏洞，谷歌倾向于快速公开；基础设施层面的问题，谷歌倾向于内部消化。这个界限在哪里，只有谷歌自己知道。

去年我和一个做渗透测试的朋友聊天，他说了句话我记到现在：“谷歌的漏洞报告，你永远只能看到他们想让你看到的那部分。剩下的，都在 Buganizer 里躺着。”这话有点阴谋论的味道，但仔细想想，哪家大公司不是这样？只是谷歌的“剩下的”那部分，可能比很多公司的全部都要大。

写到这里，我想起 Google+ 那个漏洞。后来有记者问当时的谷歌 CEO 为什么不披露，他的回答是：“我们评估了影响，认为不值得公开。”这个“不值得”三个字，才是整个事件里最值得玩味的地方。谁来判断值不值得？标准是什么？没人说得清。漏洞从来不只是技术问题，它是权力问题。谁掌握信息，谁就掌握定义“漏洞”的权力。

谷歌的漏洞，说到底，是规模带来的必然。系统越大，盲区越多；盲区越多，可被定义为“漏洞”的东西就越多。而定义权，始终在谷歌手里。我们能做的，就是盯着那些被公开的部分，然后问一句：剩下的呢？