Hacker News Reader

Comment by superkuh | Hacker News Reader

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.

View on HN

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...

... and trying hard to parse any stream of bits thrown at it. That's why iMessage and Whatsapp zero click ecploits work so well.

> 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 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.

> 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.

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.

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.

OBS explicitly disabled the security feature that would have prevented this attack in a real browser.

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.

Reply on news.ycombinator.com