The fact that they backported the fix to not one but two old stable releases is kinda heart-warming in today’s cutthroat “run the latest version or die” environment.
That we have two concurrently supported versions of ESR is kinda normal for us.
115 is the last supported version known to work on Windows 7/8, so we have extended the support for a bit longer, while we hope that people will update their system and remember to install Firefox despite all of the nagging and Edge-related “refresh” offerings that Windows users seem to get these days.
Firefox 78? Yes, that one is very vulnerable. Vulnerable to this attack and all the ones we have seen in the dozens of versions we have released since then.
At this point, I believe your question is better directed at the #security matrix channel (#security:mozilla.org). But the TLDR is: Every modern exploit requires JavaScript. Whether you will be able to properly protect yourself by disabling JavaScript (or only enabling them on trusted websites) comes with a lot of follow-up questions about habit, targeting & threat models.
More interesting piles to me would be “recent code vs old code” instead of “memory unsafety vs other”
Posts like this suggest that it can be “enough” to simply write new code in a memory safe language, even if old code is never rewritten. I’d love more evidence for or against that claim.
To give a concrete example, WannaCry was a ransomware attack that did billions of dollars of damage in 2019. The vulnerability that it exploited was present in at least Vista SP2 (released in 2009), I don’t have any knowledge of whether it had been around longer, but that made it at least ten years old.
The attack depended on a single memory-safety bug and was able to get kernel-mode arbitrary-code execution.
Fixing most memory safety bugs does not give you a secure system, it just makes attackers work harder.
Fixing most memory safety bugs does not give you a secure system, it just makes attackers work harder.
Security is precisely about making attackers work harder. That is literally all there is to it. Your system only has to be secure enough to be above the threshold where it’s no longer worthwhile to attack, because it’s too bothersome. As an analogy, all bicycle locks can be opened with an angle grinder, yet they do provide enough security that they are widely used. Security, as you define it, is impossible to achieve because even if the computer system was flawless, the operators aren’t. We have to set a reasonable threshold for the word “secure”. If it takes the combined force of multiple nation states to remotely turn off a smart light bulb, it’s secure enough.
It your bike lock can be opened by only one of ten masters, instead of all of them, it’s not secure.
Increasing work factor is a benefit, but it is rarely durable because the tools available to attackers improve over time. Attacks go away only when you eliminate the class of vulnerability, not when you make it harder to find vulnerabilities of that class.
Yeah, I agree with the notion that we should eliminate entire classes of vulnerabilities. It’s like: “No, don’t just try harder to escape SQL statements, use prepared statements everywhere.”
When I implemented a tag search feature using SQLite, I had to paramaterize the number of joins, some of the text in each join, and the structure of the where clause. That was fun.
Posts like this suggest that it can be “enough” to simply write new code in a memory safe language, even if old code is never rewritten. I’d love more evidence for or against that claim.
I think it suggests that you can get a big benefit immediately by just starting to write less C++ and more Rust, so it’s not an all or nothing, rewrite everything or it doesn’t matter situation. But the goal still needs to be full memory safety, so eventually you ought to replace anything that isn’t memory safe.
The fact that they backported the fix to not one but two old stable releases is kinda heart-warming in today’s cutthroat “run the latest version or die” environment.
That we have two concurrently supported versions of ESR is kinda normal for us.
115 is the last supported version known to work on Windows 7/8, so we have extended the support for a bit longer, while we hope that people will update their system and remember to install Firefox despite all of the nagging and Edge-related “refresh” offerings that Windows users seem to get these days.
That’s much appreciated freddyb. We’re stuck on 115 for a couple more weeks. Yes we will keep firefox after the upgrade.
What about 78? Is it vulnerable? Is there a way to disable animation timelines?
Firefox 78? Yes, that one is very vulnerable. Vulnerable to this attack and all the ones we have seen in the dozens of versions we have released since then.
What about with NoScript active and WEBP images disabled? I’m trying to get information more detailed than “it’s bad”.
At this point, I believe your question is better directed at the #security matrix channel (#security:mozilla.org). But the TLDR is: Every modern exploit requires JavaScript. Whether you will be able to properly protect yourself by disabling JavaScript (or only enabling them on trusted websites) comes with a lot of follow-up questions about habit, targeting & threat models.
Add it to the 70% pile
Unfathomable amounts of self-control are required not to mention the language whose logo is a sprocket.
bikelang?
bikeshedlang
I know not everyone likes full consensus in project management, but do you need to go that hard? :D
Just bike shedding the name here, but I feel like bikeshed should really be reserved for the package manager.
More interesting piles to me would be “recent code vs old code” instead of “memory unsafety vs other”
Posts like this suggest that it can be “enough” to simply write new code in a memory safe language, even if old code is never rewritten. I’d love more evidence for or against that claim.
To give a concrete example, WannaCry was a ransomware attack that did billions of dollars of damage in 2019. The vulnerability that it exploited was present in at least Vista SP2 (released in 2009), I don’t have any knowledge of whether it had been around longer, but that made it at least ten years old.
The attack depended on a single memory-safety bug and was able to get kernel-mode arbitrary-code execution.
Fixing most memory safety bugs does not give you a secure system, it just makes attackers work harder.
Security is precisely about making attackers work harder. That is literally all there is to it. Your system only has to be secure enough to be above the threshold where it’s no longer worthwhile to attack, because it’s too bothersome. As an analogy, all bicycle locks can be opened with an angle grinder, yet they do provide enough security that they are widely used. Security, as you define it, is impossible to achieve because even if the computer system was flawless, the operators aren’t. We have to set a reasonable threshold for the word “secure”. If it takes the combined force of multiple nation states to remotely turn off a smart light bulb, it’s secure enough.
It your bike lock can be opened by only one of ten masters, instead of all of them, it’s not secure.
Increasing work factor is a benefit, but it is rarely durable because the tools available to attackers improve over time. Attacks go away only when you eliminate the class of vulnerability, not when you make it harder to find vulnerabilities of that class.
Yeah, I agree with the notion that we should eliminate entire classes of vulnerabilities. It’s like: “No, don’t just try harder to escape SQL statements, use prepared statements everywhere.”
If only SQL had a way to parameterize prepared statements with table and column names :-/
When I implemented a tag search feature using SQLite, I had to paramaterize the number of joins, some of the text in each join, and the structure of the where clause. That was fun.
I think it suggests that you can get a big benefit immediately by just starting to write less C++ and more Rust, so it’s not an all or nothing, rewrite everything or it doesn’t matter situation. But the goal still needs to be full memory safety, so eventually you ought to replace anything that isn’t memory safe.
Apparently, this is the patch: https://hg.mozilla.org/releases/mozilla-release/rev/d2a21d941ed5a73a37b3446caa4a49e74ffe854b
I don’t see the bug (haven’t read the article)
You won’t see it just from the diff.
From reading the CVE I got the rough idea
NVD link: CVE-2024-9680
NVD link: CVE-2024-9680