I'd rather prefer people saying "C has a long history of damaging security" and that's it, no asbestos here. Is a personal preference of mine. Less chances to misinterpret something.
At least it's not a "comparing Linux kernel to a car" situation I've also seen.
That article wins the argument for me, and I'm not a fan of C particularly.
Admittedly it doesn't address security concerns, but the fact they're able to achieve 100% machine code level branch coverage (I wonder if that includes the possibility of executing injected code...) should go a long way towards generating confidence that there are no readily exploitable vulnerabilities.
Agreed, however that is against the culture of those that decide to stick with C no matter what.
Secure by default with option to turn those features off for performance, has been the way other systems programming languages have been designed since 1961.
That C culture is now being forced to change, because fixing memory corruption CVEs in devices that are permanently under security exploits attacks does not scale.
Agreed. Sad to see that it hasn't been upvoted much.
To me the article was a very clear warning on the horrific state of software security and that no one should be under any illusions of how little protection they have. My tangible take away is what you've mentioned: stop using C.
My gut feeling is that if you really want security in C, you have fewer constructs to misuse and so you get less unexpected behaviour. At the same time, you get more protection mechanisms; guard pages etc. I.e. harder to be secure, but if you really want to harden, you can get harder than in higher level languages.
I'm not putting any kind of weight behind that, though; I just feel that it's a bit odd for people (not specifically meaning you, just the whole thread) to criticise this purely on language choice and not put any substance behind their criticisms that actually relate to the software in question.
It's really great to see this level of hardware innovation and investment into security! Although it's a bit of a shame that we're down this path because of the inertia of unsafe programming languages and systems that put performance first. In some sense we're starting to pay back a big debt.
I try to choose my words carefully (these kinds of conversations can get pretty toxic pretty quick). But honestly I think in the long arc of history, C will be regarded like asbestos: very obviously dangerous in retrospect. I respect the designers of C immensely and the amount of work many thousands of people the world over have put into that entire toolchain and ecosystem, but we can't blamelessly have that conversation yet, so I guess I'll stop here.
"Loads of languages have old functions that could be better with hindsight"
Strawman. C's predecessors did it better with foresight. One of best such systems was built by C's inventors. BCPL author and C inventors deliberately removed safety at OS and language level due to hardware constraints plus personal preferences. Then nobody changed it to avoid work or broken apps. Hindsight aspect has nothing to do with it.
"C isn't going away any time soon, and there's no value in decrying it as a response to being told about a feature that makes it safer!"
Got mixed feelings on when to slam C or help its users out. I agree with you that bashing it at a comment on a safety improvement is probably a bad idea. It might have effect of reducing number of people promoting safer C strategies. I usually ignore, upvote them, or mention stuff like SAFEcode/Softbound depending on what's in comment. I go anti-C when misinformation shows up or on more general topics of safe, efficient apps.
Life experience since I touched C for the first time in 1992.
So yes I do belive, given the quality of the code bases I have seen in production.
And as discussed at Linux Kernel Security Summit 2018, which videos are freely available for you to watch as well, even with the rigorous process to accept patchs into the kernel, CVEs keep increasing.
68% of them were caused by memory corruption, something mostly unique to C and languages that are copy-paste compatible with it.
Then another good chunk was related to UB, something that even Linus already ranted a few times.
So yeah, Safe C is an oxymoron, unless we are talking about a new variant with safety turned on by default, where warnings are dealt as errors and everyone uses static analysers that break their CI builds on error.
Which is relatively inconsequential as long as there's a clear boundary between things that can be manipulated by a user and the C code.
It'd be better if it wasn't C at all, sure, but, from a security perspective I'd take a language with a C runtime over a language where code has to be carefully written in a memory-safe manner any day.
vulnerabilities were not caused by using C, they were caused by human error. C may be harder to read, but it is way faster than most of the alternatives.
Oh come on. People that know of the pitfalls build useful abstractions that keep someone falling in from burning down the house. Look to the Linux kernel for evidence of C being used by responsible people, not morons that can't rise above hacking on raw memory straight out the socket.
I feel your statement is actually much closer to the danger. C is pretty close to the hardware indeed and that misleads people into thinking that C is actually exactly how the hardware works. It's a very easy trap to fall into and I've seen many colleagues do just that.
It is fascinating how despite the thousands and thousands of high profile memory related RCE vulnerabilities, how this community doesn't seem to like pointing the fact that C is an unsafe language.
At least it's not a "comparing Linux kernel to a car" situation I've also seen.
reply