Slashdot Mirror
Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake
nk497 (1345219) writes "The Heartbleed bug in OpenSSL wasn't placed there deliberately, according to the coder responsible for the mistake — despite suspicions from many that security services may have been behind it. OpenSSL logs show that German developer Robin Seggelmann introduced the bug into OpenSSL when working on the open-source project two and a half years ago, according to an Australian newspaper. The change was logged on New Year's Eve 2011. 'I was working on improving OpenSSL and submitted numerous bug fixes and added new features,' Seggelmann told the Sydney Morning Herald. 'In one of the new features, unfortunately, I missed validating a variable containing a length.' His work was reviewed, but the reviewer also missed the error, and it was included in the released version of OpenSSL."
hats off to the developer who admits a mistake.
I suspect s/he'll get pilloried in the press and may end up with some lawsuits (?) but I, for one, recognize a person big enough to take responsibility.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
The design of the feature looks like a backdoor too. A heartbeat function with a variable length payload, and there is a superfluous field for the payload length, and all running on top of TCP, which already has a keep-alive function? And then the feature contains a "rookie mistake", but still passes review. Yes, we totally believe you. It was a mistake.
All I know is the organization I work for has prohibited use of C or C++ for mission critical software for years now. The languages we use would not ALLOW code to execute which tries to copy 64K from a 2 byte sized container.
Part of software engineering is to use the right tool for the right job. When a buffer overrun can destroy the security of the entire internet, you damn well better not be using C as your tool. Or assembly language for that matter.
Do that where I work, and you'd be fired.
The bigger problem is coders that think they need to optimize for speed.
Read the horror here: http://article.gmane.org/gmane...
Ugh... premature optimization, the root of all evil. And now also the root of the biggest security hole ever.
Bram Stolk http://stolk.org/tlctc/
http://article.gmane.org/gmane...
I'm sure the project will appreciate your patches.
I found your post on slashdot and used it as legal advise.
It turns out you were negligent in checking your facts so I'm suing you for damages.
Welcome to Engineering. Scott Adams (of Dilbert fame) best summarized this disconnect between commendation and blame in the Engineers Explained chapter of his book:
Serious question: Why don't you become the new maintainer yourself, if you honestly believe you can do a significantly better job at it than the current person(s)?
I don't do it myself because I can not guarantee that I wouldn't make even worse mistakes. I'm glad there are people out there who are willing to do the job, and I'm in no position to bite their heads off when they mess it up. And you're probably glad that I'm not a maintainer of anything even remotely security-related :-)
I know this is redundant but this is funny:
Seggelmann told the Sydney Morning Herald. 'In one of the new features, unfortunately, I missed validating a variable containing a length.'
https://tools.ietf.org/html/rfc6520
Internet Engineering Task Force (IETF)
Request for Comments: 6520
Category: Standards Track
ISSN: 2070-1721
R. Seggelmann, M. Tuexen: Muenster Univ. of Appl. Sciences
M. Williams: GWhiz Arts & Sciences
February 2012
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension ...
If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.
Can't even implement an RFC he wrote himself. Nice one.
Watch this Heartland Institute video
Why does the heartbeat request even contain the length of the heartbeat block? We know the length of the SSL record!
The record has two variable length fields, so you need a length field for either the payload or the padding. In this case the payload has the length field and the padding length is implicit.
I glanced at some of the OpenSSL C code, in particular the new code that introduced this bug.
I don't disagree about the 'coding style' issue, but that kinda misses the point. The points are:
Theres a memcpy() - where is the bounds checking? Hello? Its not 1976. We all know memcpy is dangerous. Where there's a memcpy there should be a bounds check... even in a fart app. If the project has secure in the title there should be paranoid anal-retentive checking of both the source and destination buffers.
The code uses data that has come from teh interwebs, - again, where's the obsessive-compulsive validity checking on everything that comes in?
However, that's still not the point. Programmers make mistakes - and this bug was at least a bit more subtle than the usual one where the bad hat sends an over-length string.
The problem is with the oft-made claim that Open Source security software is extra-safe because the code is public has been seen by many eyeballs. That claim is dead. Possibly crypto experts have been all over the actual encryption/decryption algorithms in OpenSSL like flies on shit - however, clearly none of them looked at the boring heartbeat stuff. That shouldn't be the death of open source, though - Windows is proprietary and look at the sheer terror caused by the prospect of running Windows XP for one day after the security patches stop...
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
The date that it was added to the OpenSSL codebase is very close to the time when the leaked NSA documents claim that they had a 'major breakthrough' in decrypting SSL. I would imagine that they are not responsible for introducing it, but do have people doing very careful code review and fuzzing on all changes to common crypto libraries, so I wouldn't be surprised if they'd known about it (and been exploiting it) since it was originally released.
I am TheRaven on Soylent News
Doctors are human. We hold them accountable for their mistakes. Engineers are human. We hold them accountable for their mistakes. Indeed, we hold just about everybody accountable for their on-the-job mistakes and the consequences of their mistakes result in everything from terminations to criminal proceedings.
So, when should programmers be held accountable for their mistakes, and how should be respond as a society?
The road to tyranny has always been paved with claims of necessity.