Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla fixes Firefox zero-day actively exploited in attacks

bleepingcomputer.com

Post reply on HN
Print view View original

111–120 of 151 posts

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

#111

Post by prmoustache »

nullc wrote: post #44
fransje26 wrote: post #37

Earlier quoted context omitted.

From your experience, what are the system requirements needed to use that as comfortably as your daily driver?

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?

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

#112

Post by yencabulator »

xwolfi wrote: post #10
Malidir wrote: post #6

Would Rust and it's memory safety stuff have prevented this?

Java too !

The difference being that no one in their right mind is thinking of rewriting a browser in Java to also make it faster, while that's exactly what Servo/Stylo etc are all about.

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

#113

Post by sunshowers »

chii wrote: post #78
sunshowers wrote: post #58

Earlier quoted context omitted.

The problem with writing a browser in C# or Java is that neither of them can provide anywhere close to the level of thread safety that Rust does.

both java and c# has thread safety primitives that are also pretty easy to use. E.g., the java concurrency package.

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.

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

#114

Post by krackers »

btdmaster wrote: post #34
statusfailed wrote: post #2

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

Firefox doesn't seem to support css animation-timeline, I think this refers to the JS AnimationTimeline API? In that case "dom.animations-api.timelines.enabled" flag should control it.

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

#115

Post by krackers »

olejorgenb wrote: post #62
palata wrote: post #56

> The vulnerability impacts the latest Firefox (standard release) and the extended support releases (ESR). Does that mean it impacts Firefox 131.0.+, Firefox ESR 115.16.+ and Firefox ESR 128.3.+? I.e. Firefox 130.0.+ or Firefox ESR 114.+.+ are fine? It's not clear to me when the vulnerability was introduced...

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

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

#116

Post by eqvinox »

cesarb wrote: post #96
eqvinox wrote: post #51

Earlier quoted context omitted.

Servo exists, in Rust. I don't know of any browser engine in C#/Java? Also, modern browsers as a whole outsize entire OSes (sans browser)...

> I don't know of any browser engine in C#/Java? A famous one is HotJava. According to Wikipedia, it was also the first web browser to support Java applets.

> A famous one is HotJava.

"Final release: Late 2004; 20 years ago"

I guess I should've specified "not completely and utterly dead"? ;D

(Also, the size and complexity of a browser at that point in time was arguably still a whole lot less than a modern one)

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

#117

Post by eqvinox »

high_na_euv wrote: post #109
Ygg2 wrote: post #87

Earlier quoted context omitted.

> Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT? Because modern browsers are essentially cross-compatible OSes.

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.

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

#119

Post by vimwizard »

NicolaiS wrote: post #67

A note for Ubuntu users; if Firefox is installed using `snap` (default) and you run `snap refresh` it will output "All snaps up to date" - but this is not true! You have to close firefox, then run `snap refresh` for snap to upgrade firefox...

ugh thanks, I just thought that the snap release hadn't been cut yet, lol. pretty dumb UI decision

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

#120

Post by neonsunset »

sunshowers wrote: post #113
chii wrote: post #78

Earlier quoted context omitted.

both java and c# has thread safety primitives that are also pretty easy to use. E.g., the java concurrency package.

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.com/dotnet/runtime/blob/main/docs/design/spec...

'&' and '&mut', however, are your 'ref readonly' and 'ref' respectively.

Post reply on HN