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

We put out something that describes our new approach to handle the patch gap: https://blog.mozilla.org/en/firefox/privacy-security/defendi...

The actual fingerprinting here does not work in Firefox though.

A colleague of mine made a recent post here: https://ritter.vg/blog-webaudio_alibaba.html

We already did, long ago, and this fingerprinting here does not work in Firefox.

A colleague of mine made a recent post here: https://ritter.vg/blog-webaudio_alibaba.html

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.

No, it's a new post, see also

https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...

No, we actually just posted a follow-up story with more details and opened several bugs, see also:

https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...

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.

And the Firefox side of the story: https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...

The infinite busy loop in this case was not the tab no (neither visible or invisible). The loop was directly in the network stack, as stated in the post, not in the caller.

> code that can end up blocking forever should have a timeout and recover from that timeout happening.

There was no way for the calling code to do this. This was literally an infinite loop inside the network stack. Imagine the network stack itself going `while(1) {}` on you, without checking if the request was canceled.

Even if you detect that this happens, there is nothing you can do as the caller. You can't even properly stop the thread, as it is not cooperating. So recovering from this type of failure is hard.

All requests go through one socket thread, no matter which HTTP version. I am not a Necko engineer, but since requests can be upgraded, an HTTP/1 request could switch to HTTP/2 and if there was a separation by protocol, the request would have to be "moved" to a different thread. So I'm not sure that would work easily.

> the fix has to be in the code that communicates back, it should fail gracefully.

The bug that caused the hang was in the network stack itself. There was no way the calling code could have prevented this in any way. You can see this by taking a look at the linked HTTP3 code. It's not that the higher-level code kept retrying over and over causing the hang, that was not the problem here.

Under "Lessons learned" you can also read "investigating action points both to make the browser more resilient towards such problems". I agree that this is broadly spoken, but it covers ideas that would have made this technically recoverable (e.g. can network requests be compartmentalized to not block on a single network thread?).

At this point, the code relied on the Content-Length header being present because the higher-level API was supposed to add it. The field that is supposed to be populated by Content-Length (mRequestBodyLenRemaining) is pre-initialized to 0.

Firefox generally does not block if a remote connection does not work. As explained in the post, the infinite loop was a bug in the network stack itself.

So yes, you can use Firefox in any offline environment.

This is absolutely true and hence we combine not only our tests with TSan, but also fuzzing, to explore even more corner cases.

On the static vs. dynamic side, I would always opt for the dynamic when it can guarantee me no false positives, even if the results are incomplete. It is pretty much impossible to deploy a tool that produces lots of false positives because developers usually will reject it at some point and question every result.

It would probably be fairly easy to change Qt's Mutex implementation to be TSan-compatible and only do so for TSan builds (by swapping out the fences for atomics when building with TSan). This is what we did in Firefox.