Live data from Hacker News

Mozilla fixes Firefox zero-day actively exploited in attacks

bleepingcomputer.com

121–130 of 151 posts

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#121
post #44

Earlier quoted context omitted.

They're increased, and some things are just obviously slow at least without extra effort to setup things like gpu pass-through. But is it worth basically turning back the clock on your computer's performance a few years to live in a world where a random click from HN or reddit can't quietly compromise your entire computer? I think so. Probably the biggest thing is to have a lot of ram, because if you're really using…

> "obviously slow at least without extra effort to setup things like gpu pass-through." AFAIK unless you have a desktop computer filled with gpus on pciexpress slots there is no way you can use GPU passthrough on multiple VMs. That kind of defeat the purpose of qubes os no?

I dunno about that? do you use more than one gpu intensive task at a time?

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#122
post #44

Earlier quoted context omitted.

They're increased, and some things are just obviously slow at least without extra effort to setup things like gpu pass-through. But is it worth basically turning back the clock on your computer's performance a few years to live in a world where a random click from HN or reddit can't quietly compromise your entire computer? I think so. Probably the biggest thing is to have a lot of ram, because if you're really using…

> a world where a random click from HN or reddit can't quietly compromise your entire computer Doesn't Flatpak also solve this?

No, flatpack is very much not a security sandbox.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#123

Earlier quoted context omitted.

> This vulnerability affects Firefox https://nvd.nist.gov/vuln/detail/CVE-2024-9680

CVE affected range is always far too wide. It obviously can't affect anything before ~75 or so because firefox didn't have the timeline api before then. It's annoying that they don't distinguish an unknown lower bound.

Well, I think their thinking is that: * we don’t want users to run 75 * 75 is so riddled with CVEs by now, who cares if there is one more

But I agree it’s appears lazy because it would have been easy to determine in that case, if I understood you correctly. Someone would have had to test it though, at the very least.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#124

Earlier quoted context omitted.

No, that's not what I'm talking about. C# and Java have nothing like the Send and Sync traits, and they don't have & and &mut.

C# doesn't have Send and Sync that is true. It frequently does not need either because it uses GC instead of affine types for automatic memory management. Synchronization is indeed "just don't write bugs", where Rust offers a massive upgrade, but .NET CoreCLR's memory model is more strict than C one, like object reference assignment having release semantics, so quite a few footguns are luckily avoided: https://github…

Is there anything in C# which ensures what Rust does statically, that you must acquire a lock to access data protected by a mutex? Rust also has MutexGuard not be sendable i.e the mutex won't be released on a different thread from which it is acquired.

With traditional mutex APIs it's just far too easy to get it wrong. I think you just have to structure your thread-related APIs to be misuse resistant. As humans we're just not good enough at not making mistakes.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#125

Earlier quoted context omitted.

So is .net

You've clearly never tried to use .net on a non-MS OS. Sure, it's possible . But it's also a royal pain, at least last time I checked.

I had .net on prod linux since 2018 and it works very fine seamlessly, web apps.

Things changed after core

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#126
post #121

Earlier quoted context omitted.

> "obviously slow at least without extra effort to setup things like gpu pass-through." AFAIK unless you have a desktop computer filled with gpus on pciexpress slots there is no way you can use GPU passthrough on multiple VMs. That kind of defeat the purpose of qubes os no?

I dunno about that? do you use more than one gpu intensive task at a time?

Please define GPU intensive. Using a gpu for video decoding can mean smaller battery usage in some cases.

Also it is not only about doing these tasks at a time, but if you need to shut down to be able to start another VM context because they can't be used concurrently it makes it very tedious user experience.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#128
post #25

Earlier quoted context omitted.

They already are partly in JS so there's a smooth path. (Wasm isn't safe but could be a building block too)

I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C, which basically adds a runtime memory safety layer to unsafe C code at the cost of some performance (I think it was a couple of media codecs, but not sure). Not sure why you think that WASM is less secur…

> there's no way for this to do damage outside the WASM sandbox

java applets promised a sandbox and then we had years of continuous vulnerabilities of escaping said sandbox.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#129

Earlier quoted context omitted.

You've clearly never tried to use .net on a non-MS OS. Sure, it's possible . But it's also a royal pain, at least last time I checked.

I had .net on prod linux since 2018 and it works very fine seamlessly, web apps. Things changed after core

I'm happy to hear of your experience, but all we have at this point is a sample size of 2 with one good experience and one poor one…

(I've tried [and failed/given up after about 2 weeks] to get a .net desktop application to build on Linux.)

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#130

Seems bad. "An attacker was able to achieve code execution in the content process by exploiting a use-after-free in Animation timelines. We have had reports of this vulnerability being exploited in the wild." See: - NVD page for CVE-2024-9680: https://nvd.nist.gov/vuln/detail/CVE-2024-9680 - Mozilla security advisory: https://www.mozilla.org/en-US/security/advisories/mfsa2024-5...

Ticket in Tor Browser: https://gitlab.torproject.org/tpo/applications/tor-browser/-... It seems to be JavaScript-free from the description, which makes it even scarier. Imagine the libwebp decoder bug except embedded media blocking doesn't really work (who blocks CSS?).

The vulnerability did require JavaScript to trigger.

I think it would be a labor of love and craftsmanship to exploit a content process today without using JavaScript.

Post reply on HN