别再 –gpu-launcher 了——Chromium 参数注入的利用技巧

上个月有安全研究员公布了一个 Windows 10 上综合利用预装 Office URI 和 Microsoft Teams 的参数注入而形成的远程代码执行漏洞。读者可能已经早已阅读过。

Windows 10 RCE: The exploit is in the link

https://positive.security/blog/ms-officecmd-rce

大体就是 ms-officecmd: 这个 URI 可以启动本地的 Office 组件，包括 Microsoft Teams，并注入任意的命令行参数。

作者给出的利用思路是使用 –inspect 再结合远程调试协议，或者直接使用 –gpu-process 执行命令。

在文中提到一个局限性：

Precondition for this particular exploit is to have Microsoft Teams installed but not running.

漏洞触发需要安装 Microsoft Teams，但是 Teams 如果已经在运行，PoC 就会失效。

因为版本有一定要求，我没能配置复现环境，不过笔者相信这个问题其实可以通过更好的 payload 解决。因为 Chromium 系列的参数注入上栽跟头的可不止这一家，之前已经遇到过这个坑。

Chrome 浏览器套壳应用很多，除了浏览器之外还分化出两个很流行的桌面应用框架 ——Electron 和 CEF。Electron 侧重将所有代码都用 node.js 的生态编写，而 CEF 则更适合在已有的 C++ 项目里引入 WebView。

Electron 在 2018 年出的参数注入 CVE-2018-1000006 让人印象深刻。简单来说就是 win32 程序处理 URL protocol 的时候启动程序的机制有历史遗留问题，导致伪协议里的恶意 URL 可以闭合引号，注入额外的命令行参数。

经过一番挖坟，早在 2008 年 Chrome 自己的 ChromeHTML:// 伪协议就出过问题。

<!--Google Chrome Browser (ChromeHTML://) remote parameter injection POCby Nine:Situations:Group::bellick&strawdogSite: http://retrogod.altervista.org/tested against: Internet Explorer 8 beta 2, Google Chrome 1.0.154.36, Microsoft Windows XP SP3List of command line switches:http://src.chromium.org/svn/trunk/src/chrome/common/chrome_switches.ccOriginal url: http://retrogod.altervista.org/9sg_chrome.html
click the following link with IE while monitoring with procmon--><a href='chromehtml:www.google.com"%20--renderer-path="c:windowssystem32calc.exe"%20--"'>click me</a>
# milw0rm.com [2008-12-23]

话说回来，正好 Electron 是基于 Chromium 的，兼容其参数。通过滥用命令行开关可能导致命令执行：

--renderer-cmd-prefix--gpu-launcher--utility-cmd-prefix--ppapi-plugin-launcher--nacl-gdb--ppapi-flash-path 和 --ppapi-flash-args

这个 Teams 的漏洞利用很明显就受到了启发，也是用的 –gpu-launcher。

无独有偶，AWS 一个基于 CEF 的 Windows 桌面客户端也被坑了：

CVE-2021-38112: AWS WorkSpaces Remote Code Execution

https://rhinosecuritylabs.com/aws/cve-2021-38112-aws-workspaces-rce/

给出的 PoC 大同小异。

前面提到由于 Chromium 引擎的流行和 Windows 留下的坑，这种参数注入漏洞很常见。然而大家基本上都是照搬 Electron CVE-2018-1000006 的 payload，这里就有一些小问题。

笔者也在国内的流行软件上找到类似的漏洞（这个漏洞触发点还无需额外点击）：

在我当时的报告里用的也是 –gpu-launcher，TSRC 复现时反馈并没有执行命令。而我隔了几个月才反应过来原因：gpu-launcher 顾名思义就是给 gpu-process 用的。如果在虚拟机等环境里复现，缺少图形加速的支持，自然就不会启动 gpu 进程。

前文说到可能触发命令执行的开关有好几个，最稳的当然就是 –renderer-cmd-prefix。渲染器无论如何都要运行的。记得加 –no-sandbox，否则会无法执行命令。

另外一个有意思的问题，也是 MS Teams 漏洞那篇文章遇到的。Chrome 会检测已运行的实例，如果已经在运行，就会导致命令行开关被忽略，直接正常打开标签页。

这个问题其实非常好解决，就是 –user-data-dir。这个参数会指定一个新的用户目录，如果路径不同就不会复用已有的浏览器实例，永远接受新的参数。

然而 –user-data-dir 指向的目录必须是可写的。这种命令参数注入的问题貌似只会出现在 Windows 上（其他系统的 URL 机制不同）。假如默认 Windows 安装在 C 盘（绝大多数情况），可以使用 C:UsersPublicDownloads。但谁能确保一定是 C 盘呢？

如果 ISP 和防火墙没有禁掉相关协议和域名的情况下，倒是可以考虑用网络地址，例如 –user-data-dir=\hosttest。

注意对应的 SMB 目录必须可写入，这样就不用考虑具体的盘符了。亲测可用。

原文始发于微信公众号（非尝咸鱼贩）：别再 –gpu-launcher 了——Chromium 参数注入的利用技巧