查看原文
其他

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

综合编译 代码卫士 2022-04-06

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

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


研究员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)

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

产品线。

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



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存