They've only linked a few tickets, so of course maybe when we see all 271 actual distinct things the insight won't apply but all those I examined ended up as some C++ code with a nasty bug in it.
Firefox is written in several languages, only about 25% of it is in C++ but every single one of these issues seems to touch the C++.
A general limitation of this approach is that it is only as good as your validator, and there's nothing easier to validate than a test case that creates, say, an AddressSanitizer use-after-free. For subtler issues will we have to more specific validators or will the LLM become better at coming up with other dangerous conditions it will verify? We'll see.
> A general limitation of this approach is that it is only as good as your validator, and there's nothing easier to validate than a test case that creates, say, an AddressSanitizer use-after-free
Sure, but, surely AddressSanitizer would also detect the same problem in the C or Rust which together also make up about 25% of Firefox so... ?
It's possible Mythos is a lot better at finding vulnerabilities in C++ code than it is for other languages. After all, these models are also based on pre-existing security analysis.
From what I can tell, a lot of these bugs were hardly C++-specific, they just happened in C++ code. Even the most secure Rust can't magically catch things like TOCTOU issues.
> Even the most secure Rust can't magically catch things like TOCTOU issues
I suppose it depends what the word "magically" means. A ToCToU race is because you imagined things wouldn't change but they did and in Rust you actually do write fewer patterns with this mistake because of the Mutable xor Aliased rule. If we have at least one immutable reference to a Goose then Rust isn't OK with anybody mutating the Goose, your safe Rust can't do that and unsafe Rust mustn't do that. So the ToCToU race caused by "Oops I forgot somebody else might change the Goose" is less likely because you were made to wrestle with this problem during design - the safe Rust where you just forgot about this doesn't compile.
But there is AddressSanitizer for Rust and for C too right? As I understand it AddressSanitizer consumes LLVM IR, so from its point of view some C, C++ or Rust is all the same, and presumably also if you are a famous Russian streamer and you hand wrote LLVM IR instead of using a real programming language that too?
Yes I was including C in "C++". I dunno how much C Firefox uses.
And I presume you can run AddressSanitizer with Rust but given Rust is memory safe by default, it's only going to find issues in `unsafe` code which is a tiny tiny fraction of most code. Google had a blog post a few months ago where they managed to put some actual numbers on this, because they almost shipped one Rust memory safety bug.
The lesson for other projects is very different if the reason these are all C++ bugs is just "We didn't ask Mythos for the bugs in Rust" versus if the difference is that asking Mythos for similar bugs in the Rust is futile because it won't find any.
Some of this is tempered if the pattern is that Mythos finds bugs mostly in dusty old C++ but the rates are much, much lower in newer C++, the reverse of Google's earlier finding for human researchers.
> The lesson for other projects is very different if the reason these are all C++ bugs is just "We didn't ask Mythos for the bugs in Rust" versus if the difference is that asking Mythos for similar bugs in the Rust is futile because it won't find any.
The answer is both of those. They didn't ask for bugs in the Rust code because it wouldn't have found any. They've explicitly set it up to only look for memory safety bugs. It's not going to find any in a memory safe language.
> There exist memory safety bugs in Rust projects, so you will find them. Or maybe not with AI, as there is not enough training data?
No, there are simply too few memory safety bugs in Rust projects for AI to find any. It found 271 bugs in Firefox so you're talking around 0.3 bugs found in the same amount of Rust.
> The 70% number google claims is either BS or google-specific as other projects reported far lower numbers.
The post I linked didn't mention 70% so I guess you didn't read it. And if you're talking about the "70% of C/C++ security bugs are due to memory safety" stat, then no it isn't bullshit. The same (or very similar) number has been found by numerous companies and projects. Not that that stat is relevant here.
It is impossible to interpret this number (271) without looking into details. People certainly found plenty of memory safety and others bugs in Rust projects in the past, so I do not understand you claim that there too few to find any.
Curl reported 40% and more recently it dropped to about 20% of issues caused by their use of C. And this even with the requirement to stick to old C89. OpenBSD reported 30%. I assume the 70% either have to do with C++ or - more likely - there is a huge selection bias.
> I assume the 70% either have to do with C++ or - more likely - there is a huge selection bias.
Daniel admits that he "might" just be counting differently.
I expect some of it is C++ because there sure is plenty of additional complexity to fit in the same size brain and yet you retain the same absolute requirement to juggle everything at all times or the software blows up but I'd be very surprised if it accounted for this huge disparity.
> It's not going to find any in a memory safe language.
I mean, it's not supposed to find any in the unsafe language either, but that's why it was used.
Firefox not only uses unstable Rust features (via the exemption mechanism the same way Linux does it, trained professionals, closed course, do not attempt at home) it also presumably has some volume of its own explicitly unsafe Rust and so there's no reason this could not be checked, and what makes the difference here is whether it was or was not.
> I mean, it's not supposed to find any in the unsafe language either, but that's why it was used.
No it is supposed to find them in C++, because we all know humans are infallible and it's super easy to write memory errors in C++.
The whole point of Rust is that the borrow checker is infallible (pretty much anyway).
> it also presumably has some volume of its own explicitly unsafe Rust
"Some volume" is so tiny as to be irrelevant. There's no point going to this effort if Rust memory safety vulnerabilities are 1000 times less frequent than in C++.
I assume you intended either "humans are fallible" or "humans aren't infallible" ?
I'd like to understand if Rust was skipped because they assumed it would be fine, skipped purely as happenstance, or in fact tested and found to not be problem. I don't like assuming things when I could measure instead.
Firefox is written in several languages, only about 25% of it is in C++ but every single one of these issues seems to touch the C++.