mozdeco

26 ms·

1.
by mozdeco 27d ago
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
2.
by mozdeco 27d ago
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
3.
by mozdeco 4mo ago
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 eas
4.
by mozdeco 4mo ago
> 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?
5.
by mozdeco 4mo ago
No, it's a new post, see also https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
6.
by mozdeco 4mo ago
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...
7.
by mozdeco 4mo ago
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 vulnerabili
8.
by mozdeco 7mo ago
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 u
9.
by mozdeco 7mo ago
[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
10.
by mozdeco 7mo ago
[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
11.
by mozdeco 7mo ago
And the Firefox side of the story: https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...
12.
by mozdeco 5y ago
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.
13.
by mozdeco 5y ago
> 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 st
14.
by mozdeco 5y ago
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 reques
15.
by mozdeco 5y ago
> 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
16.
by mozdeco 5y ago
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.
17.
by mozdeco 5y ago
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.
18.
by mozdeco 5y ago
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,
19.
by mozdeco 5y ago
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.