I think at this point we've established that it's C which is just irreparably broken.
Blaming the OpenSSL developers for writing bad C is just a "no true scotsman" at this point, since there is no large, popular C codebase in existence that I'm aware of that avoids running into vulnerabilities like this; vulnerabilities that just about every other language (mainly excluding C++) would have prevented from becoming an RCE, and likely prevented from even being a DoS. Memory safe languages obviously can't prevent all vulnerabilities, since the developer can still intentionally or unintentionally write code that simply does the wrong thing, but memory safe languages can prevent a lot of dumb vulnerabilities, including this one.
No feasible amount of funding would have prevented this, since it continues to happen to much better funded projects also written in C.
On the other hand, I guess we could blame the OpenSSL developers for writing C at all, being unwilling to start writing new code in a memory safe language of some kind, and ideally rewriting particularly risks code paths like parsers as well. We've learned this lesson the hard way a thousand times. C isn't going away any time soon (unfortunately), but that doesn't mean we have to continue writing new vulnerabilities like this one, which was written in the last two years.
> Blaming the OpenSSL developers for writing bad C is just a "no true scotsman" at this point, since there is no large, popular C codebase in existence that I'm aware of that avoids running into vulnerabilities like this; vulnerabilities that just about every other language (mainly excluding C++) would have prevented from becoming an RCE
No, this whole thing is about the lack of testing. Adding a parser without matching tests is just absurd regardless of the language it's implemented with. If only for basic correctness check, you want a test.
Not all vulnerabilities or bugs are memory-related, vulnerabilities are bound to surface in any language with that kind of organizational culture.
Keep in mind that Ubuntu compiled OpenSSL using a gcc flag that turns this one byte overflow into a crash instead of a memory leak/corrpution because it has a way to do that already. It's very risky, and a very long term project to rewrite something with this level of history into a completely new language.
> It's very risky, and a very long term project to rewrite something with this level of history into a completely new language.
I didn't suggest a complete rewrite of the project. However, they could choose to only write new code in something else, and they could rewrite certain critical paths too. The bulk of the code would continue to be a liability written in C.
I agree that it would be nearly impossible to rewrite OpenSSL as-is. It would take huge amounts of funding and time. In general, people with that much funding are probably better off starting from scratch and focusing on only the most commonly used functionality, as well as designing the public interface to be more ergonomic / harder to misuse.
qmail in 32-bit mode (which was the default when it was written) had no issues. One issue was found in 64-bit mode without memory limits (against the explicit recommendation).
Most "safe" languages like Python are written in C and are full of segfaults, mostly due to the high churn rate and the attitude of the developers.
I haven't tried Rust yet, so I won't comment on that.
I'm of the opinion that in cases like this, it'd be better for the organization to close, and allow the gap to be filled naturaly.
If the current OpenSSL maintainers closed the project, given its importance, there would be a rush to follow up maintenance. Chances are, it'd be better funded; even in worst case, it'll hardly be assigned less than two devs.
This a case of the general dynamic where a barely-sufficient-but-arguably-insufficient solution prevents actors from finding and executing a proper one.
You don't even have to close. You can just refuse to merge code which does not include 100% test coverage. If someone wants the feature badly enough, they will figure out a way to fill the gap. Alternatively, someone can always fork the code and release "OpenSSL-but-with-lots-of-untested-code" variant.
For a project like OpenSSL, it's not just having "enough" developers (whatever that is) it's having qualified developers. Writing good crypto code requires deep expertise. There aren't a lot of people with such expertise whose time is not already fully committed.
The OpenSSL team is actually very good and they do very good work, and they even have funding. The problem is that legacy never goes away, and OpenSSL is a huge pile of legacy code, and it will take a long long time to a) fix all the issues (e.g., code coverage), b) migrate OpenSSL to not-C or the industry to not-OpenSSL.
This vulnerable parser of attacker-controlled remote input was written from scratch in C in 2020, without a fuzz harness even though OpenSSL is critical infrastructure and is already hooked up to oss-fuzz.
It is simply difficult to reconcile these facts with the idea that it is a very good team doing very good work.
