Mozilla fixes Firefox zero-day actively exploited in attacks(bleepingcomputer.com) |
Mozilla fixes Firefox zero-day actively exploited in attacks(bleepingcomputer.com) |
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...
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?).
https://news.ycombinator.com/item?id=33223080
I'd be interested to know if it's sufficient to avoid this recent vulnerability. Either way, it confirms my opinion that UI animations are an anti-feature.
I think it would be a labor of love and craftsmanship to exploit a content process today without using JavaScript.
You don't actually need to stop it before running “snap refresh” though, it'll just be out of date as long as it is kept open. Once the application stops running, next time it is run the updated image will be used.
[caveat: I'm not a snap user myself currently, so my information may be inaccurate, take with a pinch of your favourite condiment]
https://bugzilla.redhat.com/show_activity.cgi?id=2317442
and likely affects Thunderbird as well by the looks of things.
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...
Even if it means some perf drop, modern hardware will get it back in X years, but safety will be significantly improved
Like, the attacker will get write and read access to part or the whole of some other object allocated on the heap, when the memory is reused?
Seems hard to do anything useful with.
And I can imagine that those countries use front companies to buy exploit.
I just hope that those blackhats understand that their discovery might land in the wrong hands.
I guess those blackhats don't like authoritarian regimes.
https://github.com/mozilla/gecko-dev/commit/7a85a111b5f42cdc...
Probably the biggest thing is to have a lot of ram, because if you're really using the virtualization it's a bit ram inefficient.
Many things I expected to be hard or annoying just turn out to be non-issues. Qubes has lots of good automation to make it pretty seamless to use multiple VMs.
I was already a fedora user, so I just copied my old home into a new app vm and was instantly productive. Then over time I weaned myself off the monolithic legacy vm into partitioned VMs.
I've run through a few QubesOS installations over the years and would say for me it's ~2x memory and a couple of cores overhead.
It has been like that for most 'internet software' in the last decades, no light at the end of this tunnel.
Firefox is used in other projects, so the patch needs to spread, and time is needed.
The fix was released today, and FF says they received the report 25 hours before that: https://infosec.exchange/@attackanddefense/11328207943028074...
https://4e6.github.io/firefox-lang-stats/
That's down from 12.49% at the peak in July 2020 so I assume the conversion work was halted after the layoffs in 2020:
https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9e...
https://techrights.org/o/2022/02/17/mozilla-salaries/
https://www.reddit.com/r/browsers/comments/yy986k/can_someon...
The Servo shouldn't have ever been laid off. Yes, I'm aware a team is working on it now, but it isn't up to the same speed and enthusiasm as it was when funded by Mozilla, is it?
At the end of the day web browser is just bunch of parsers and compilers working together, and some video/audio
> Throughout 2024, so far, Mozilla had to fix zero-day vulnerabilities on Firefox only once.
> On March 22, the internet company released security updates to address CVE-2024-29943 and CVE-2024-29944, both critical-severity issues
Vulnerabilities will be found in everything. Firefox is a fully internationalised application and it is FOSS. The team responsible for Firefox is doing a good job.
Different ratios, different consequences, etc.
I think the last part might be crucial.
I think the unfortunate reality is that other browsers will also take advantage of that speed boost, sites will get even more bloated because they can and it will stay unusable for a long long time.
(Wasm isn't safe but could be a building block too)
Not sure why you think that WASM is less secure than JS though. Even if the WASM heap has internal corruption there's no way for this to do damage outside the WASM sandbox that wouldn't be possible in JS.
! No CSS animations
##*,::before,::after:style(transition:none !important;animation-delay:0ms !important;animation-duration:0ms !important)
! No CSS animations (different method)
##*,::before,::after:style(animation-timing-function:step-start !important;transition-timing-function:step-start !important)
! No image filters
##*,::before,::after:style(filter:none !important)
! No text-shadow
##*,::before,::after:style(text-shadow:none !important)
! No box-shadow
##*,::before,::after:style(box-shadow:none !important)
! No rounded corners
##*,::before,::after:style(border-radius:0px !important)
! Un-bold Youtube
youtube.com##*:style(font-weight:400 !important)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.
Java was rejected because of the huge memory requirements and the unpredictable (and sometimes lengthy) garbage-collection pauses.
C# was rejected because (at the time) it was too tied to the Microsoft ecosystem and there was no way to get it to build on all the platforms for which Firefox is available. I don't remember garbage-collection pauses being discussed, but they would also be an issue.
And history has shown that when you need to do that kind of low level code, it's nigh on impossible to achieve acceptable results with a garbage collected language. Many people tried, none really succeeded.
Hence why Rust was made
Can you back this up with a citation?
Once again, JS proves to be a security risk.
Edit: Seems like someone has managed to get CUDA to work, with some effort.
https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin...
If you run multiple GPUs (so one for your GUI and the rest for whatever else you want to do), PCIe passthrough for the latter is pretty straightforward these days.
You can set up a dedicated gpu qube for the former - recommended but optional.
You're right that the trusted codebase is huge, but I sincerely do not know how big a problem this is in practice, hence the question.
In my usage I've never felt the need to share stuff other than the network/sound/storage stuff that qubes make just work. Other devices tend to be just plug them into the particular VM that needs them. YMMV.
I would say that perhaps containers could do just as well, or some other technology. The thing qubes brings to the table is that other people are doing most of the heavy lifting to make a usable desktop out of a highly virtualized system.
There may be path dependent reasons why qubes approach isn't the best possible... but it doesn't matter because so much stuff just working is worth so much. That the compromise we always make when running a distribution... one could meta-x butterfiles and write your own kernel from scratch, or whatever. Or you can run a system created by others. Their system may have decisions you disagree with or are objectively bad, but they saved you 12 months of tinkering with the dynamic linker-- well worth it. :)
For me, the alternative of having my whole laptop compromised by some browser zero day or because a malicious party sent me some malware document was just not viable. I was already carrying two laptops for isolation, and suffering some anxiety from the residual risk. But in my case I've been targeted specifically (due to cryptocurrency bullshit), a friend and former colleague was hit with an astonishingly sophisticated attack that used stuff like BMC vulnerabilities on his web server and then traversal with X11 forwarding and stuff like that all to just break into his desktop.
So I'd probably be using qubes today even if I could only move the mouse with my tongue and the computer was slowed down to the speed for a 486sx. But the incorrect belief that it would be that kinda hit really delayed my adoption. It's a hit, it's real, but at least for my usage it was far smoother than I expected.
I think right now the only obvious wart I experience is that full screen video stutters pretty badly. So I just don't watch video full screen on the laptop now. There are things that might fix it, but I haven't bothered even trying.
There are benefits I didn't expect too. For example, The operating system image in a normal application VM isn't persistent, only your home directory. So you can just scribble all over the OS install in an app vm and it'll go away when you restart it. If you want it to be persistent you change the underlying templatevm. So to get something working I can totally take a chainsaw to my configuration confident I won't get stuck with anything broken. Once I figure out the changes I can apply just the required steps in a template.
Another benefit is that updating fedora versions is a riskless breeze--- install a new template vm. shut down your app vms, click to change template. Restart them if some particular app vm is broken, switch it back and worry about it when you have time.
It’s obvious that laying off people that were working hard at making more robust the flagship product of the non-profit wasn’t going to result in a an increase of security in this product. Could the whole lay-off have been prevented? That would require some number analysis here, and insights I lake.
Could at least some termination have been avoided? Freezing the income of the CEO until some agreed metrics improve, and use the amount thus spare to save some employ salary was certainly an option here, wasn’t it?
Claiming "think of my family, look how much more some other people earn elsewhere" while almost simultaneously (at organization level at least) putting so many people in a jobless position, that’s a rather bold cognitive dissonance to throw at the world to my mind.
If pointing out "odd financial priorities" of a non-profit is flame bait, one might wonder how humanity is supposed to mend all organizational dysfunctions it can ever fall into.
Nobody would care about Mozilla in 2024 without Firefox, but Firefox development seemingly takes a back seat to a variety of other pet projects that Mozilla’s management tries (and keeps failing, over and over) to chase.
For example, they’ve been trying a pivot to become a community-focused privacy company the last couple of years, yet are fine with implementing ad topics.
AFAIK didn’t Safari advocate against it over privacy concerns? If so, what is Mozilla doing?
Or their partnering with a shady company for removing data from data brokers.
Before the privacy pivot, there was the “we want to make browsing better” pivot with their acquisition of Pocket that went nowhere.
From the outside Mozilla looks like a low-scoring charity grift you’d find on CharityNavigator with how far they deviate from the missions they claim to support.
For what it's worth, Python was also considered at some point for use in the Firefox codebase. I don't remember the rationale for not adopting it, but I think the idea was "we all like Python, but we already have one messy language (JavaScript), let's not make it two".
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?
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.
Doesn't Flatpak also solve this?
Was it this one? https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
Or perhaps this one? https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
java applets promised a sandbox and then we had years of continuous vulnerabilities of escaping said sandbox.
And also we'll pay for a bypass of the wasm sandbox. (Actually, looking at our table, I'm going to try and get the bountyamount upped...)
But you're also not running qubes if minimizing battery usage is a high priority for you.
As far as the tedium, perhaps a little, but bringing up a terminal on a non-currently-running app vm takes about 5 seconds for me, so it's faster than you might expect.
I think in general my view is that qubes has serious operating costs but they are much less than I anticipated.
And whats the real alternative? It's still better than carrying 5 laptops in terms of ease and usability.
We live in a world where browsers are constantly required but where their probably hasn't been a single day since their initial releases where Chrome and Firefox were without a RCE vulnerability (though often not a publicly known one).
That's enough for hours of intensive usage on my laptop, like running nodes and compiling stuff. And as you know, I run Qubes too!
I originally got an external battery when I went to Ukraine while Russia was trying to destroy the electricity grid; I got the largest battery I could legally carry on a plane (typically 100Wh is the limit). I ended up liking them enough to buy a few more.
That's... an interesting reduction :) I guess it's about as true as saying that the Linux Kernel is a bunch of I/O and a scheduler?
Also, modern browsers as a whole outsize entire OSes (sans browser)...
A famous one is HotJava. According to Wikipedia, it was also the first web browser to support Java applets.
"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)
At the end of the day, OS is just a bunch of command lines being piped together. /sarcasm
Sure, you are just missing: rendering, layout, security, network traffic for sockets, low-level control over hardware, writing a decent enough VM, image processing, video playback, music playback, compression, decompression, self-update, decryption, don't forget add-ons people love add-ons, also add-on security and isolation, web edit and debug tools, network analysis tools, etc.
You know, little things.
Video and audio I mentioned.
Extensions are tricky, right, but more from privacy standpoint cuz after all you can just expose too much
So browser vendors couldn't rely on the platform to provide up-to-date SSL support. Or MP3 support. Or MPEG-4 support. Or PDF support. This established the norm that browsers would ship their own video support, their own SSL support, and so on.
And Google realised they like the power this gives them - if Google wants to replace HTTP with QUIC or introduce a new video DRM standard, or a new video codec like VP9 - they don't need the cooperation of anyone outside of Google.
If Chrome bundles DRM support (allowing it to play Netflix), and its own HTTP/2 stack for speed - are you going to release a browser that's slower and doesn't play Netflix? Doesn't sound like a recipe for big market share.
There are benefits to this approach, of course, but the costs would have been consequential.
It's going to be the same for crypto and compression. Systems don't ship with brotli for example. The battle tested implementations come to the browsers first in many cases - or at least they're battle tested at the point anyone starts including them in .net or Java.
Because modern browsers are essentially cross-compatible OSes.
Things changed after core
'&' and '&mut', however, are your 'ref readonly' and 'ref' respectively.
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.
The premise of this stays. C# approaches this in a more traditional way, with exposing the set of synchronization primitives. It's a step above C and, usually, C++ still because you don't need to e.g. have an atomic reference counting for objects shared by multiple threads.
Concurrent access itself can be protected as easily as doing
lock (obj) {
// critical section
}
What Rust offers in comparison is strong guarantee for complex scenarios, where you usually have to be much more hands-on. In C#, you can author types which e.g. provide "access lease", that look like 'using var scope = service.EnterScope(); ...`, where using turns into a try-finally block, where finally that calls .Dispose() on the scope is guaranteed to be executed.
It's a big topic, so if you have a specific scenario in mind - let me know.
I do think Rust's mutexes handle almost every use case that can be thrown at them, though, and in a way where it's next to impossible to get it wrong. I think if you're writing a browser engine in the 21st century you should bake in parallelism and concurrency from the start, and Rust is the most suitable language to do that in.
(I've tried [and failed/given up after about 2 weeks] to get a .net desktop application to build on Linux.)
If you have .NET SDK installed (you can get it with apt/dnf install dotnet8 or dotnet-sdk-8.0), you only need the following:
dotnet new install Avalonia.Templates
dotnet new avalonia.app
dotnet run
If you prefer GTK, there are rich GObject bindings that are a successor to GTK#: https://gircore.github.io/
Here are samples that demonstrate basic GTK4 usage scenarios: https://github.com/gircore/gir.core/tree/main/src/Samples/Gt...
All this should require less than 10 minutes including setup and such.
Lastly, I want to make a disclaimer that you do not need C# Dev Kit extension (which requires an account that annoys many people, including me) for VS Code, only the base C# one, which is what gives you language server, debugger, etc. If you are using VSCodium which cannot use closed-source vsdbg component that the base extension uses, you can replace it with https://github.com/muhammadsammy/free-vscode-csharp which uses open-source debugger from Samsung instead. It can be rough around the edges but works well enough in standard scenarios. Just don't use Debugger.WriteLine over Console. :D