Using memory safe languages may help, but the core issue lies on the lack of understanding of the program as a whole. Hence, the over reliance on fuzzing.
Debating what the "core issue" is may be an interesting philosophical debate, but at the end of the day, using a memory-safe language would have prevented this issue from being exploitable.
I understand, really.
But much of the discussion is already on that topic. It's not that I don't consider it unimportant.
I'm just trying to point out a bigger issue with software, in my opinion. Even more so when talking about the standard implementation of an image format as big as this. It really puts a lot into perspective on how bad software is commonly designed.
Luckily type safe languages, which includes memory safe languages, help you in understanding the program as a whole better, and strictly prevent you from doing things against that understanding, because the types literally encode automatically proven properties of your code.
Not all memory safe languages are type safe. I'd argue that expressive ML-style typing is if anything more important than memory safety, although it's hard to tell since a type-safe language will almost always have to be memory-safe.
I never claimed all memory safe languages are type safe. But memory safety is a subset of type safety. Whether dynamic or static (though I’m much in the latter camp), memory safety is achieved through information associated with the types. Whether that’s exposed to the surface or not: Rust exposes it and is static, Haskell normally does not expose it and is also static, most modern dynamic languages are memory safe but don’t expose the associated information.
> But memory safety is a subset of type safety. Whether dynamic or static (though I’m much in the latter camp), memory safety is achieved through information associated with the types.
Nah. Dynamic languages don't actually have types (even if they have something that they call types), and even typed-but-GCed languages often don't really use the types for memory safety.
They have value types. The expressions don’t have types (or rather very general types), but the values do, and it’s still possible to have a dynamic language with very rigorous value types that have a well-defined set of inhabitants.
Any dynamic language that has a string type has something similar to (for example) a buffer and a length associated with it internally. You can formalize that from the compiler’s perspective, even if you don’t expose it to the outside.
You could argue that the language doesn’t necessarily have memory safety associated with its types, because a compliant compiler or interpreter could represent strings in any way it chooses, and on some academic level there’s merit to that, but in practice you’d be rather stupid to implement the string value type in an interpreter or compiler for a language with a common string type in a memory unsafe way.
At least theoretically one could have a dynamic language with e.g. C-style malloc/free manual memory management, although I haven't actually seen such a thing in practice.
[1] https://security.googleblog.com/2021/02/mitigating-memory-sa...