'Heartbleed' contributor denies he inserted it deliberately
smh.com.au
smh.com.au
But what required the denial from the developer (and I feel horrible for him) is that this bug gained so much mainstream attention and speculation. It was only a matter of time before a reporter wanting to further the story got in touch with him.
He was in a bad situation - don't respond and have that misconstrued or respond and deny and give credence to the theory.
We all know that he didn't do it intentionally and in absence of any supporting evidence in all cases these are simple mistakes, but the general public who are currently whipped up in a frenzy around NSA revelations don't know that.
Actually, I hadn't known that. But this article gave me strong reasons to believe that it was, indeed, accidental. I certainly recognize that this is the sort of mistake that is extremely easy to make.
Never mind the fact that the code was apparently reviewed, so I guess the reviewer would have been in on it as well.
There are always people who prefer to play the blame game instead of actually working to solve the problem.
If something is important to you, you should spend more resources than zero on it.
Most static code analyzers could have caught this particular bug, as it requires only a fairly simple kind of reasoning about allocated vs. used length. In fact I believe it probably was found by static analysis before being reported by a human, which is a shame because it misses an opportunity to highlight the value of such tools. Maybe next time people will spend a little less time designing a logo and a little more time doing things that actually help (though that's a wish and what I expect is the exact opposite).
The real lesson here is that we should apply as many different tools and processes as we can at improving code quality for critical infrastructure. Code reviews are nice. Static analysis is nice. Detailed tests are nice. However, none of these alone is sufficient even when pursued with fanatical devotion.
So you want the graphic designers contributing to crypto code?
As someone who is a mid level programmer but a decent/good designer, the only way I'm able to contribute to some projects is through things like logos.
Don't use this straw man argument to make your point, which is otherwise valid.
We have looked at it. Repeatedly. First when porting Chrome to Linux (and trying to decide what sort of UI there should be for NSS cert management). Then for ChromeOS. And then again, revisiting it in light of the OpenSSL migration.
The reality is, the certificate management/configuration UIs, of all platforms (Windows, OS X, Linux-via-Firefox-and-Chrome-which-just-copies-Firefoxes-PSM), is hard. It's hard to express the decisions. It's hard to explain how the branching and cross-certifications of CAs can affect trust decisions (eg: recall DigiNotar's cross-certifications).
And in the end, it's not where users are spending their time/being tripped up. Getting the lock icon into a more meaningful state is a far, far greater investment, with far, far more actionable returns in users security. The work of the Chrome Security Enamel team on this - especially Adrienne Porter Felt - has been focused on trying to improve this.
I'm not saying that. I'm saying that the fact that there's only a UI to configure your root store, and not a UI to:
* set policy for which CAs you trust with which domains
* subscribe to policies published by trusted third policies
* monitor which sites bind you to which CAs
* easily opt in and out of trusting different CAs
... is the big problem. It's a UX problem, not a simple UI problem. There are additional features that need to be added, and that can be added, without litigating the whole CA system.
The OpenSSL project doesn't seem to have a 'review' step[0] in code commits, unlike FreeBSD, OpenBSD and Chromium (i'm just picking projects i'm familiar with, no bias).
So it might not have been 'many eyes', but the eyes of just one.
edit: [0] a proper review step, what the openssl project does is have feedback on commits (which is what the OP article is referring to). see below.
http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest...
That is very far from it being a security review, or any real proper review. It is more a request for comments (which defaults to code being committed)
You'll notice that the workflow for commits doesn't have a review stage, and it isn't implemented in the workflow software.
Compare to a chromium example, where each commit, eg.
http://src.chromium.org/viewvc/chrome?view=revision&revision...
has a review stage that the original committer doesn't have permissions for. In this case 3 reviewers for that commit:
https://codereview.chromium.org/231923002
Code doesn't get committed without at least 4 people, its like a 2-man rule that is enforced in the workflow.
In contrast the openssl process is that the same committer can push the code after getting no objections. There is a big difference in how each of these processes work.
And some of that only applies when you're Linus.
Does that mean nobody out there in the crypto world ran a static analyzer on OpenSSL in the last 2 years?
Even if that weren't the case, I think this particular bug would still qualify as low-hanging fruit. It doesn't involve a lot of macros. It doesn't involve dynamically assigned function pointers. It's not limited to one execution through multiple iterations of a complex loop. I'm painfully familiar with the constructs that can defeat static analysis, and none of them seem present in this case. The code allocates a buffer of size N, then reads from an offset that's not checked to be less than N. That's kind of Static Analysis 101.
My biggest worry here, TBH, is that static analysis was done, and this was flagged, but it was buried among so many other reports - many of them false negatives - that nobody paid any attention. That would be truly sad.
The lesson out of this ordeal is probably to be as skeptical as possible of everything you take for granted. How do you know that you're secure? What if your assumptions are wrong? Try to invent ways to break your own assumptions. The best way to protect yourself is to try to defeat yourself.
Unfortunately, "ain't nobody got time for that," as they say. But if you find time, it's quite rewarding. And disconcerting. You'll wonder why we're still wrestling with these fundamental problems in 2014, and then you'll start questioning the foundations we've been relying on until now.
In the long run, yes. In the short run, only you know about it and can exploit it from day 0, others are presumably going to take some time to find it, and it may go unnoticed for years or never be found (I understand the error was only present in some versions of OpenSSL and both older and more recent versions were free from it). I'm inclined to think the author made a simple mistake but this does not seem like sufficient incentive against someone introducing such a vulnerability.
Seriously, this place is like Lord of the Flies sometimes.
now, perhaps you could answer the original question I was asking: shouldn't we rule out malice?
Now would be a nice time for one of the Lint vendors to donate copies of their product to some of the OpenSSL team members, and for them to dedicate some resources into fixing the more important stuff it finds.
Bounds checking incurs such a trivial amount of overhead, and the potential cost of straying out of bounds is so high. I understand we've got decades' worth of C culture built up around coding idioms that are incompatible with type safety and bounds checking. I understand that means that developing and migrating to a dialect of C or C++ that offers something in the way of a safety net is anything but trivial. But we've also got decades' worth of painful examples of just how catastrophic - and difficult to prevent - these kinds of errors can be, and that alone should justify the cost.
At the very least, consider the example set by C#: Be type safe and do bounds checks by default, but provide an `unsafe` keyword for those cases where it really is necessary to disable them.
I really hope it doesn't affect his career..
I'm all for being aware of the possibility that shenanigans are involved, but until proof comes out, it is nothing but a possibility, and a remote one at that.
This, incidentally, is the same sort of thinking that sometimes kills experts in dangerous situations: the assumption that someone smarter than us must by definition know more than us, so we can be lackadaisical. Witness Snow Fall (http://www.nytimes.com/projects/2012/snow-fall/?forceredirec...)
1) and a simple reading of the license
I think any company that is damaged by this should get all their money back, all $0 of it.
Some big-name cryptographers have started implementing some useful crypto services in Go, so we'll see whether it catches on.
EDIT: Is the JVM generally trusted by cryptographers? I just realized that TextSecure is java code. Is the side channel threat posed by GC not too serious, then?
There can be safer-than-C languages that don't use GC, e.g. you don't need GC for array bounds checking. You can use reference counting for more deterministic garbage collection.
No problems here.
EDIT: Objective-C doesn't solve the problem at all. (More precisely, it requires manual intervention by the programmer.) See http://stackoverflow.com/questions/6260256/what-kind-of-leak...
From the article: "This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original."
Some backrground info on Objective-C's memory management: http://stackoverflow.com/questions/7874342/what-is-the-diffe...
It's an interesting approach to insert release calls at compile time. Maybe it's worth not solving the cyclic reference problem in exchange for determinism. Thank you for pointing that out.
The question of cycles is even more pertinent with ARC, because it's easy to get used to letting the compiler do everything for you, and it's easy to miss an occasional leak of a cyclic object graph.
I don't think cyclic object graphs are needed to, say, respond to a TLS heartbeat without out-of-bounds reads.
I'm curious what about Go's GC leads you to say that? Is it that when you get a new chunk of bytes, they've been pre-zeroed? That's not specifically a characteristic of the GC but it's my best guess. Otherwise I don't know what it would be, which is why I ask.
I remember some discussion on HN where someone mentioned that GCs pose a problem for secure code due to the non-deterministic nature of GC. There's apparently a nonzero chance of introducing a side-channel attack via GC. Until we're certain that chance is far closer to "zero" than "non-zero," we should either study that threat vector in detail or find a safer option.
It would be horrible to switch to something which is then proven to be broken in some fundamental and unfixable way, such as a GC side channel attack.
Could a GC'ed language not just pause the GC thread while it executes a given block of code?
[1] http://lkml.iu.edu//hypermail/linux/kernel/0311.0/0635.html --
Makes me wonder how many serious bugs I have pushed to production in the last year or two. Yikes.
The cost of regularly reviewing codebases like OpenSSL would likely not be that high when compared to the potential impact of a breach because of a flaw in the software.
They didn't say how much else got flagged, and how many false positives there were. It's very easy to retrospectively look through the list and say "oh yeah, there it is, amongst this big pile of nonsense".
A little less briefly, then. ;) It is absolutely possible to create code that these tools in general, and Coverity in particular, will have difficulty analyzing . . . but you really have to work at it. Seriously, these guys are good. It's a bit like the "arms race" in building vs. breaking crypto. These guys have been there, they've seen all the moves, they know all the countermoves. Sure, if you load up your code with runtime-assigned function pointers and code that only executes if the last five iterations of a loop each went through specific code paths themselves, then that's going to cause some problems, but most programmers are unlikely to "win" that battle.
However, this particular bug looks like it's in the absolute easiest category. Any static analyzer should have caught it. As others have pointed out, the real problem is false positives. If it was caught, but the report was buried in hundreds or thousands of crappy reports about things that actually aren't problems, then it might as well not have been caught. That's why the pros at this spend as much time writing code to eliminate false positives as they do writing code to find new things. In every project I've worked on that used static analysis, the weak link in the chain has been between reporting and remedy, not in the analysis itself.
Which I would HOPE is not the case here.
Of course, the argument can often be made that if it isn't clear enough for the tool to find, it's not clear enough for a person to understand quickly.
My stance (which I made clearer elsewhere in the thread) is more along the lines of: if it's not being done by the core maintainers, but just by concerned third parties, it's very easy to lose the signal in noise you don't have the ability to refactor away (because of time, difficulty getting it merged upstream etc.)
So I'm not surprised that given the context it was missed by people running static analysis over it. That context is wrong, and it should have changed a long time ago, but under that context I can see it getting missed [1].
[1] By interpreting static analysis results, not necessarily by the code author and reviewer.
http://openssl.6102.n7.nabble.com/Coverity-coverage-of-OpenS...
mentions that one OpenSSL developer used to see defect reports from Coverity (probably through Coverity's scan project). He states:
"Coverity used to, and perhaps still do, run scans of OpenSSL, which we had (have?) access to. I used to look at them and fix relevant ones, but got irritated with the false positive level in the end.
If Coverity were interested in fixing their bugs, I might get interested in looking at their reports again."
Of course this doesn't demonstrate that Coverity found this particular problem, and since he doesn't state what the false positive rate was it's difficult to know how reasonable his statement is.
So no, Coverity wouldn't find it.
One of the things that sucks about the Federal sector is that they are dominated by Microsoft and Oracle shills (the kind of IT pros who can't learn new skills unless its spoon fed pre-digested in the form of industry certification training) who do nothing but scream about the danger of open source. Now of course we all know that the only difference between enterprise and open source security holes is that the former go undiscovered for longer, and when discovered by the code owners aren't disclosed despite them having knowledge that black-hats know about it.....
But make no mistake. This fucking idiot [Edit: Ok, this isn't fair, this could happen to anyone, so he's not an idiot, but why not use a static analysis tool?] who did this to OpenSSL and the idiots who let it happen are going to set open source in the Federal government back YEARS. Not because its an actual threat, but because it will be used by the enterprise assholes as a weapon to keep selling their shitware to the risk averse morons who make up the giant pile of middle manager idiots that composes the Federal government.
I've already told my boss I'm not doing any more public sector work after my current project ends, and this is the nail in the coffin for me touching it ever again.