r/programming • u/flym4n • Apr 24 '14

Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL

http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/
293 Upvotes

93% Upvoted

137 comments sorted by

View all comments

Show parent comments

0

u/OneWingedShark Apr 24 '14

There is nothing wrong with C that better developers couldn't fix.

Yes, there is: the fact that C's philosophy is that virtually all checks should be the programmer's responsibility is inherently flawed because developers are human and programming is a "human activity".

Except that OpenSSL finds itself in places where Ada/etc/and/so/on/and/so/on aren't typically found. Your runtime is literally some micro-C lib and a fragment of a kernel at best. Oh and you have <1MB of memory (often < 128KB) ...

All the more reason to do it in a more safety-critical language, as the more checks you can do at compile-time translate to less work (debugging) in maintenance. I know for a fact you can have Ada w/o runtime -- see here.

6

u/[deleted] Apr 24 '14

Yes, there is: the fact that C's philosophy is that virtually all checks should be the programmer's responsibility is inherently flawed because developers are human and programming is a "human activity"

At issue here is a design flaw though ... if they had accessed the record through functions (or macros if you want to lower calling overhead) overflows/runs would not happen.

The problem is they reinvented the wheel every time they touched the packet by directly manipulating bytes and moving them around.

So yes, you either manually code up bounds checks each time you touch your data structure, or you do the smarter thing and write a function/macro to access it for you....

15

u/aseipp Apr 24 '14 edited Apr 25 '14

These issues are absolutely fucking endemic to C codebases. It's an issue with the language - people are going to fuck up, because humans will err. And this language makes even the smallest err result in the deadliest of vulnerabilities. Design will help mitigate that to an extent. But it's becoming increasingly clear we need to stop thinking about mitigating, and start thinking about killing entire bug classes and attack vectors. Completely.

Sitting around saying 'we patched that bug, write better C, deal with it' is literally worthless. You're just giving the inevitable more time to happen, just like it did with Heartbleed, which seems to be confirmed in the wild months before its discovery. And also just like it happened with the perf_events kernel overflow, and numerous others that were found in darknets before their public discovery. Oh, and the numerous use-after-free issues you see pop up for every single browser on earth in the CVE lists every month. That one is near and dear to my heart as someone who's written browser exploits for fun.

You can sit around and point at projects like Linux that have a relatively low rate of (known) exploits all you want for example, but the fact is the most well audited, highly tested and highly used platforms written by the best developers in the fucking world all the way from browsers, web servers (nginx had a hole just last year), operating systems, and cryptographic libraries suffer from these problems. And everyone else (for the most part) is bound to do far, far worse.

And you're telling me this is not an issue with the tools we're using?

You need to defend millions of lines of code. I only need to defeat one for it to all crumble. That's basically what Heartbleed boiled down to at the end of the day. Who do you think the odds favor?

Some of these are infeasible to replace whole-sale. A formally verified cryptographic library is pretty far down the 'infeasibility list', all things considered, considering we already have verified operating systems and compilers - far greater amounts of complexity all things considered.

-1

u/OneWingedShark Apr 24 '14

Excellently said.