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.
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
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.
What did I miss?
An article before the word "bad."
Slashdot: providing anti-social weirdos a soapbox, since 1997.
My ID is hardly 'new', but this place has surely gone downhill. :(
If firefighters fight fire, and crimefighters fight crime, what do freedom fighters fight? - George Carlin
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.
Eiffel compiles to C. Pascal can compile to C (I think k that Linux Pascal 'compiler' is just a translator to C and gcc)
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
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!
I have no idea why you're maintaining that "Republicans" create these bugs, and I'm, like, a socialist.
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.
> 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
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."
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?
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.
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."
I think that sometimes too, but when I actually go back and browse the old articles, it's mostly the same stuff.
Yep. It's a thing you include to guarantee your post to be modded up. ;)
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.
The Heartbleed vulnerability existed for a long time, then it was fixed quickly when finally discovered.
The recent Internet Explorer vulnerability existed for a long time, then it was fixed quickly when finally discovered.
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.
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.
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.
it's super effective.
Spent All My Mod Points
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...
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.
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.
like lack of QA / testing
This was not a bug that would have been found in testing. It doesn't _attack_ the software. The software was totally unaffected. You could have a very specific test.for this problem, but if you thought of that test, you might as well have looked at the code and immediately spotted the problem.
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...
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.
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.
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 ...
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.
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.
Wrong bug dude. Heartbleed was a buffer overread.
I'm really glad you're trying to think of alternatives. However, when you say: 1). Initialize all allocated memory. Routinely and automatically.... They did. But the Heartbleed bug let you see currently-active memory. In particular, you have to have the private key available somewhere so you can use it.
Some of the weirdness was due to the spec itself (RFC 6520). I agree that error avoidance is better than parameter-checking, but it's not clear that parameter-checking could have been avoided in this case. But that's certainly worth checking out.
- David A. Wheeler (see my Secure Programming HOWTO)
Profiling w/ 100% code coverage would have caught this bug. - No, code coverage would not have worked in this case. Since the problem was that code was missing, you can run every line or branch without triggering the vulnerability. For more, see: http://www.dwheeler.com/essays...
Input fuzzing in the unit tests under memtest could have located this bug even faster. - No, not in this case. Fuzzers were countered because OpenSSL had its own set of memory allocators. When fuzzing you often are looking for crashes; to force buffer over-reads into a crash, the usual way to do that is to override memory allocation. Since OpenSSL managed its memory separately, the override had little useful effect. For more, see: http://www.dwheeler.com/essays...
- David A. Wheeler (see my Secure Programming HOWTO)
The LLVM static analyzer finds this bug. So would warning about dead code, since the code past the point of the second goto...
Um, no. You're talking about the Apple "goto fail; goto fail;" vulnerability. That's a different vulnerability in a different program. They're both vulnerabilities in TLS/SSL implementations, but they are different programs.
- David A. Wheeler (see my Secure Programming HOWTO)
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).
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.
DOES NOT COMPUTE
You must be one of those high-level language compilers to have caught that error.
"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.
I know just enough mathematics to impliment my own key exchange and assymetric encryption functions.
I also know enough cryptographic practice not to attempt to do so. I leave that to the expects who know all the non-obvious mathematical tricks too.
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
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.
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.
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.
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.
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%.
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?!
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).
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".