一个脆弱的聊天叠加层，一个未沙盒化的Chromium渲染器，以及一个在野外已被利用的V8漏洞，足以将观众控制的文本转变为本地代码执行，而OBS本身保持默认设置。我发现了一个在OBS浏览器源中将观众消息作为原始HTML渲染的Twitch聊天叠加层。这使得观众可以在OBS嵌入的Chromium浏览器中执行JavaScript。在我测试时最新版本的OBS使用的Chromium版本在没有正常沙盒的情况下运行，其V8版本仍然受到CVE-2024-7971的影响，这是一个在野外已被利用的漏洞。综上所述，这条消息始于Twitch聊天，并以完全控制主播的机器告终。PoC：在OBS 32.2.2上的远程代码执行 一切始于一张截图 我的朋友曾为OBS制作了一个小型Twitch聊天叠加层，并发布了一张截图。如果你以前从未处理过流媒体设置，聊天叠加层基本上就是一个小型网页，OBS通过浏览器源在流媒体上方呈现。它可能拉取实时聊天消息、警报、捐赠，或者你希望观众在屏幕上看到的其他内容。这张截图碰巧也显示了一些代码，而一行特别引起了我的注意：聊天消息直接作为HTML放入页面，而没有进行清理。 引发整个调查的推特 这是一个经典的XSS攻击。你很可能见过这种设置：观众控制消息，叠加层将其视为HTML而非文本，攻击者控制的内容可以在页面内执行。我相信你们中的一些人已经陷入沉思，这是有充分理由的。它让我想起了Micode的一个旧视频，视频中讲述了如何通过WebSocket接口攻击OBS。这个主意是利用聊天XSS作为切入点，然后与OBS的本地WebSocket服务器进行通信，触发诸如切换场景或停止流媒体等操作。今天这种路径已经不那么有趣了。默认情况下，OBS的WebSocket服务器是禁用的，并且启用时需要密码（它会自动生成一个）。我希望得到更强的东西：一个Twitch消息，最新的OBS，默认配置，主播无需干预，以及在机器本身上的代码执行。WebSocket无法让我达到这个目的。浏览器可能可以。 OBS内部有一个完整的浏览器 OBS浏览器源是通过CEF驱动的Chromium，CEF是Chromium嵌入框架。它们用于聊天框、警报、捐赠小部件、动画和自定义叠加层。相同的浏览器组件还为浏览器停靠和服务集成提供支持。因此，这个小聊天布局实际上是在OBS内嵌的完整Chromium浏览器中运行的。利用XSS，观众控制的JavaScript现在在主播的机器上的Chromium内部执行。仅此而已并不构成Windows上的代码执行。浏览器有安全边界，专门用于防止Web内容转变为对主机的控制。但是，OBS的浏览器缺少了一个重要的边界。 Chromium沙盒被禁用 Chrome通常使用沙盒隔离渲染进程。即使攻击者利用内存损坏漏洞并在渲染器内部实现本地代码执行，他们通常仍然需要越过那个沙盒才能到达主机。OBS以以下方式初始化其嵌入的CEF浏览器：CefString(&settings.log_file) = log_path_abs; settings.windowless_rendering_enabled = true; settings.no_sandbox = true; uint32_t obs_ver = obs_get_version(); uint32_t obs_maj = obs_ver >> 24;该设置直接存在于当前的obs-browser源中。XSS仍然只给我们JavaScript。但是，如果这些JavaScript可以利用V8并在渲染器内部变为本地代码执行，便不会留下Chromium沙盒可供逃避。因此，我检查了OBS使用的Chromium版本。可以说，答案并不如我所希望的那样。 然后CVE-2024-7971进入了聊天 在我撰写此文章时最新发布的OBS使用了Chromium 127.0.6533.120和V8 12.7.224.18。这很有趣，因为CVE-2024-7971，V8中的一种类型混淆，影响Chromium 128.0.6613.84之前的版本。谷歌在2024年8月21日的Chrome 128中对此进行了修补。这不是一个理论上的浏览器漏洞。微软记录了它被他们追踪的朝鲜威胁行为者Citrine Sleet利用，并且CISA将其添加到已知被利用的漏洞目录中。在微软观察到的攻击中，利用V8获得了在Chrome沙盒渲染器中的代码执行。攻击者仍然需要另一个漏洞才能逃脱该沙盒。在OBS内部，这个特定的障碍已经被禁用。 事件走向连贯：攻击链 构建攻击链 市面上没有针对我正在测试的确切CEF构建的公开概念证明，因此我构建了自己的。在开发过程中，我启用了Chromium远程调试，并使用DevTools协议检查渲染器并调试该漏洞。在高层次上，V8漏洞为页面提供了它绝不应该拥有的内存访问权限。