mozdeco

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.

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.

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).

As described in our blog posts, our harness/pipeline only looks for crashes so all of the bugs resulting from that do have PoCs. There is a smaller number of bugs found by manual auditing that didn't have PoCs but I'd say easily more than 90% of all of the bugs we are talking about had a PoC.

> But report [1] says that "Some of these bugs showed evidence of memory corruption...", which implies that majority of these (which includes 271 bugs from Mythos) don't have evidence at all. Do I not understand something?

This is just the standard sentence we've been using for years. It has nothing to do with Mythos and for Mythos, almost all bugs show evidence of memory corruption (we do have a handful of bugs in JS IPC / JS Actors, one is in the blog post).

> Mythos is supposed to be pretty good at writing actual exploits, so (as I understand) there shouldn't be any serious problems with checking if bug is vulnerability or not.

Yes but if we have a choice between writing exploits and scanning more source, potentially finding more bugs, then of course we prioritize the latter.

Mythos did in fact write PoCs for all bugs that crash with demonstration of memory-unsafe behavior (e.g. use-after-free, out-of-bounds reads/writes, etc).

For us this is substantial enough evidence to consider it a security vulnerability at that point, unless shown otherwise and it has always been this way (also for fuzzing bugs).

The bugs are at least of the same quality as our internal fuzzing bugs. They are either crashes or assertion failures, both of these are considered bugs by us. But they have of course a varying value. Not every single assertion failure is ultimately a high impact bug, some of these don't have an impact on the user at all - the same applies to fuzzing bugs though, there is really no difference here. And ultimately we want to fix all of these because assertions have the potential to find very complex bugs, but only if you keep your software "clean" wrt to assertion failures.

The curl situation was completely different because as far as I know, these bugs were not filed with actual testcases. They were purely static bugs and those kinds of reports eat up a lot of valuable resources in order to validate.

[working for Mozilla]

That's because there were none. All bugs came with verifiable testcases (crash tests) that crashed the browser or the JS shell.

For the JS shell, similar to fuzzing, a small fraction of these bugs were bugs in the shell itself (i.e. testing only) - but according to our fuzzing guidelines, these are not false positives and they will also be fixed.

[work at Mozilla]

I agree that LLMs are sometimes wrong, which is why this new method here is so valuable - it provides us with easily verifiable testcases rather than just some kind of analysis that could be right or wrong. Purely triaging through vulnerability reports that are static (i.e. no actual PoC) is very time consuming and false-positive prone (same issue with pure static analysis).

I can't really confirm the part about "local" bugs anymore though, but that might also be a model thing. When I did experiments longer ago, this was certainly true, esp. for the "one shot" approaches where you basically prompt it once with source code and want some analysis back. But this actually changed with agentic SDKs where more context can be pulled together automatically.