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)
Deja Vu. I had to submit an issue and fix a similar issue years ago -- it was similarly Twitch chat overlay XSS, but for that they (the streamer) at least tried to strip the tags (but it was a poor JS implementation of PHP strip_tags), and the streamer didn't understand the issue until I crafted a image with onload/onerror to freeze/hang the chat overlay.
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.
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. Terms like “code” and “execute” are largely arbitrary. If you want safety, stop letting untrusted payloads enter your machine at all, and that includes Hacker News.
> 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.
There's such a thing as an attack surface. JavaScript with JIT enabled has an attack surface so much larger than HTML and CSS that I cannot believe you're saying this in good faith.
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.
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.
Url changed from https://cyberinsider.com/malicious-twitch-chat-messages-can-..., which points to this.
tldr: XSS on OBS via the message
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)
Deja Vu. I had to submit an issue and fix a similar issue years ago -- it was similarly Twitch chat overlay XSS, but for that they (the streamer) at least tried to strip the tags (but it was a poor JS implementation of PHP strip_tags), and the streamer didn't understand the issue until I crafted a image with onload/onerror to freeze/hang the chat overlay.
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.
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. Terms like “code” and “execute” are largely arbitrary. If you want safety, stop letting untrusted payloads enter your machine at all, and that includes Hacker News.
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.
There's such a thing as an attack surface. JavaScript with JIT enabled has an attack surface so much larger than HTML and CSS that I cannot believe you're saying this in good faith.
Craziest thing is the mixture of:
- A browser engine outdated by two years, with known-exploited CVEs
- Chromium sandboxing completely disabled [0]
- JavaScript V8 Engine with JIT enabled [0]
For me, it's surprising we haven't seen more of these yet.
[0]: https://github.com/obsproject/obs-browser/blob/f555da02b1d59...
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.
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.