CVE-2024-7532 (high-severity) does not only effect Google Chrome:
To my knowledge it is unknown if exploits exist but as the patches have been rolled out I would assume exploits do exist. The flaw allows RCE without javascript.
At least one template has not rolled out an update which fixes its browser. In most browsers you can check for updates in the About-Tab. It is the distros responsibility to roll out the updated browsers and I expect them to do so during the next 24 hours.
If not… the XEN hypervisor is very likely to contain working exploits to your (maybe disposable ) qube. Never consider any browser to be secure. Paranoia can be your friend.
I didn’t write that the XEN hypervisor is vulnerable. I wrote that it will contain someone with RCE through your not-up-to-date-browser to the qube you are using.
There is nothing special with this CVE then. People should patch their software, I mean, nothing really new here. This kind of critical vulnerability is not exceptional.
The purpose of Qubes OS is indeed to reduce damage in case of a vulnerability being exploited by separating contexts/workflows, but it does not mitigate vulnerabilities in software. I hope people do not assume it magically protects their computer
Using disposables may help a bit because if a vulnerability is exploited, it will not persist once the disposable stops, meanwhile the template is likely to receive a patch so the next disposable starting will not be vulnerable anymore. This would not prevent an attacker to steal data from the disposable qube, or use the infected system for a DDoS though.
Agreed. Then we are on the same page I assume. Thought for a while I’m not using the word “contain” correctly.
Regarding the question if a vulnerability is critical or exceptional… browser vendors have been promising their products to be secure and to have rock-solid sandboxing for years. On YT Fabian F. (“live overflow”) interviewed - I believe 5 or 6 different - security researchers, one from Google’s project zero, about browser security and all of them said something like “nearly impossible to get RCE”, “very, very unlikely” and so forth. Yet, after that interview Fabian made a series about binary exploitation focusing on browsers. And there have been tons of critical CVEs found in every browser in the years after this interview.
As the browsers - and very likely there are a lot of apps which rely in parts on the same code base, the electron framework for instance - are used by almost everyone and all the time, I thought this CVE might be worth to mention, especially as some distros need time to propagate their security updates.
I’m using a vulnerable browser right now. So yes, this is a good opportunity to praise QubesOS and Xen. See you around and have a great day.
I wonder if this vulnerability could be used if a safer memory allocator is in use. On OpenBSD, the strict malloc function usually prevent a lot of memory related exploits by crashing the software when it tries write where it should not, but this has a performance cost.
I would be very interested in seeing more general exploit protections in VMs. Just because Qubes protects your other VMs if you get hacked doesn’t mean I want to be hacked in the first place. I think there would be real value in the project investing in hardening templates that focused less on intra-VM sandboxing and rather on soft targets (libs, memory allocators, systemd, etc.) and Xen targets (i.e. privilege escalation; I’m not familiar enough with Xen to do the recommending here, but that’s why I’d want specifically the Qubes team to work on this).
That being said, I don’t think this is the best usage of the devs’ time either. I’d still love to see some work on templates (Fedora and Debian hardening, or even a different template designed solely for security, although I think it would be better to work with existing templates unless there is a significant benefit to a custom one).
And to top it all off, I’d like to add/admit that I believe that there’s nothing you can do to make browsers trusted short of disabling javascript (and CSS here soon). And even then I wouldn’t be too eager to trust them. I would really love to see split-browser mainlined. I do think that would be a good use of the devs’ time considering just how vulnerable browsers are and just how much they’re used.
There have been reports about parsers and libraries for webp (CVE-2023-4863 allowing RCE) and even HTML (allowing XSS). I would like to argue that Xen and Qubes should stick to VM isolation business, but kernel developers and distros should invest more in hardening and mitigating exploits.
For instance a kernel could disallow that a binary without stack protection is started. This would have prevented CVE-2023-4863 which was a deliberate backdoor. Compiling a binary without stack-protection is intent, not negligence.
) qube. Never consider any browser to be secure. Paranoia can be your friend.
