Updating Firefox is highly recommended [LWN.net]

Access Denied

Posted Oct 10, 2024 16:06 UTC (Thu) by NightMonkey (guest, #23051) [Link] (2 responses)

"Access Denied

You are not authorized to access bug 1923344. To see this bug, you must first log in to an account with the appropriate permissions. "

*Sigh*

Access Denied

Posted Oct 10, 2024 16:16 UTC (Thu) by daroc (editor, #160859) [Link] (1 responses)

The patch fixing the issue appears to be this one.

Access Denied

Posted Oct 10, 2024 16:49 UTC (Thu) by NightMonkey (guest, #23051) [Link]

Thank you, daroc! :)

Firefox is Rust based, right?

Posted Oct 10, 2024 17:15 UTC (Thu) by atai (subscriber, #10977) [Link] (7 responses)

does not prevent such security hole...

Firefox is Rust based, right?

Posted Oct 10, 2024 17:21 UTC (Thu) by mb (subscriber, #50428) [Link] (2 responses)

Rust would very well have prevented this use-after-free, because there's no such thing as use-after-free in safe Rust.
If you read daroc's comment, you can see that the vulnerability was in C++ code.

Firefox is Rust based, right?

Posted Oct 11, 2024 11:35 UTC (Fri) by parametricpoly (subscriber, #143903) [Link] (1 responses)

If the link listed above fixes this, it also shows that they've switched from that old explicit iterator syntax to a more modern one. This is something that was added to e.g. Java already 20 years ago.

Firefox is Rust based, right?

Posted Oct 25, 2024 22:24 UTC (Fri) by mrugiero (guest, #153040) [Link]

That's a different assertion, ain't it? Would use of the better modern iterators have prevented this? Yep. But does Rust not prevent it as well? That's false.

Firefox is Rust based, right?

Posted Oct 10, 2024 17:36 UTC (Thu) by viro (subscriber, #7872) [Link]

<wry> The bug in question is in C++ parts of that shitpile, actually. </wry>

Firefox is Rust based, right?

Posted Oct 10, 2024 17:59 UTC (Thu) by geofft (subscriber, #59789) [Link] (2 responses)

Firefox is not Rust-based. Mozilla sponsored early development of Rust in the hopes of building a new rendering engine (Servo) to replace the one in Firefox (Gecko), but that never shipped and the Servo team got laid off in 2020. While a small portion of the work from Servo was adapted into Firefox 57 ("Quantum"), there is so little Rust in Firefox that it doesn't even show up in GitHub's auto-generated count of lines of code per language (https://github.com/mozilla/gecko-dev).

Firefox is Rust based, right?

Posted Oct 11, 2024 1:29 UTC (Fri) by tschoerbi (subscriber, #88015) [Link]

Servo appears to have come back to life but that life is outside Mozilla.

Firefox is Rust based, right?

Posted Oct 11, 2024 9:03 UTC (Fri) by kelvin (guest, #6694) [Link]

> there is so little Rust in Firefox that it doesn't even show up in GitHub's auto-generated count of lines of code per language (https://github.com/mozilla/gecko-dev)

There's a separate project which tracks the amount of Rust in Firefox (https://4e6.github.io/firefox-lang-stats/), and it currently has Rust at 11.7%. The other systems languages are C at 13.8%, and C++ at 26.7%.

I don't know why there's a difference to the github numbers, but maybe Firefox is developing cargo crates which reside outside the gecko-dev repository.

about:config mitigation?

Posted Oct 11, 2024 2:07 UTC (Fri) by randomluser (guest, #173956) [Link] (1 responses)

Because the bug is in the animation timelines API, does setting dom.animations-api.timelines.enabled to false mitigate this?

about:config mitigation?

Posted Oct 11, 2024 10:25 UTC (Fri) by mss (subscriber, #138799) [Link]

I wonder whether disabling JavaScript JIT (javascript.options.baselinejit=false) would mitigate any practical exploit here since achieving the required memory layout with just the JavaScript interpreter is AFAIK pretty hard.

What about Seamonkey?

Posted Oct 11, 2024 11:39 UTC (Fri) by parametricpoly (subscriber, #143903) [Link] (4 responses)

I've wondered why the Seamonkey project is so far behind Firefox. According to the changelog from Sep 4th, 2024:

"SeaMonkey 2.53.19 uses the same backend as Firefox and contains the relevant Firefox 60.8 security fixes."

"Additional important security fixes up to Current Firefox 115.14 and Thunderbird 115.14 ESR plus many enhancements have been backported. We will continue to enhance SeaMonkey security in subsequent 2.53.x beta and release versions as fast as we are able to."

The delta between the last two releases is over 5 months. So I guess Seamonkey users get these patches in March or April 2025?

What about Seamonkey?

Posted Oct 11, 2024 22:58 UTC (Fri) by remicardona (guest, #99141) [Link] (3 responses)

The few projects that are based on gecko have more or less universally decided to track Firefox ESR rather than the main "rapid" Firefox. AIUI, the latter evolves at a much faster pace than any of those projects (mostly volunteer-driven) can manage. Rebasing on top of Firefox ESR every couple of months is a lot less hassle and relieves a lot of the pressure to upgrade as ESRs have upstream support for nearly a year.

What about Seamonkey?

Posted Oct 12, 2024 5:07 UTC (Sat) by roc (subscriber, #30627) [Link] (1 responses)

Seamonkey is not using Firefox ESR.

What about Seamonkey?

Posted Oct 12, 2024 5:10 UTC (Sat) by roc (subscriber, #30627) [Link]

Sorry, nevermind, I could be wrong about that.

What about Seamonkey?

Posted Oct 12, 2024 10:38 UTC (Sat) by parametricpoly (subscriber, #143903) [Link]

The latest ESR is 128.3.1 (first release in 2024), not 115.14 (first release in 2023).

Breaks screensaver inhibition

Posted Oct 13, 2024 16:05 UTC (Sun) by wx (guest, #103979) [Link] (3 responses)

It looks like as of this update (or the previous from the 128 branch) Firefox on Debian no longer inhibits the screensaver when full-screen video is playing.

Does anyone have a fix or workaround?

Breaks screensaver inhibition

Posted Oct 13, 2024 20:00 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Huh. I never thought to try *fullscreen* playback…the screenlock still kicks in when on a video call. And it works as expected with `mpv`, so it isn't that my weird setup isn't capable of it either…

Breaks screensaver inhibition

Posted Nov 1, 2024 13:14 UTC (Fri) by sammythesnake (guest, #17693) [Link] (1 responses)

Isn't that something for the window manager to handle? On my desktop (using sway) I've just got it configured to inhibit the screensaver whenever the focused window is full-screen...

I presume there's some kind of mechanism that FF uses to tell the WM it would like to inhibit the screensaver, but at the least it's the WM's job to gate that request and ensure it doesn't override the user's intentions for their device...

Breaks screensaver inhibition

Posted Nov 1, 2024 16:43 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

There's a DPMS protocol that should work. Firefox is supposedly using it, but it doesn't work for me (I use `xlock`). `mpv` blocks screen locking when it is playing, so there's *something* that works at least.