Google Update Service 被曝提权 0day，谷歌拒绝修复

 聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士团队

研究员Halov 最近研究了谷歌 Omaha Update 并创建了一些小工具和该服务进行通信并执行一些任务。结果他发现 Omaha 在查找一个不存在的配置文件 “C:\GoogleUpdate.ini”。该文件似乎主要用于记录日志/调试，而由于该服务以提权组件运行且非管理员也可访问，因此Halov 决定尽心供研究。如下是正文。

很多人可能会认为在默认情况下“C:\”不允许用户创建新文件，但从 Windows 10 2009开始似乎在默认情况下允许认证用户写且微软做出了一些 DACL 变更，如下：

从 Windows 10 2009中可知道，认证用户目前可以在根目录中创建文件，而在本例中可允许我们以标准用户身份创建 “C:\GoogleUpdate.ini”。

但 Windows Server 的情况是，C:\不允许非管理员创建文件。

从日志配置文件来看，参数 “LogFilePath” 似乎允许我们指定日志文件。

可以说我们已经获得任意文件覆写漏洞，但不止如此。遗憾的是，再次查看后，该结构中的 “MaxLogFileSize” 参数有一个文件大小且其值可以是0。从实现中可知，每当谷歌 Omaha 试图创建一个新文件允许“认证用户”根据代码片段（https://chromium.googlesource.com/external/omaha/+/75e7a83d4d8485a62c4b3ffe52f57d9d5b59c33e/common/logging.cc#1042）具有访问权限时，就会有 DACL 写入。

当前剩下的唯一事情就是要启动服务本身，当我编写一些谷歌 Omaha 工具时就很轻松地实现了这个目标。只要调用 CoCreateInstance 并确保传递 Google Updater CLSID 并将该服务作为系统启动即可。

谷歌答复不修复

Halov 将问题告知谷歌，但谷歌答复称“要求对用户机器具有物理访问权限的攻击不属于Chrome 威胁模型。如果对机器具有物理访问权限，则Chrome无法阻止数据被盗或遭攻陷。”

但 0patch 平台的创始人Mitja Kolsek 认为，Google Update for Windows (“Omaha”)是开源的且由多种产品使用，因此可能该漏洞与该威胁模型相关。

推荐阅读

谷歌修复又一枚遭在野利用的 Chrome 0day
谷歌发布 Windows 10 图形组件 RCE 漏洞的详情
0day影响 Chrome和 Safari，谷歌不修复

参考链接

https://halove23.blogspot.com/2021/03/google-update-service-being-scum.html

题图：Pixabay License

本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。

    觉得不错，就点个 “在看” 或 "赞” 吧~