This is inflammatory and vapid. OpenSSL just needs better code review and should follow the standards they are programming to. It's not the death knell for an entire programming language.
True, though hopefully it will make people thing that, no matter how smart the programmers working on a project of a similar caliber are, there will be, for the most part, vulnerabilities like this caused by using C.
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.
Perhaps you missed the part of the drama where it was revealed years ago that OpenSSL prefers to roll it's own malloc rather than work out issues in their code that were exposed when porting to other platforms? OpenSSL would just have rolled their own shit to circumvent whatever protections you think other languages provide.
It's the attitude that was wrong, not the language. Stupid always finds a way. Back in the day, porting to different compilers and platforms was one way to find and quash bugs. Nowadays I guess you can just pitch a single OSS compiler and rely on it's implementation details and bugs. Drag your own chunks of libc around and presto, no porting headaches. That's such a stupid attitude.
The discipline, as he said, to Not Be Stupid. There's still a floor on the error rate, but it's entirely possible to use these tools responsibly.
I will believe Rust when I see it. We may, however, look at Lua. That might not sell, though. Lua is amazing but I'm not sure a culture is ready to bifurcate its code base like that.
Given the complexity of all this, it's amazing we don't get a Heartbleed sized thing per week. The color and shape of this reminds me of when markets take a tumble because of a cascading failure - some poor schmoe ends up with a margin call and everybody sweats a lot for a while.
At work, I do this: "Are you done?" "Yeah, but I don't trust it yet." They're really nice about this.
The problem is that no other language has captured the good points of C anywhere near as good as C. There are ways of using C that are much less likely to result in this type of bug - and the more complex processing that other popular languages can add in surprising places can cause bugs too. I've been meaning to learn ATS that basically adds a separate validation layer to C:
http://www.ats-lang.org/
I love Go, but it is a prime example of a language that fails on the problem C solves that nothing else does that I mentioned in another post on this thread...
Getting Go to link to anything but C (and C++, but only if it uses C interfaces) is (depending upon the specifics of the other language) difficult to nearly impossible (and at some point certainly involves using C anyway).
... not until something else with a sane, stable ABI that everyone agrees upon comes along (and before anyone points it out, I realize C has no actual standard defined ABI, but it doesn't matter in practice because following the OS/arch ABI is always the path of least resistance when linking C).
For all of its issues, C is still incredibly important for being the only language you can fairly easily integrate with virtually any other language.
There's a small set of systems code for which C is a requirement, for various reasons. (There are experimental systems trying to get non-C languages into those areas too, and more power to them.)
But today, writing large piles of new C code interacting with untrusted users and data is both painful and irresponsible. Pick a higher-level language, any higher-level language.
As far as I can tell, the main thing keeping C in its entrenched position these days isn't performance, or preference; it's C's status as the language of the native platform, that every other decently powerful language can talk to via FFI. If you write a new library in language $FOO, it'll mostly get used by other code in $FOO; if you write a new library in C, many different languages can use it.
However, adhering to the C ABI does not require writing code in C. And if enough new libraries start providing a C interface backed by a more powerful language, perhaps we can start establishing careful extensions to the C ABI to better fit higher-level languages (such as standard ways to pass buffers).
That's not to say there aren't new classes of systemic bugs in other languages, too. And FFI code, by necessity, lets you write C-like bugs. However, there's no excuse for buffer overflows and integer overflows anymore when any decent high-level language has buffer types and bignums.
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.
Please, it can happen in any language, it depends on how you write it. If you do not sanitize your inputs you get sql-injected, and is this fault of SQL or you? I agree it is harder to write C code safely, but this was a stupid bug, not actually a C incompetence. You could allocate a large buffer in Java, and you could use `System.arraycopy(array, 0, part, 0, size);` instead of OpenSSL: `memcpy(bp, pl, payload);` both lacks only a boundary check and language provided checks will not help you in Java. Java is given as an example language that provides boundary checks. It applies to others as well.
Sure, but that's bounded by the size of the buffer in Java. A bad boundary to the arraycopy in Java will throw an exception, not give you the contents of memory beside the buffer. These are not comparable failures.
The issue is more software architecture than programming languages. DJB writes plenty of C, and manages to create secure systems.
If you follow the principle of least privilege and separate things into processes, then you can write secure systems in C. Granted, there is friction with this approach on modern Unix, but it's more than worth it, and much more likely to get done than rewriting all of OpenSSL or OpenSSH or nginx or Python in Rust or whatever.
See "Some thoughts on security after 10 years of qmail 1.0":
People can and do write insecure code in any language. The most popular ones seem to be the most insecure -- C, PHP, and JavaScript -- and that doesn't seem to be coincidence (liberal languages have advantages as well as diadvantages).
Systems have to be designed so that tiny mistakes aren't catastrophic, and rewriting everything in a different programming language is probably the most costly way of achieving that goal. In other words, it's an economic impossibility.
That Pretty Much Wraps it Up for hammers
I love hammers. So damn much. I enjoy using heavy hammers.
I love having some nails and some wood and the flexibility to do whatever I want. I love that it imposes a discipline that prevents me from using that flexibility in stupid ways.
But between hitting your finger and bent nails I have to wonder if my beloved tool should be retired — at least for everything that could be a carpentry issue. (Which is potentially everything, I suppose.)
There are two things that make other tools better for these things: 1) in many tools these particular bugs are impossible, and 2) there are often better tools that can prevent those particular flaws from happening in a chunk of wood.
The finger hitting bug is a major hassle. What worries me is that the next time something else might happen — maybe someone hits their toe or breaks their hand. (Or worse.)
If we’re serious about protecting ourselves from pain and other malevolent entities, maybe we have to move away from hammers.
(I suggest this with great reluctance. And a realization that the cost of this would be huge.)
In short, this is click bait and stupid. C is a tool, it's up to the people using it to make sure the tool is used right. What we need is something closer to build codes for software. Right now it looks like some people think that building sky scrapers out of marshmallows is a wonderful idea and anyone pointing out that this is a bad idea is called a Luddite.
Some of this are not corner cases, and could be say are unnecessary to fight them decades after. You know, if B turn to C, why not turn to something better? Instead, the inertia (like happend with javascript) is push and push doing things the hard/dumb way because, well, all that people that have worked better from DECADES, they are wrong.
You either have an epistemology about defects and practices to prevent them to the best of your flawed ability or you don't. If you don't like 'C' then don't use 'C'.
You really, really need an epistemolgy. I mean absolutely no disrespect, but railing about choice of language ( although I love the links you provided; heads on pikes outside the city wall ) falls flat.
There are entire quadrants of computing for which 'C' is a grindingly horrible choice. OpenSSL for one is not one of them.
For path dependent and beyond-our-control reasons, 'C' is just about the only choice for that.
'C' programs should be invisible and close to the wire. Examples like these should give us courage in the face of pressure to let go of something too early, while that still small voice is nagging you "It's not really done."
Have good practices is good. Part of it, is not use a tool that could blow up your whole leg and drag a massive multi-million dollar pandemonium to the whole world (hyperbole Off).
Look, is clear that C, as a concept or tool, is a necessary thing. Close to the metal and all that, great. But consider this exactly like the same OpenSSL bugs: it have a problem, is patched, never again.
C don't have that. Have not improve in safety or remove any bad behavior in a decent way. Not deprecate things, not nothing.
Just " 'C' is just about the only choice for that.". That is bad!. So imagine if our only choice for hosting is Win3.11, and it continue towards Win90 and DON'T fix some very dangerous and stupid things.
This is what my rant is about.
For contrast (no just talking about pascal, ada and others -also old- saner, safer, can be close to the metal, languages), see what have happened with Obj-C.
It start horrible, but slowly is moving to something more ok. Now, I don't have problems because a bad release, the language remove that pain. The syntax is improving, slowly, but improving. The compilers are moving to something better.
I am quite sympathetic. We oldsters actually expected Modula-2, Obj-C or Ada to take off in the '80s. That didn't happen. The "reentry curve" for them was too steep and they burned up. 'C' didn't. It's the canonical "worse is better."
Turbo Pascal had good market share, but was eclipsed by 'C'. We really did have to squeeze every cycle back then; 'C' was better because you didn't have to do as much raw assembly. The cast of companies was largely established before even Windows; you were more or less encouraged to write TSRs. 40 miles uphill in the snow both ways to school! :)
I expect that the sheer mass of 'C' code out there creates quite a problem for wholesale replacement. So many computer things have been swept away; I doubt Linux is going anywhere. One suspects that the "cockroach" nature of 'C' is why it's still here...
Oberon is still out there; but perhaps the better thing is to simply increase the resources of the OpenSSL community.
Just because of bad programming practices you are diminishing the language. If I'm allowed to make an analogy to what you said, it is the same as cutting a tree because we found a rotten fruit. I agree with the @CSDude arg, every language has its weaknesses and a good developer should recognize and understand that.
35 comments
[ 3.5 ms ] story [ 82.8 ms ] threadIt's the attitude that was wrong, not the language. Stupid always finds a way. Back in the day, porting to different compilers and platforms was one way to find and quash bugs. Nowadays I guess you can just pitch a single OSS compiler and rely on it's implementation details and bugs. Drag your own chunks of libc around and presto, no porting headaches. That's such a stupid attitude.
What discipline? Am I missing something?
> maybe we have to move away from C.
Hopefully, Rust will facilitate this transfer.
I will believe Rust when I see it. We may, however, look at Lua. That might not sell, though. Lua is amazing but I'm not sure a culture is ready to bifurcate its code base like that.
Given the complexity of all this, it's amazing we don't get a Heartbleed sized thing per week. The color and shape of this reminds me of when markets take a tumble because of a cascading failure - some poor schmoe ends up with a margin call and everybody sweats a lot for a while.
At work, I do this: "Are you done?" "Yeah, but I don't trust it yet." They're really nice about this.
Getting Go to link to anything but C (and C++, but only if it uses C interfaces) is (depending upon the specifics of the other language) difficult to nearly impossible (and at some point certainly involves using C anyway).
For all of its issues, C is still incredibly important for being the only language you can fairly easily integrate with virtually any other language.
If you want safe operations in C, just write a few simple functions and use those.
http://www.tedunangst.com/flak/post/analysis-of-openssl-free...
Who can resist Theo: http://article.gmane.org/gmane.os.openbsd.misc/211963
Seriously, apart from C, what other language cause almost any of their users to think: I must do my own malloc, or String type, or XXXX.
This kind of weird is typical of C.
But today, writing large piles of new C code interacting with untrusted users and data is both painful and irresponsible. Pick a higher-level language, any higher-level language.
As far as I can tell, the main thing keeping C in its entrenched position these days isn't performance, or preference; it's C's status as the language of the native platform, that every other decently powerful language can talk to via FFI. If you write a new library in language $FOO, it'll mostly get used by other code in $FOO; if you write a new library in C, many different languages can use it.
However, adhering to the C ABI does not require writing code in C. And if enough new libraries start providing a C interface backed by a more powerful language, perhaps we can start establishing careful extensions to the C ABI to better fit higher-level languages (such as standard ways to pass buffers).
That's not to say there aren't new classes of systemic bugs in other languages, too. And FFI code, by necessity, lets you write C-like bugs. However, there's no excuse for buffer overflows and integer overflows anymore when any decent high-level language has buffer types and bignums.
Otherwise, I imagine system memory protection would have found this much sooner.
[1]: http://article.gmane.org/gmane.os.openbsd.misc/211963
If you follow the principle of least privilege and separate things into processes, then you can write secure systems in C. Granted, there is friction with this approach on modern Unix, but it's more than worth it, and much more likely to get done than rewriting all of OpenSSL or OpenSSH or nginx or Python in Rust or whatever.
See "Some thoughts on security after 10 years of qmail 1.0":
http://scholar.google.com/scholar?cluster=981457031544057079...
People can and do write insecure code in any language. The most popular ones seem to be the most insecure -- C, PHP, and JavaScript -- and that doesn't seem to be coincidence (liberal languages have advantages as well as diadvantages).
Systems have to be designed so that tiny mistakes aren't catastrophic, and rewriting everything in a different programming language is probably the most costly way of achieving that goal. In other words, it's an economic impossibility.
See also: http://www.cl.cam.ac.uk/research/security/capsicum/ . This works with existing code.
I love having some nails and some wood and the flexibility to do whatever I want. I love that it imposes a discipline that prevents me from using that flexibility in stupid ways.
But between hitting your finger and bent nails I have to wonder if my beloved tool should be retired — at least for everything that could be a carpentry issue. (Which is potentially everything, I suppose.)
There are two things that make other tools better for these things: 1) in many tools these particular bugs are impossible, and 2) there are often better tools that can prevent those particular flaws from happening in a chunk of wood.
The finger hitting bug is a major hassle. What worries me is that the next time something else might happen — maybe someone hits their toe or breaks their hand. (Or worse.)
If we’re serious about protecting ourselves from pain and other malevolent entities, maybe we have to move away from hammers.
(I suggest this with great reluctance. And a realization that the cost of this would be huge.)
In short, this is click bait and stupid. C is a tool, it's up to the people using it to make sure the tool is used right. What we need is something closer to build codes for software. Right now it looks like some people think that building sky scrapers out of marshmallows is a wonderful idea and anyone pointing out that this is a bad idea is called a Luddite.
http://queue.acm.org/detail.cfm?id=2010365
This is C thing, that have a lot of problems. In pascal, no problem.
And the worst?
IS STILL A PROBLEM. Decades after.
And this is only one thing.
The other bug: http://www.slate.com/articles/technology/bitwise/2014/02/app...
Is a C problem. No just the goto. YEARS AFTER, still here. IS the "brace" thing. Is not mandatory.
C have a lot of stupidity built-in (ie: Bad by default):
http://www.drpaulcarter.com/cs/common-c-errors.php http://www.andromeda.com/people/ddyer/topten.html
Some of this are not corner cases, and could be say are unnecessary to fight them decades after. You know, if B turn to C, why not turn to something better? Instead, the inertia (like happend with javascript) is push and push doing things the hard/dumb way because, well, all that people that have worked better from DECADES, they are wrong.
You really, really need an epistemolgy. I mean absolutely no disrespect, but railing about choice of language ( although I love the links you provided; heads on pikes outside the city wall ) falls flat.
There are entire quadrants of computing for which 'C' is a grindingly horrible choice. OpenSSL for one is not one of them.
For path dependent and beyond-our-control reasons, 'C' is just about the only choice for that.
'C' programs should be invisible and close to the wire. Examples like these should give us courage in the face of pressure to let go of something too early, while that still small voice is nagging you "It's not really done."
Look, is clear that C, as a concept or tool, is a necessary thing. Close to the metal and all that, great. But consider this exactly like the same OpenSSL bugs: it have a problem, is patched, never again.
C don't have that. Have not improve in safety or remove any bad behavior in a decent way. Not deprecate things, not nothing.
Just " 'C' is just about the only choice for that.". That is bad!. So imagine if our only choice for hosting is Win3.11, and it continue towards Win90 and DON'T fix some very dangerous and stupid things.
This is what my rant is about.
For contrast (no just talking about pascal, ada and others -also old- saner, safer, can be close to the metal, languages), see what have happened with Obj-C.
It start horrible, but slowly is moving to something more ok. Now, I don't have problems because a bad release, the language remove that pain. The syntax is improving, slowly, but improving. The compilers are moving to something better.
That is what I'm talking about.
Turbo Pascal had good market share, but was eclipsed by 'C'. We really did have to squeeze every cycle back then; 'C' was better because you didn't have to do as much raw assembly. The cast of companies was largely established before even Windows; you were more or less encouraged to write TSRs. 40 miles uphill in the snow both ways to school! :)
I expect that the sheer mass of 'C' code out there creates quite a problem for wholesale replacement. So many computer things have been swept away; I doubt Linux is going anywhere. One suspects that the "cockroach" nature of 'C' is why it's still here...
Oberon is still out there; but perhaps the better thing is to simply increase the resources of the OpenSSL community.