When we announced the security flaw CVE-2024-11053 on December 11, 2024 together with the release of curl 8.11.1 we fixed a security bug that was introduced in a curl release 9039 days ago. That is close to twenty-five years.
The previous record holder was CVE-2022-35252 at 8729 days.
↫ Daniel Stenberg
Ir’s really quite fascinating to see details like this about such a widepsread and widely used tool like curl. The bug in question was a logic error, which made Stenberg detail how any modern language like Rust, instead of C, would not have prevented this issue. Still, about 40% of all security issues in curl stem from not using a memory-safe language, or about 50% of all high/critical severity ones. I understand that jumping on every bandwagon and rewriting everything in a memory-safe language is a lot harder than it sounds, but I also feel like it’s getting harder and harder to keep justifying using old languages like C.
I really don’t know why people get so incredibly upset at the cold, hard data about this.
Anyway, the issue that sparked this post is fixed in curl 8.11.1.
People understandably gets incredibly irritated about the push for rewriting existing code, more specifically “already debugged code”.
As this story points out, not all errors are memory related, and rewriting code will inevitably introduce logic errors.
IMHO the general rule should be: use newer tooling/languages in new projects, but don’t rewrite already debugged old projects just because of the new tooling/languages.
Note that there are times that accrued technical debt in a codebase makes it easier to rewrite than to shoehorn new features in there. But that is independent of the tooling/languages used.
Antartica_,
It may be a logical contradiction when “debugged code” still has bugs, but it happens to the best of us. Large code bases become larger than human capacity to certify there are no errors.
This is true. It might be hard to justify rewriting code in safer languages in the short term. However over the long term the opportunity cost of sticking with insecure C code always gets worse. We could subject ourselves to these memory faults ad infinitum on the basis that we don’t want to be inconvenienced and burdened with rewrites today. However if only we can get it done we’d save future generations from the many flaws that insecure languages have exhibited for half a century and counting.
Ah hypothetical dilemmas…in reality most of society is motivated by short term agendas at the expense of future progress.
I think this is the best we can expect too. However it’s not necessarily ideal because incumbents can and often do use their market dominance to impede better alternatives, for better or worse. Just the way it goes I suppose.
Indeed. This rings true for many of the corporate projects that I work on. Even so, I don’t see much risk of them getting displaced any time soon. Managers in many organizations take pride in their existing code bases even when it’s very costly and difficult to maintain and modernize them. Look at mainframes, haha. Suggesting their past investments need to be thrown away often puts executives off even if it’s warranted by facts on the ground.
Certainly long-lived, big and complex codebases are difficult to renew.
I feel lucky to work mainly with heavily distributed systems in which no part is too big. Being distributed means that the boundaries are well defined, at minimum in machine-to-machine protocols, and if the protocol and config files are keep intact, components can be rewritten/replaced pieacemeal.
More generally, I think that is a strength of Zig versus Rust; at the cost of losing idiomatic interfaces, you can replace a codebase in “sourcefile increments”.
” I also feel like it’s getting harder and harder to keep justifying using old languages like C.”
Well they do say it’s a logic error, not a language-caused one:
” This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.”
ChodaSly,
That’s exactly what Thom Holwerda said.
Anyway, while it is true that memory safe languages don’t fix logic bugs in semantically correct code, I don’t think this is a great excuse for dismissing memory safe languages. Consider this parallel: The vast majority of airline accidents aren’t related to MCAS, but that’s no excuse for not fixing MCAS.
https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System
I feel the same way about software engineering. C is hard to replace, but this still has to happen for the software industry to solve the systemic memory problems of the past 5 decades.
I see the importance of replacing C, although I sympathize with those who don’t like rust’s syntax…neither do I. So many languages have a C-like syntax…even javascript. I think a familiar syntax would have made these code migrations more palatable.
But he admits 40-50% of security bugs could have been prevented via memory safe languages. So that seems obvious if you’re doing a rewrite to not use c. It doesn’t mean you won’t screw up some other way., but the lack of a perfect language that prevents any developer from ever introducing a bug shouldn’t stop one from using the best one available today.