Thank you for the link. Could you explain why an attacker needs an exploit in both the renderer and sandbox? Why is an RCE in just one not game over?
mozdeco 16 hours ago [-]
The renderer (called ContentProcess in Firefox) is the process that's interacting with untrusted web content, so this is the process you would initially have to compromise. But that process is heavily sandboxed (can't just read files or run unsandboxed code), so in order to break out of that, you need a second exploit in one of the higher privileged processes.
holystatesman 4 hours ago [-]
There are some heavy limitations worth highlighting here.
Firefox compromises also depended on a separate, previously unpublished vulnerability. Mozilla patched that vulnerability in Firefox 159.0 on October 27, 2026.
The researchers were unable to reproduce comparable results against Chrome, despite spending roughly $100,000 testing it.
zb3 17 hours ago [-]
What is the solution implied here? Attackers - whoever they are - already have them, so perhaps it's time we close the patch gap instead.
mozdeco 17 hours ago [-]
Closing the patch gap completely is unfortunately impossible.
One strategy that can help in the meantime is to make sure that we never have fixes for both renderer vulnerabilities and sandbox escapes in one patch gap at the same time. That's a new strategy we're working on right now.
The problem is also only relevant as long as security vulnerabilities still make it into release. The models are getting better and better at finding the pre-existing ones as well as newly introduced ones by commit scanning (which never make it to release then).
armcat 17 hours ago [-]
The article doesn't establish whether AI ultimately benefits attackers more than defenders. Open weight models give defenders access to the same capabilities. At the very least the community has a level of symmetry they wouldn't otherwise have.
mozdeco 17 hours ago [-]
Ultimately, I would say it favors the defenders.
Right now, we are in this transition phase where models discovers tons of latent bugs everywhere. That makes it easier for attackers of course to find a single bug, and lots of fixes means lots of things to reverse-engineer in the patch-gap. But that won't be going on forever, as the number of bugs to find here are finite. Assuming that we use the same models/techniques to scan all commits being made, we'll end up with a codebase that is much much safer than what we had before.
16 hours ago [-]
pizza234 17 hours ago [-]
It depends on who attacker and defender are.
Excluding the modern equivalent of a script kiddie, even a "budget" attacker will have for sure invested enough to run a serious model (GLM 5.3 in this case, which requires hundreds of GB of RAM).
On the other hand - the defense - there is a large spectrum, and that's where the problem lies. There are surely companies that can defend themselves (either via cloud solution with granted cyber capabilities, or on local powerful machines), but there is a large amount of people that don't even know how to run a local LLM, let alone compile a program like Firefox.
Firefox compromises also depended on a separate, previously unpublished vulnerability. Mozilla patched that vulnerability in Firefox 159.0 on October 27, 2026.
The researchers were unable to reproduce comparable results against Chrome, despite spending roughly $100,000 testing it.
One strategy that can help in the meantime is to make sure that we never have fixes for both renderer vulnerabilities and sandbox escapes in one patch gap at the same time. That's a new strategy we're working on right now.
The problem is also only relevant as long as security vulnerabilities still make it into release. The models are getting better and better at finding the pre-existing ones as well as newly introduced ones by commit scanning (which never make it to release then).
Right now, we are in this transition phase where models discovers tons of latent bugs everywhere. That makes it easier for attackers of course to find a single bug, and lots of fixes means lots of things to reverse-engineer in the patch-gap. But that won't be going on forever, as the number of bugs to find here are finite. Assuming that we use the same models/techniques to scan all commits being made, we'll end up with a codebase that is much much safer than what we had before.
Excluding the modern equivalent of a script kiddie, even a "budget" attacker will have for sure invested enough to run a serious model (GLM 5.3 in this case, which requires hundreds of GB of RAM).
On the other hand - the defense - there is a large spectrum, and that's where the problem lies. There are surely companies that can defend themselves (either via cloud solution with granted cyber capabilities, or on local powerful machines), but there is a large amount of people that don't even know how to run a local LLM, let alone compile a program like Firefox.