Slashdot Mirror
How To Prevent the Next Heartbleed
dwheeler (321049) writes "Heartbleed was bad vulnerability in OpenSSL. My article How to Prevent the next Heartbleed explains why so many tools missed it... and what could be done to prevent the next one. Are there other ways to detect these vulnerabilities ahead-of-time? What did I miss?"
It could have been discovered with static analysis if anyone had the foresight to implement a specific check ahead of time (although it's unknown whether anyone could have thought of checking this specific case before Heartbleed was discovered):
http://blog.trailofbits.com/2014/04/27/using-static-analysis-and-clang-to-find-heartbleed/
about as effective as sunshine and puppies.
If someone is a moron, they can't help but be stupid.
Did anyone edit this? 'was bad vulnerability'?
Jeebus. Have some integrity.
If firefighters fight fire, and crimefighters fight crime, what do freedom fighters fight? - George Carlin
Or remote viewing? Or, more scientific, maybe put a bounty on big bugs that we'll pay time travelers from the future to tell us about?
If you want to find the next one and are in the US, force your broken government to disclose the ones they're already using on civilian targets (both in the US and abroad).
Every industry goes through this. At one point it was aviation, and the "hot shot pilot" was the Real Deal. But then they figured out that even the Hottest Shot pilots are human and sometimes forget something critical and people die, so now, pilots use checklists all the time for safety. No matter how awesome they might be, they can have a bad day, etc. And this is also why we have two pilots in commercial aviation, to cross check each other.
In programming something as critical as SSL it's long past time for "macho programming culture" to die. First off, it needs many eyes checking. Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more. No matter how macho the programmer thinks s/he is, s/he is only human and WILL make mistakes like this. We need better tools and technologies to move the industry forward.
Last, in other engineering professions there is licensing and engineers are held accountable for mistakes they make. Maybe we don't need that for some $2 phone app, but for critical infrastructure it is also past time, and programmers need to start being held accountable for the quality of their work.
It's things the "brogrammer" culture will complain BITTERLY about, their precious playground being held to professional standards. But it's the only way forward. It isn't the wild west any more. The world depends on technology and we need to improve the quality and the processes behind it.
Yes, I'm prepared to be modded down by those cowboy programmers who don't want to be accountable for the results of their poor techniques... But that is exactly the way of thinking that our industry needs to shed.
Don't use C and its variants like C++. C is an extremely unsafe, low-level language that is just one step above assembly language. This makes it great for low-level, performance sensitive programs like OSes, compilers, etc. but the low-levelness also increases bug count for general purpose applications.
Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc. These languages guard against buffer overflows and don't have the slowness and bloat associated with garbage collected languages like Java and .NET, but are much safer than C. The problem usually is, few people know these languages and they are not portable from one platform to another.
Let's remember the good old bug that plagued (and probably still does) many libraries that read graphic files such as TIFF. The classic scenario was that the programmer was reading the expected image size from the TIFF file header, allocated memory for this size, then read the reminder of the file into said buffer, until end of file. Instead of reading as many bytes as he has allocated. Now for a correct file this would work, however if the file is maliciously crafted to indicate one size in the header while having a much larger real size, you would do a classic buffer overrun. This is pretty much similar to what the SSL programmer did. And no tools were ever able to predict this type of errors, whether TIFF or SSL.
BTW the last famous one with TIFF files was pretty recent:
http://threatpost.com/microsoft-to-patch-tiff-zero-day-wait-til-next-year-for-xp-zero-day-fix/103117
Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc.
Yes, I agree. And as mentioned in the article, Rust is a good choice here too, or will be once it gets to version 1.0. I think the plan is for Rust to get version 1.0 this year.
issues
like lack of QA / testing
deadline that lead to cut corners.
having sales people over promise and more.
can be put on the PHB and without some kind professions there is licensing system they can say you can do it or we can find an H1b who can (at least on paper)
The problem has more to do with the "hey, this is free so lets just take it" attitude of the downstream consumers not willing to pay for anyone to look at the code or pay anyone to write it.
Why would you want the OpenSSL people to be held accountable for something they basically just wrote on their own time since nobody else bothered?
Striking out to solve a problem should NOT be punished (that culture of legal punishment for being useful is part of why knowledge industries are leaving North America).
This problem was caused by a simple missed parameter check, nothing more. Stop acting like the cultural problem is with the developers when it is with the leaches who consumer their work.
Yeah, we'll just rewrite the Internet in Pascal.
Libraries like OpenSSL are built in C in no small part because C can easily be linked into just about any other language out there. Nothing is going to change that.
And idiots can write bad code in any language. It might not be a buffer overflow, but they could still have screwed up in many other ways.
Or you just learn how to code properly. This particular vulnerability wasn't because there was a mistake, it was because they opted to bypass a function that was meant to keep people safe. It's a bit like bolting the fire escapes closed then wondering why everybody died after the fire.
It's astonishing to me that somebody would put code into a production environment that asked for a certain length of response without bothering to do any validation.
The only problem with doing this is you'd have to convince congress to actually punish companies that don't hold up to professional standards when applications get broken into for simple stuff. As is with our government, the Brooklyn bridge could cave into the bay killing 10,000+ people, and everyone would point to each other and it'd be the "system" that would be broken warranting new wonderful scummy laws that funnel billions out of your and my pockets into some ass hat politicians back pocket.
"Yes, I'm prepared to be modded down"
as you wish! wtf is with these insecure posts?
i'll burn karma (lots of karma given) posting this. hey, aww you guys!
i'll be modded down for this
posts don't need this useless ego driven filler.
What did I miss?
An article before the word "bad."
Slashdot: providing anti-social weirdos a soapbox, since 1997.
Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc. [...] The problem usually is, few people know these languages and they are not portable from one platform to another.
Agreed regarding both the solution and the problem with the solution.
It's probably reasonable to use [insert-super-secure-machine-verifiable-language-here] to develop libraries that are as security-critical as OpenSSL. However, it's unlikely that such libraries will be widely used if they aren't easily callable from the more popular languages (C/C++/ObjectiveC/etc).
Given that, I wonder how difficult it would be to write a library in (e.g.) Ada, but have the Ada compiler compile the code in such a way that the outputs is a C library file and C header files for the library's public API? That could give us a way to have our cake and eat it, too.
I don't care if it's 90,000 hectares. That lake was not my doing.
If that really worked, there would be no QA dept. for software. Unless you can formally prove your software is correct, you should assume there are bugs. And no one has the time, money or ability to formally prove hundreds of millions of lines of code.
And even more astonishing the head maintainer and merger did not review this change and ask the developer to fix it.
This was not a "hangman" game, this was a critical security package. If you can't be bothered to check parameters you shouldn't be working on security projects.
Eiffel compiles to C. Pascal can compile to C (I think k that Linux Pascal 'compiler' is just a translator to C and gcc)
No. I will agree, however, that any software that is to be used in critical operations by an organization should be verified by that organisation. If the organisation are responsible for maintaining and operating a system that integrates with others outside their control the method and criteria for validation should be public.
There is no need to certify programmers for this. It is the USE of an implementation that should be validated not the CREATION of that which is implemented.
Pilots verify that their tools and equipment function as advertised and show values within tolerance levels. They do not verify that the engineers who built the plane where certified.
I'm not sure you can auto-generate a C header file but you can create a library (.dll or .o) file from Ada source and call it from C. You have to hand generate the C header file.
Create DLL library in Ada
I want to punch everyone in the head who is using Heartbleed as an example of why NOT to use open source. It actually proves that open source development works well. Once the bug was found, the fix was released very quickly. I can guarantee you that if this was a closed source commercial product, the bug would exist a long time and the bug's existence would have been denied for a long time.
If anyone thinks this is an example of open source failure, they are idiots.
Your thin skin doesn't make me a troll
Yeah, we'll just rewrite the Internet in Pascal.
It can be done, regardless of naysayers like you. GNU rewrote Unix, the Internet can be rewritten too. Better get started.
It is a process problem, and your solution is to ban the use of screws, replacing:
1 "make a critical library written defensively and correctly, removing any cruft, and adhering to good processes"
with
2 "build an entire cross-platform compiler/runtime with no flaws that does that for you"
It was reverse psychology.
You forgot NIH. OpenSSL used its own allocator, the most positive thing I can say about that is "totally idiotic". AFAIK nobody is removing it ...
Furthermore, C is insufficient language for a security software (C++ when properly used barely acceptable, managed languages much better).
Yes, I think it's clear the next gen of CPUs really needs to have the machine language removed entirely. What a security hole!
You don't know what you're talking about. Do you have any idea how much money was invested in OpenSSL last year? $2k. That's not a typo, they received two hundred dollars. If the volunteers responsible for openSSL, a world-class product, were held accountable for bugs they would have no choice but to ditch the project. You want accountability, you pay for it. No, $2k won't cut it.
Get down your high horse, they're not your slaves. People work for free and you think you can tell them how they're supposed to do it. Either do better or shut up and let others work in peace. The OpenBSD guys have the right attitude. They saw OpenSSL sucked and got their hands dirty to fix it. What have you done to address the problem?
Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more.
This. It is high time that by default C compilers did buffer overrun check. Maybe deep inside some kernel routine we cannot afford the 0.5nanosecond it takes to check the buffer size, and we can always have a pragma that disables the checking for that piece of code. All other usages should be subject to buffer overrun check.
I have no idea why you're maintaining that "Republicans" create these bugs, and I'm, like, a socialist.
Do you think any brogrammers work on SSL? Do you think they're actively warding off peer review? In short: do you have evidence that the engineering culture behind openSSL caused the failure, rather than the obvious complete lack of revenue, funding and active contributors?
And if so, does this same culture simultanesously affect gnuTLS, LibreSSL, and Apple?
As with any population, _variation_ is the best defence against attack and disease. The best defence against the next heartbleed? Have more than one implementation.
How can you write general purpose libraries in c#? It will only run on windows. Java runs on more things. But what about their interpreters what are they written in?
> If that really worked, there would be no QA dept. for software.
No, that's just poor reasoning.
Quality must be built-in, not added-on. QA expectations and improvement scope are largely imposed on any QA department, therefore the level of 'quality' reached can never be an absolute bar.
Developers in general need to minimise the vector product of bug count/severity that could be exposed before it gets to QA. This allows the bar to be raised, and focus to be spent on where it should be rather than catching obvious mistakes, or dealing with unnecessary performance/cognitive/configuration complexity.
Keep in mind that this is an Open Source project, and the developers don't have access to all of the resources that corporations tout around.
> programmers need to start being held accountable for the quality of their work.
They are.
But I guess you mean that people who aren't paying for your work, and companies which aren't paying for the processes and professional services necessary for some level of quality, should hold programmers who don't have any kind of engineering or financial relationship with them accountable.
DOES NOT COMPUTE
The blog posting spent 80+% of it's time focusing on automated testing tools. They are fine and all, but cannot make up for a lack of basic good design practices. Ones which were present in the Heartbleed episode.
What would really have helped prevent Heartbleed?
1). Initialize all allocated memory. Routinely and automatically. And stop complaining that it "takes too much time." That's an excuse;
2). For Heartbleed particularly, I fail to understand why the echo word didn't self-define it's own length. Why did the programmer require this as a separate parameter? I'm a programmer and this is a glaringly obvious location for logic holes. The strongest defence against the possibility of conflicting parameters is not better parameter checking code. The strongest defence is to redesign the parameters to eliminate the possibility of the conflicts in the first place. Parameter error check code is good; error avoidance is better. This is programming 101 here!
I realize that I'm asssuming certain things here. However that's the best information I have for the moment and that's my take away.
Clearly there weren't any programmers of that quality bothering to work on OpenSSL for free.
That's why many people use alternatives to OpenSSL.
I have personally ported OpenSSL to at least 6 embedded systems, one of which was so proprietary they wrote their own C/C++ compiler. Good luck finding an Ada compiler for that.
his makes it great for low-level, performance sensitive programs like OSes, compilers,
Aaand... performance sensitive like, say... crypto? There isn't much code more performance sensitive than crypto libraries, which is one of OpenSSL's main uses. In fact, there are a whole bunch of native assembler implementations for x86, MIPS, ARM, PPC, etc to achieve that low level performance. Clearly you have never actually looked at the OpenSSL code base...
In programming something as critical as SSL it's long past time for "macho programming culture" to die.
Yeah, but it's kind of going the other way, with more and more companies going to continuous deployment. Facebook is just pit of bugs.
programmers need to start being held accountable for the quality of their work.
OK, I'm with you that quality needs to improve, but if I have a choice between working where I get punished for my bugs and where I don't; I'm working for a place where I don't get punished for my bugs. I test my code carefully but sometimes they slip through anyway.
"First they came for the slanderers and i said nothing."
Don't you mean if it not a hangman app don't get free code from the Internet?
That is not the answer or there would be no FOSS.
It is the issue of who works on the boring stuff.
The US Army will swear that I was once, many moons ago, officially certified in Ada, whether that means anything or not. I never liked it much, even though I did turn in successful code a few times, and I really have a problem with Ada for open source applications - Yes, in theory, Ada has some very strong security functions by design, but it's definitely not going to result in the 'many eyes make all bugs shallow' effect. I actually read your post as deliberately tongue in cheek at first, what with phrases such as 'extremely unsafe'.
But as I think more about it, one of the problems revealed by Heartbleed is open sourcing the target code didn't result in a lot of properly trained eyes passing over that code. I never thought I'd encourage anyone to learn Ada after I got out of the service (just as I never thought I'd encourage anyone to start a cult worshipping many-tentacled, eldritch, blasphemous horrors from beyond space-time as we delusionally try to limit our conceptions of it to preserve our fundamental human sanity, and for much the same reasons), but I have to admit, you may have a damned good argument for Ada there.I don't know if the extensive compile time checking of Ada 2012 could have automatically caught the bug that made Heartbleed possible - the last version of Ada I've really used is 95, but I'd be really interested to hear from someone who's current if they think Ada is just about totally bulletproof against this sort of bug, because even the older versions I recall had some features that would have made it hard to make this sort of mistake.
Who is John Cabal?
GNU rewrote Unix
In C. Not Pascal.
How do you propose that the compiler performs this check when it has no idea as to the size of the buffer?
The problem is with the language, not with any given implementation.
actually a couple more *bad* vulnerabilities were found in openssl, but the author of this paper didn't find them. arm waving ivory tower bullshit, that's how we got into this pickle in the first place
all well and good.... and i agree to some extent, but you know what it was the gung ho ones that pioneered it and the wusses looking for a reliable paycheck that regulated the living hell out of it..... at which point innovation completely dies.
- Simplify the code, and the protocol. LibreSSL's simplifying OpenSSL, but also, we didn't need heartbeats built into a crypto protocol in the first place.
- Lots of code needs more review. Other open-source frameworks and servers are in OpenSSL's same nasty spot of being widely used but not corporate-supported and well-vetted.
- Non-security code can cause critical security bugs, too; remember the zlib bug. We can give widely-used non-security libraries more fuzzing/review, and/or figure out ways to better contain software faults with finer-than-process-level precision.
- C(++) is certainly a playground full of buzzsaws, but we're also addicted to it; maybe augment w/things like bounds-checked array access where we can afford it and standardized formatting and linting to catch some bugs (if not this one).
- If we only consider bugs like Heartbleed, we're stuck fighting the last war. We should think about those CAs and providers we trust, or the way we rely on passwords, or how to change servers' default configs and libraries to make it more natural to deploy secure services than it is today.
In programming something as critical as SSL it's long past time for "macho programming culture" to die. First off, it needs many eyes checking. Second, there needs to be an emphasis on using languages that are not susceptible to buffer overrunning. This isn't 1975 any more. No matter how macho the programmer thinks s/he is, s/he is only human and WILL make mistakes like this. We need better tools and technologies to move the industry forward.
Your post should be modded down, it is a repetitive theme...But that's not your fault, how many articles is /. going to post that are repetitive? Your comment was already posted once in a /. story and yet they keep posting echo articles from programmers/critics who somehow think their geniuses for pointing out the obvious problems with open source projects.
Wheres Linus Torvalds in all this? I was hoping to read or hear his thoughts over this, would be even better if he did video self-interviews .. The guy is brilliant and priceless!
If you are worried about security don't use software written by people who can't be bothered to check parameters.
One of the many eye-openers that reading Douglas Hofstadter's "Gödel, Escher, Bach" book has provided me, all those years ago, is that, no matter how much we humans may try, we may *never* be sure to have removed all errors or imperfections from anything that's even marginally worth of our interest. In a nutshell, if you can prove that something has reached perfection, at the same you prove that it is not interesting anymore.
We cannot write complex bug-free software. PERIOD. OpenSSL is not windows. Headlines about OpenSSL bugs are not such a common occurrence. One bug happened at the wrong time, wrong place. This could have happened even if the world had opted for a proprietary library for this critical role. The only difference is that there would have been somebody to sue. Big consolation.
New theories come out of IT faculties around the world at regular intervals, that promise, if strictly followed, the holy grail of bug-free software. All of them eventually prove non-effective.
The only concrete effect of all these tactics is that the job of the programmer becomes more tedious, less interesting. One thing I can tell you from direct experience is that, the lowest the level of interest of the programmer, the higher the possibility will be that bugs may slip into his or her code.
So, the question is wrong. We cannot prevent the next Heartbleed. What the world needs to (re)learn instead is how to cope with unexpected events without reaching for your phone and calling your lawyer.
Many thanks go to all free software contributors, including OpenSSL ones, for what they do!
Unless you are trying to switch to pascal-style strings instead of null-terminated ones you have limited ways to automatically check buffer overruns, just as you have limited ways to do garbage collecting or, for that matter, almost anything automagical with pointers. The compiler alone cannot enforce that policy, one could try to enforce it in the standard library or a framework. The difference between low and middle level languages and high level languages is the magic that happens behind the language. C has almost no magic, it just gives you the building blocks to do whatever you please.
uhm...
Going forward, all CPUs shall be required to execute Java bytecode natively.
Hi dwheeler,
This is a great article. It covers many common software development and testing techniques. But also some "on live system" techniques. It was a pleasure to read, I'll recommend it to various places.
I really have a problem with Ada for open source applications - Yes, in theory, Ada has some very strong security functions by design, but it's definitely not going to result in the 'many eyes make all bugs shallow' effect.
No one ever reads open source code. It's just some free stuff that naive neckbeards wrote for you, that you can compile and use for free, because it's free!! If no one ever reads the code, who cares what language it's written in?
DOES NOT COMPUTE
Obviously shoddy work, not enough "eyes" looking at it from a QA perspective.
Nothing in the C language precludes checking array bounds. There are plenty of implementations that used tagged pointers, or instrument code to lookup the bounds of an automatic array or malloc pointer.
But few people use them because they're slower.
dollars and able bodies... simple enough, the project before this incident had neither sufficient budget nor sufficient numbers of people working on it.. considering the number of huge, profitable companies, institutions and governments that rely upon the project for day-to-day operations, simply NO EXCUSE.
If we look how was treated the disclosure of DES vulnerability, and if we compare with the status regarding RSA, we can expect that the next hearthbleed vulnerability will not be in the implémentations but in the foundations.
My experience is that people who trust in their language to keep their code bug free inevitably have more bugs in their code. It's amazing how many memory leaks I've found in Java, by programmers who swore such things were impossible. Another entertaining situation is people who manage to get around deadlock detection by creating live-locks.
I think it's clear to everyone who's actually looked at the situation that the problem here wasn't the language, it was the people who were using the language. They would have written bad code in any language.
"First they came for the slanderers and i said nothing."
But as I think more about it, one of the problems revealed by Heartbleed is open sourcing the target code didn't result in a lot of properly trained eyes passing over that code.
My experience is that reading code isn't a very good way to catch bugs, mainly because reviewers tend not to read it as carefully as the person who wrote it. If you want to find bugs, it's more effective to do white/black box testing of some sort.
"First they came for the slanderers and i said nothing."
Yep. It's a thing you include to guarantee your post to be modded up. ;)
Don't use C and its variants like C++. C is an extremely unsafe, low-level language that is just one step above assembly language.
That's like saying we shouldn't use nuts and bolts to build things and instead only use Legos, since they're "safer".
The problem wasn't the language, it was the fact that there were less than a half dozen people actually working on the software, and only one of them could even remotely be classified as a full-time worker. It's incredibly common to miss your own mistakes, especially when the code works properly when tested and widely used.
What is needed are more eyes actually reviewing the project and performing QA and testing on it, instead of just assuming that it was working properly. Part of the problem is that Crypto is Hard, and many people have a tendency to assume that the bits of code which seem wrong or out of place are actually working properly, and that it's their own understanding which is in error.
Then we have to go one step further and store the size of the buffer.
In general, a "hardened C" programming language would be an excellent idea in my opinion.
We have fast computers. Why not sacrifice some of it to security? I mean, we are still probably not talking about 50-time slowdowns, like when you run a program under Valgrind.
Going forward, all CPUs shall be required to execute Java bytecode natively.
Well there was the PicoJava from Sun.
Or the MAJC from Sun
Both of which did exactly that.
Alas none are around any more...
People should not be afraid of their governments - Governments should be afraid of their people.
This was not a "hangman" game, this was a critical security package. If you can't be bothered to check parameters you shouldn't be working on security projects.
No, it was a free piece of software with no guarantees which was not tested nor rated as acceptable for high-risk use. Others chose to use that software as part of various critical security applications, but completely failed to validate that the software they used was in reality up to the task.
This wasn't a company paying people to write secure code. It was a few volunteers, only one of which was even what you could consider 'full-time'. Meanwhile, thousands of high-profit companies couldn't be bothered to help them out with the project, so if you've got anyone to bitch at, go bitch at every for-profit company who used it and utterly failed to give anything back.
I saw that a week ago, so I donated $50 USD to the OpenSSL Software Foundation. I figured I would either whine about the problem, or do something. I chose the latter.
We're moving in that direction. Intel is adding bounds checking instructions to the Skylake ISA called MPX. The compiler will keep some shadow memory populated with the bounds of pointers and arrays, and insert MPX instructions to check loads and stores.
Clang and GCC now both have AddressSanitizer, which does the same thing in pure software.
So there's nothing inherently unsafe about C. Its just that most implementations haven't bothered to deal with the problem.
Also, the Heartbleed over-read could have happened in Java. Plenty of high-performance Java projects use buffer pools that look identical to what OpenSSL was doing. They do it to cut down on garbage churn.
I actually agree with both of you. The Open SSL guys gave out their work for free for anybody to use. Anybody should be free to do that without repercussions. Code is a kind of literature and thus should be protected by free speech laws.
However, if you pay peanuts (or nothing at all) then likewise you shouldn't expect anything other than monkeys. The real fault here is big business using unverified (in the sense of correctness!) source for security critical components of their system.
If regulation is needed anywhere, it is there. People who develop safety and security critical stuff should be certified and businesses with a turn over $x million dollars should be required to use software developed only by the approved organisations.
There is nothing in this definition that prevents an open source implementation. In fact, there's an argument to say that any such verified implementation must be open source precisely so it can be inspected. But it is quite a lot of work and people need to be paid to do that work. You can't expect to get this level of quality assurance for free.
We have fast computers. Why not sacrifice some of it to security? I mean, we are still probably not talking about 50-time slowdowns, like when you run a program under Valgrind.
The irony is that you're already sacrificing it to security in C if you're doing it right; every bounds check that you have to add manually slows things down _at least as much_ as the bounds checking done in higher-level languages.
C/C++ aren't magical speed-demons, they get their speed through a trade-off and a horrible one at that. The sooner people realize this the better.
it's super effective.
Spent All My Mod Points
I am surprised that D language was not mentioned.
http://dlang.org/
Don't use software at all, then.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
I have personally ported OpenSSL to at least 6 embedded systems, one of which was so proprietary they wrote their own C/C++ compiler. Good luck finding an Ada compiler for that.
his makes it great for low-level, performance sensitive programs like OSes, compilers,
Aaand... performance sensitive like, say... crypto? There isn't much code more performance sensitive than crypto libraries, which is one of OpenSSL's main uses. In fact, there are a whole bunch of native assembler implementations for x86, MIPS, ARM, PPC, etc to achieve that low level performance. Clearly you have never actually looked at the OpenSSL code base...
Performance sensitive? really? most crypto is NOT performance sensitive at all and you could easily sacrifice some performance for more secure/reviewed code. I would imagine there are very few mostly fringe cases where the performance is more critical in which cases they should be uses modified versions not having hacks put into the main code stream.
If you want a language that checks for buffer overruns you use a language that checks for buffer overruns. Or when you want to fly somewhere you strap wings on your car instead of taking a plane?
If your web server is pushing out lots of https traffic then yes it is performance sensitive.
The higher-level languages are often either interpreted or run as cross-platform bytecode. Those make up for the main performance hit, not bounds-checking.
As in; don't add exploit counter-counter-measures to a fucking crypto library. Reading the comments below no one even mentions that they used their own memory allocator, while tellin us how humans can fail and we should all use language X.
Buffer overruns can be statically prevented at compile time without any runtime penalty.
All that is required is that the type system of the target programming language enforces a special type for array indexes and that any integer can be statically promoted to such an array index type by a runtime check that happens outside of an array access loop.
Array indexes are essentially pointer types that happen to be applicable to a specific memory range we call an array. Memory itself is just an array, but for that specific array C gives you special types to access it, namely pointers.
Actually OpenSSL is FIPS-certified, so there is some reason to expect a level of quality.
"Brogramming" is the latest feminist buzzword - and as with the rest of their claims, it's bullshit.
Nothing about the OpenSSL fault is to do with macho programming (notice the conglomeration of "male" and "irresponsible" in all this).
It's about a software fault... the type of fault that happens when a critical part of your infrastructure has been under-resourced compared to its importance.
Interestingly... one of the faults underpinning heartbleed was the attempt make OpenSSL as inclusive and cross-platform as possible. Too much junk hid the fault.
That's in stark contrast to the idea that it was some kind of exclusive man-club... but hey... social justice warrios will turn anything into a conspiracy.
Profiling w/ 100% code coverage would have caught this bug. Input fuzzing in the unit tests under memtest could have located this bug even faster. When I'm looking to find a bug to crack these are what security conscious folks like myself or any cracker will use against a code-base to quickly find potential exploit vectors. Thus these tests are the bare minimum framework for any code that has anything to do with credentials or security. Even a PHP login form will have better input sanitation than this. Even just basic Input fuzzing would have randomly asked for a gigabyte or so of data back from the pings making the bug very fucking unignorable.
Here's how I prevent "heartbleed" like bugs: Part of my build process's test harness script generates basic stubs for fuzzing and range tests from the function signatures in .H files if any are missing; So, when I very rarely forget to range check a function parameter the basic unit test is already generated for me and shows up in the build system issue tracker as a failed test; Not only that, it eats my lunch every RC / testing build by chewing through billions of int values until I manually drop in a function call for a stochastic input range check approach instead and maybe added a few tests to hit both sides of any edge cases. FINE If we're having a "Monolith meets Monkeys " moment anyway, might as well throw this one in too: Get the sources for Doxygen (which lets you define custom properties @min_int 42 @max_float 3.142, etc. in your doc comments), and now you just add a bit of your own code to generate your unit tests and input fuzzing code from the function signatures in the source code (Java, C/C++, etc). You generate one file per test, and make nested folders (one per class/source file, one per function) to keep shit organized. One test per file? Isn't that very inefficient? 0. Fuck you, haven't optimizations ruined enough lives already? 1. How else will make produce your missing unit tests, and have your SCM point out each one you forgot to update as an untracked file? Basic code management may seem alien to some of you humans, but it's really not saucer science folks.
I repeat: Use a fucking code coverage tool, for fuck's sake. Folks do this for bullshit enterprise crap, and this is a security product? Regardless of the implementation cock-up, there were multiple untested branches of code for many releases; Specifically there was one branch with and without the bullshit optimization of a custom memory management strategy. Despite the fact that this optimization was not beneficial on any but a very small subset of systems, it was turned on by default. The other branch of code without the memory management hadn't been tested in forever, so code coverage was clearly not a requirement for a release. This also means the optimization wasn't even being profiled against malloc() and free() to see if it was even faster. Memory management is a KNOWN major exploit attack surface... If the code isn't being tested, you don't fucking leave it in the code base, and you NEVER take code out of the code base leaving only a kludgey optimization hack, so this forces you to test the damn code. Just any degree of secure development best practices themselves would have been enough to catch heartbleed.
Want to help steer clear of the next heartbleed? Don't use 3rd party libs that can't test cleanly with memcheck: Yes, I know they can have obcaches and etc. custom memory management which makes memcheck complain even if they're used correctly, but GC is a prime KNOWN place for state leakages and subtle bugs to breed. Even my embedded scripting language for C has a GC that cleans itself up properly. Yes the OS reclaims allocated memory at program termination whether you free() or not, but it's just such a fucking minimal thing (a basic check) to just walk your data structures and release resources or que up a function to free() things atexit() so that memcheck is
I have no idea why you're maintaining that "Republicans" create these bugs, and I'm, like, a socialist.
I think he's claiming non-Republicans can't code...
The LLVM static analyzer finds this bug.
So would warning about dead code, since the code past the point of the second goto is, by definition, dead code. Most people prefer automatic dead code elimination, mostly because they don't want to have to fix their code, if they could be working on new code instead.
When I turned on the "Brucification" warnings in the Mac OS X compiles, everyone bitched they couldn't see the new warnings their changes introduced with the previous (small) set of warnings that they personally cared about were all the compiler would complain about. We found tons of code in the VM system and elsewhere which was dead (most of them intended as code path optimizations, which is funny because performance testing would have found they didn't have any impact) because of "comparison is always true..." or "comparison is always false..." rendering them silently dead.
Unfortunately, -Wunreachable-code was removed from gcc in 2010 (brilliant move, that, in retrospect, wasn't it?).
Excerpt...
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
Heartbleed was not really a buffer overrun problem.
So cute!
The problem usually is, few people know these languages and they are not portable from one platform to another.
And in this particular case it wouldn't have helped anyway.
Actually I have a hard time finding real security cases that can have been avoided by changing language. It is all just theory.
Rigorous coding should be held to approximately the same standard as engineering and math. Code should be both proven correct and tested for valid and invalid inputs. It has not happened yet because in many cases code is seen as less critical (patching is cheap, people usually don't die from software bugs etc). As soon as bugs start costing serious money, the culture will change.
Anyway, I'm not a pro coder but I do write code for academic purposes, so I am not subjected to the same constraints. Robust code is easier with some languages and harder with others, but should be doable in any setting. In the end, some form of static and dynamic checking should provide reasonable security for almost any environment.
yes. exactly, exactly! a piece of software no matter how open or closed, is a concept, an idea so on and so forth. but when you program a finite automaton ( any computer) to work by the rules described by that software, then you, the guy who installs that set of rules ( the software ) bare a lot if not all the responsibillity. in my oinion we take computers and software for granted and we shouldn't.
final thought : the people who wrote the code are not responsible for proposing a piece of software, but everybody who put it into production bares responsibility.
So you are saying Open Source is inherently flawed because "the developers don't have access to all of the resources that corporations tout around"?
This problem was caused by a simple missed parameter check, nothing more. Stop acting like the cultural problem is with the developers when it is with the leaches who consumer their work.
I do not believe you. If this were an isolated case, then you'd be right. But no, this kind of "oops, well now it is fixed" things happens all the time, over and over again. The culture of the programming never improves due to the error - no matter how simple, no matter that it should have been noticed earlier, no matter what.
I am willing to bet that after next hole the excuses will be same "it was simple, now it is fixed, should up" and "why don't you make better, shut up" or just "you don't understand, shut up". And still the cowboy-coding continues.
This was caused partially by unchecked parameter (this should have never happened, there is no excuse for it), partially because the idiots used their own allocator which created the covert channel and prohibited the use of malloc-debug libraries. Libraries which would have found the error - again this should not have happened.
But then, maybe I just should shut up ...
yes developers are humans so they make mistakes. Some of them are technical some organizational I.e. not having proper or at least sufficient process in place. The faults are just part of what we do, they are unavoidable and we just need take care of them. Calling users of openssl leaches proves does only one thing - shows how stupid you are.
Speaking of weird remnants of the past, I've seen claims about the kernel needing to be uber-efficient before, but does that really make any sense? How much time does the average machine spend executing kernel code, besides the idle loop? If kernel was 10 times as slow, would it still be a significant amount?
No we can't, because every programmer is better than average, thus they clearly can disable the checks safely, and as the Heartbleed fiasco showed, they will do stupid shit to gain a (real or imagined) speed advantage.
No, if checks are to do any good, they need to be mandatory. But we already have a language that does that, and Java is bitterly hated precisely because it keeps programmers from living dangerously. Not that that stops them from inventing new and innovative ways of screwing up, as evidenced by the software that requires a particular JVM version...
Also, I'm not at all certain that a truly secure programming language wouldn't face opposition or outright sabotage from various intelligence agencies. Whether the excuse is spying on your own consumers or the foreign dogs, everyone and their dog wants access to every system they come across.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
= what arrays use for indexing. Arrays need contiguous memory whereas linked lists don't (and they operate on pointers).
GNU rewrote Unix
No. GNU took existing projects that existed under permissive licenses and called them a UNIX replacement after GNU relicensed them under the GNU license. Other than 3.1 MB of "Hello World" source, GNU has done fuck all. They don't even have a kernel, yet.
No there isn't
How would it not have helped? In a memory safe language the buffer overhead which caused the bug could not have happened.
A quote from the "Insane Coding" blog, which in turn quotes from the book "cryptography engineering":
The issues with higher level languages being used in cryptography are:
- Ensuring data is wiped clean, without the compiler optimizations or virtual machine ignoring what they deem to be pointless operations.
- The inability to use some high-level languages because they lack a way to tie in forceful cleanup of primitive data types, and their error handling mechanisms may end up leaving no way to wipe data, or data is duplicated without permission.
- Almost every single thing which may be the right way of doing things elsewhere is completely wrong where cryptography is concerned.
Why would you want the OpenSSL people to be held accountable for something they basically just wrote on their own time since nobody else bothered?
I think this is part of the problem: much of the code was written as a hobby.
Which is fine, and doesn't necessarily mean it's bad code. But similar to how Linux started as a hobby, people are now paid full-time to work on the code.
The same thing should (and is) happening with OpenSSL: put a bunch of money (either the OpenSSL Foundation, or the Linux Foundation) and hire smart, competent folks to work forty hours a week on cleaning things up. It doesn't have to even be a lot of folks (6-12?), but it needs to be their job for forty hours a week to look at it.
We do it with BIND, ISC DHCP, Linux, etc., and many other important projects. The time has long past when proper funding should be applied to full-time developers to this.
>But then, maybe I just should shut up ...
Yes. You should.
Nope. You're a moron. This works fine for compile-time constants, but not dynamic/runtime initialized arrays. At least, not without overhead. But nice try. Maybe if type more words you can look smart in front of whoever.
The fundamental problem is the current developer culture that sees software development as "coding".
It wasn't always this way. There was a time when "design" was considered crucial, and "coding" was seen as the elaboration of a design into something that could be compiled and executed. People assumed that eventually we would have a design level language that could be compiled - that "coding" would be at a design level.
Unfortunately, design level language have not caught on, even though there have been many developed in universities, so we are still stuck at a low level code level - way below the design level, and given the waning emphasis on design today, it is no wonder that we have so many vulnerabilities in software.
And this has nothing to do with agile development: agile development can work at a design level; but the culture emphasizes "code", and that is the problem.
Compounding the problem is the fact that most developers have little interest in secure design; and if bypasses design and goes straight to coding, then there is no secure designing, there is only "secure coding", which is a non sequitur.
I have reviewed code for dozens if apps and reported dozens of bugs for them. The problem is that not every project fixes them. Not even if you provide a patch and the issue is obvious programming error.
Agreed, but not in C. You need to change C (and modify the code to use the functionality) or change programming language. The article does discuss switching languages.
- David A. Wheeler (see my Secure Programming HOWTO)
Shit happens to the best programmers. The only thing to prevent such things is to check the code. Therefore, you need another person trying to test the code and you need a specification for the code so you can really check the code against another artifact. But obviously nobody bothered. That's why in housing the architect plans the building and at least two structural designer check the design (at least in Germany that is).
Speaking of weird remnants of the past, I've seen claims about the kernel needing to be uber-efficient before, but does that really make any sense? How much time does the average machine spend executing kernel code, besides the idle loop? If kernel was 10 times as slow, would it still be a significant amount?
Assuming that kernel time is 1% of your total CPU time. Your 10x number, now becomes 10% of CPU time. Which could possibly translate into 5-15% less battery life.
Not every machine running code is a desktop hooked to a power line. There are a lot of battery-powered devices out there which also need to run code, where you do need to think about clock cycles. Or systems which have very limited CPU power.
That being said, in 98% of the time, a developer's focus should be on using appropriate algorithms / design patterns which are fast and efficient in 90-98% of cases, rather then playing around with ASM or low level C trying to squeeze out that last 2% of performance.
OpenSSL used its own allocator, the most positive thing I can say about that is "totally idiotic".
That's deeply unfair. The most positive thing I can say about it is that it was 100% necessary a long time in the past when OpenSSL ran on weird and not so wonderful systems.
AFAIK nobody is removing it ...
Except in LibreSSL, you mean?
Furthermore, C is insufficient language for a security software (C++ when properly used barely acceptable, managed languages much better).
Depends on the amonut of auditing. C has huge problems, but OpenBSD shows it can be safe.
SJW n. One who posts facts.
I wasn't really thinking about fully managed languages here, just a step up. This bug would never have happened if it had been written in Ada, Pascal, Fortran, etc, and the program as a whole would most likely not have been slower.
most crypto is NOT performance sensitive at all
Ever run a web server with HTTPS? At work, not all systems have Xeons with AES yet, so we don't enable AES-NI on images, which means AES is all done in software. This became such an issue, that the majority of the web server's CPU was being consumed by AES. We eventually had to purchase a $250,000 firewall+reverse proxy. Since you can't just have 1 of something for redundancy reasons, we had to purchase two of them, so $500k, and because we have an offsite datacenter in case the main one goes down, that's another $250k. All in all, $750k because we can't enable AES-NI. Freaking awesome!
I guess these firewalls do a lot more than just offload HTTPS, but it's the biggest feature the web admins care about.
Says the people defending c programmers...heartbleed...who is real idiot...
signed,
garbage collecter
DOES NOT COMPUTE
You must be one of those high-level language compilers to have caught that error.
I do not donate to programs written in c...
"businesses with a turn over $x million dollars should be required to use software developed only by the approved organisations."
That would just lead to regulatory capture. The approved organisations would use their connections and influence to make it very hard for any other organisations to become approved - and once this small cabal have thus become the only option, they can charge as much as the like.
But they do give the programmer control of where the checking happens.
If you have a function CalculatePasswordHash(char *pass, int len) that in turns calls functions sha1, memcpy, rotatebit and xor fifty times each passing that len parameter, then you can check it is = the space allocated for *pass just once, rather than doing it for every function and thus needing two hundred and one checks minimum.
A lot of kernel stuff is very time-sensitive. Got to get the next block of sound to the audio device before the ring buffer catches up, got to get the display memory updated before the screen refresh kicks in, got to calculate the next LBA address read before the disc spins around to whereever it may lie.
Yes. Also, the problem with Rap is that it is in English. If they just wrote their masogenistic statement in a different language all would be well!
Seriously, please stop with the ridiculous claim that the language is the problem. The problem is that nobody is perfect, no process is perfect, and mistakes will always happen. They will happen far more often when the system is implemented by people who understand so little about software development that they think the language is the problem.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I agree that in general corporations are not going to contribute anything back to open source unless it somehow helps them. I also believe that something as fundamental as security libraries should undergo much more review care and planning than they likely do, be they closed or open source. I do not agree that security libraries should be written in some specific language, though if you can get the same performance in a more secure language that is also widely used, then it makes sense to make the transition. That being said, if you don't make the performance requirement you need, people will not use a particular library.
The problem ultimately comes down to money. With sufficient care a high paid team of experts could write the requirements and checks needed to make it reasonably secure, while another highly paid and experienced team could code it. Ideally you would want this kind of thing repeated in multiple countries with multiple levels of review for the really important stuff. A piece of code designed that way is likely to have the needed review. It also may end up being slow, due to the vast amount of concensus required, but then it is the standard compromise.
Faster, cheaper, better. Pick any two, except in something this important your likely to get slower, more expensive, better, if you truly want the best. Another sad fact is you can't trust an agency like the NSA to oversee such work, since they have a clear conflict of interest. The best idea that comes to mind would be to entrust such work to say three top universities in three different countries, perhaps with undergrads being given full ride scholarships if they find an important enough bug... Of course, I don't think that level of commitment is ever going to happen, but if you truly want bulletproof security, I think that is probably about the level of comittment needed. (It would also be best, if at least one of the universities was from a country that did not actively get along with the other two countries.)
Adacore has a perfectly good implementation of a high-security Ada compiler, which produces executables for multiple platforms. There's nothing difficult about finding such tools. What's difficult is finding programmers and developers who are willing to take the time to actually develop their code to take advantage of the strict typing which is one of Ada's strengths.
John Barnes, author of one of the most-used Ada texts, outlined the meanings of "safe" and "secure" software in a very straightforward manner:
If software is "safe", it cannot harm the world
If software is "secure", the world cannot harm it.
From what I've seen, C and its derivatives do not have the intrinsic mechanisms to make software developed with that language either "safe" or "secure". It's too easy to break both safety and security using C and its derivatives, because a programmer can cast between types, auto-promote from one type to another, and similar logical faux pas, and the compiler will very happily allow such to take place, which means most bugs are able to hide until run time. Not so with Ada; because of strict type checking, casting must be explicit, and an attempt to auto-promote will be met with a CONSTRAINT_ERROR at compile time.
As the poster on my wall says, "[i]f builders built buildings the way programmers write programs, the first woodpecker to come along would destroy civilization."
All the world's an analog stage, and digital circuits play only bit parts.
I can see the cattle call now from a lot of software places: "But forcing all these bargain basement H-1Bs or our offshore, oursourced dev shop to adhere to these standards costs us money, and security has no ROI! Lets just keep coding cheaply, and pay people off if something does get discovered."
Is there any reason we can't get bounds checking in C?
I think I read something about an interpreted version of C some time ago that did this.
move on ...
Wouldn't the best course of action be to zero important memory after it's use just like on disk. After something like a password is loaded in memory it should always be followed by memset with zeros in C/C++. That way if an unchecked read is followed all that would be read is null.
Why was a comment about the horrific attack on science and technology by Republicans moderated as funny? It's horrible. I guess the same idiot that did that thinks Holocaust jokes are funny. You Republicans are all alike.
Depends on the amonut of auditing. C has huge problems, but OpenBSD shows it can be safe.
How so? OpenBSD says they audit their operating system (which includes code that they did not write). OpenBSD was affected by Heartbleed, which means OpenBSD's audit did not catch this bug, and they were affected just like everybody else.
Also, most of the bugs on their advisory page are for typical C memory problems, such as use after free and buffer overruns.
So there's nothing inherently unsafe about C. Its just that most implementations haven't bothered to deal with the problem.
C is inherently unsafe because the default mode is unsafe. History has shown that expecting implementations to add security after the fact does not lead to secure programs. C's builtin strings, which are null-terminated and prone to security flaws, are a perfect example of C's insecure defaults.
Also, the Heartbleed over-read could have happened in Java. Plenty of high-performance Java projects use buffer pools that look identical to what OpenSSL was doing. They do it to cut down on garbage churn.
Could have, yes, but you have to go out of your way in Java to fall to this kind of bug. There's a huge difference.
Of course, we should find ways to improve quality control in open source software. But the next Heartblee is going to happen. It's like asking, "How can we prevent crime from happening?" Sure, you can and should take measures to prevent it, but there will always be unexpected loopholes in software, that allow unwanted access.
Can you express what you didn't like and why? Perhaps it's a bit verbose and overly strict. But the strictness means you find many bugs during compilation and basic testing. Of course, compiler and runtime errors frustrate many programmers, which is why many prefer C -- fewer warnings and errors. Let the customers deal with the errors.
But this class of bugs (buffer related) is extremely common in many software apps, (specifically C apps because C uses pointers for buffer management instead of creating a dedicated type). Why should you need many eyes to perform such a tedious task when the compiler/runtime can do it more efficiently?
But that's the point, we can and should take measures to prevent it. Even if we never eliminate all vulnerabilities, we can prevent many more vulnerabilities than we currently do.
- David A. Wheeler (see my Secure Programming HOWTO)
The bug is foremost a flaw in the Interface call.
The spec can be described as "Here is a bit of data, send it back to me so I know you are alive".
But there are two separate sources for the length of the data:
- The write length
- The read length
Why a parameter for the read length at all?
We already know how long the string is!
.
The general rule is to have one authoritative source for any given peace of information.
Not only did OpenSSL have its own allocate, it also had logical dependencies on a security hole in the allocater. OpenSSL actually required, based on the way that it was written, that the data be available after it was freed and reallocated!
a = alloc(n)
*a = *x
free(a)
a = alloc(n)
assert(*a == *x)
WTF kind of coding practice is that?!
The short answer: better tools. Coverity isn't complete, nor are other tools. 15 years ago Coverity was an idea. 10 years ago it transitioned from a project in a university lab to a commercial product. 5 years ago it was used by the US-DHS to check 50 commonly used open source products, and many other proprietary products. Now holes in how it does what it does are being found and more tests and checks are being added. The tools are maturing but are not perfect yet. Its not a time to abandon these tools, its a time to improve them, make sure they 'fix' is able to find not just the current flaw but all other similar generic kinds of flaws like it, and then move on.
Because of Amdahl's law, a 1% increase in time could cause an unbounded amount of slowdown. You may go from having a cap of 32 cpus of performance to 4 cpus of performance because context switching takes longer, which causes some threads to hold locks longer. In the case of multi-threading, 1% can turn into 10,000%.
If translate OpenSSL -> C. Then you only need the translated code.
This. It is high time that by default C compilers did buffer overrun check.
It has been claimed that due to OpenSSL's own memory management, this wasn't actually a buffer overrun. If you allocate 10 bytes for X, 5,000 bytes for Y, and 50,000 bytes for Z, but your proprietary allocator puts all these items into a 1MB malloc block, then copying 50,000 bytes from X isn't a buffer overrun to the compiler.
The real problem was that the code tried to respond to requests that it shouldn't have responded to. In this particular case, trying to respond could have triggered a buffer overflow, but in other cases, it might not.
My experience is that reading code isn't a very good way to catch bugs, mainly because reviewers tend not to read it as carefully as the person who wrote it. If you want to find bugs, it's more effective to do white/black box testing of some sort.
That depends. Your reading of code can have three possible results: 1. "There are no bugs". 2. "There are bugs A, B, C and D; go and fix them". 3. "I can't understand the code to a degree that I can say it is bug free".
In case 3, the code should be rejected unless it is code handling some really hard problem that needs a better reviewer. The area where the Heartbleed bug happened was in no way difficult, so code that is hard to understand should have been rejected. If that happens, reviews reduce the number of bugs.
In addition: Even good programmers make mistakes. However, good programmers can write code that even with mistakes either works or doesn't work but doesn't have hidden problems.
Point taken, I've heard the same thing. This is also a problem with ancient languages: they have really primiitve malloc routines that call the kernel every time there is a malloc. The consequence is people roll out their own memory management routines.
Don't get me wrong, I used C heavily and really liked it, back in the late 70s and early 80s. Thirty years later is long on the tooth and with very little progress in between. The original version was released in 1973, the first revision took place 16 years later (ANSI C) and it was rather modest. Since then things have moved slightly faster with C99 and C11, but still not fast enough to correct what are, in retrospect, clear flaws in the language.
Maybe. I'm basically going on my experience here, code reviewers just don't put in the effort necessary to look for bugs.
If you can say you know how to always write code that is so clear that it never has any bugs, I would like to know how you do it.
"First they came for the slanderers and i said nothing."
TFA mentioned these advantages of the C-family as well.
-- Who am I? How did I get here? My God, what have I done?!
testing can show the presence of bugs, but not their absence.
Performance sensitive? really? most crypto is NOT performance sensitive at all and you could easily sacrifice some performance for more secure/reviewed code. I would imagine there are very few mostly fringe cases where the performance is more critical in which cases they should be uses modified versions not having hacks put into the main code stream.
First: how do YOU know whether crypto is performance sensitive or not "at all", because it's entirely dependent on the use of it.
Second: yes, it's absolutely performance sensitive because the trend is becoming to use HTTPS for everything. On a server that means the whole front end can greatly benefit from faster crypto, and on client side one of the most popular current Internet applications - video streaming - often uses crypto for DRM so the entire video stream needs to be decrypted in real time. Sorry, Netflix is not a "fringe case".
RFC 6520 clearly states "If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently." If best practice for test case construction and execution is done, this RFC item would be linked to one or more negative tests and these tests must pass to allow the code to move forward. I'm surprised that this was missed in such an important library. I'm also a bit surprised that this article fails to mention this.
"Multiple platforms" means nothing if it's not MY platforms (which looking at it in general, it's not).
In fact, due to C's popularity, pretty much every language in existence has a way to call to/from C. These vary in how heavyweight they are, but the overhead/complexity is usually due to having a different runtime model (i.e. garbage collection, different restrictions on value layouts), but that shouldn't be an issue for a language low-level enough to be considered as a replacement for C. We most definitely should be using some other language (or, equivalently, a subset of C that is statically checkable/checked to be free of certain classes of bugs, including buffer overruns like Heartbleed).
You are right. You can write bugs in any language. Unless you take the tremendous effort to prove your code correct of course, but even then you can only prove it secure against attacks you can think of (mainly a problem for crypto where every few years someone thinks up a new side-channel). You can't do that for most code, but you can do code reviews / other process requirements. That said, there's no reason to not mechanize checks against known classes of bugs. Whether you use a different language or a subset of C that conforms to a static checker that proves there are no buffer overflows / other bug classes you want to avoid,
If you are pushing out a lot of traffic then you would typically offload crypto duties to an application delivery device like F5 so your farm does not have to worry about the load of decryption/encryption.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
Not to belabor the obvious, but that takes the "Open" out of the equation, doesn't it?
All the world's an analog stage, and digital circuits play only bit parts.
Fully agree with you. Even in 1975 there were better, safer languages than C for systems programming.
What does that have to do with it? For example. as far as I can tell there is no MIPS support at all.
If you look at the OpenSSL Makefile/config, it's been ported to literally HUNDREDS of platforms. Of course, all of those have a basic C compiler. Probably 10% would be supported by AdaCore.
And, of course, yes, if you wanted to port OpenSSL to a proprietary platform and not release the source, that's perfectly acceptable given the OpenSSL license.
I agree with ThosLives, it was a design issue. Heartbleed could have been avoided if the input language was designed to be context-free. The error was caused by the use of a length field, which makes the input to the system context-sensitive. This was not necessary. Start and end delimiters could have been used instead, which would have made the vulnerability impossible. The input language to a software component should be recognised by a machine with the lowest computational power possible. In the case of a TLS hearbeat message a regular language would do the job. Comments which were mentioning it should not have been implemented in C were close to the mark, the input parser should have used only regular expressions. I have written a review of a paper on this topic which has changed the way I think about designing software inputs: http://edenduthie.com/2014/05/...
The reality was both more interesting and much worse than the above implies.
The OpenSSL project had one full time programmer as gatekeeper; he passed the code and added it to the tree, when in fact it missed a bounds check the RFC it implements says should be made.
As an OSS project that accepts patches from the community, the submitter could have been anyone, of any level of ability. In practice, the submitter was a student, who had written not only this patch but the RFC that describes the change, as part of his thesis project. The idea was to increase the efficiency of SSL *in UDP* for applications such as OpenVPN, by adding a "are you still there?" heartbeat exchange.
The final patch was submitted (and accepted) on the evening of Dec 31; I am at least slightly suspicious of the timing, as it smells of trying to meet some arbitrary deadline (and a student throwing in his work "under the wire") rather than the "when its as perfect as I can get it" criteria that should govern a submission to a security product.
-=DaveHowe=-
Thing is, there are some safety features in C that could have been used. If there had been a consistent use of calloc() instead of malloc(), Heartbleed would not have been exploitable. (My guess is that they used malloc() since it's a touch faster than calloc(), since it doesn't zero the heap.) Personally, I think their handling of the memory heap was just asking for major trouble.
I believe that any team that manages to take something written in C and make it less safe is going to screw up royally in any language. Moreover, since they removed what pitiful protections C has for the sake of performance, they wouldn't have written OpenSSL in a safer language in any case.
BTW, C++ is a far safer language to write this stuff in than C. It's a C variant in the sense that Java is. I don't know that it's a good language for security software (although a whole lot better than C), but when I discussed this on Bruce Schneier's blog I found that nobody there knew anything about C++ more modern than my son (finishing his second year at college now). Since it has all of C's performance ability when you want it, it is probably worth a second look.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
My experience is that code reviews catch a lot of bugs, myself. Testing is good, but there's lots of stuff it's never going to catch.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I don't think regulation is the answer; I think that holding businesses accountable is the answer. If it seriously hurt a company to get hit by Heartbleed, they'd have an incentive to make sure OpenSSL worked right.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Except that this wasn't a buffer overrun. Given a request to return the 65K characters of "foo", apparently OpenSSL allocated a 65K buffer and went through it properly. The problem here was that the memory hadn't been cleared out.
Still, proper use of C++ will do wonders at stopping buffer overruns.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
If you are worried about security don't use software written by people who can't be bothered to check parameters.
"If Engineers built buildings the way Programmers write programs, the first Woodpecker that came along would Destroy Civilization!"
When free enterprize gets bad enough, regulation is the result.
Clean up your act, or you will be roadkill for the control freaks in government!
If you think back, you'll be able to think of plenty of bugs that made it past your review.
"First they came for the slanderers and i said nothing."
Sure. I've written plenty of bugs that got into production despite code review and testing. That doesn't mean testing and review are useless.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
No one said testing and review are useless
"First they came for the slanderers and i said nothing."
The allocator was never "100% necessary". It might have been advantageous in some systems, but in vast majority of systems it have never been more than a hassle. Then when they made the OpenSSL unworkable without their allocator - or rather without the undocumented behaviour their allocator happened to have, they should have removed it immediately. But no, they were macho, they thought "we know better".