10 ms·
'Heartbleed' contributor denies he inserted it deliberately
- systematical 13y agoYeah most of my bugs are deliberate. I like the feeling of making mistakes and seeing my boss run out of his office frantic.
- venomsnake 13y agoJust wait till you have been told - it is running too fast so the client won't perceive it as a "serious" software ... slow it down.
- iwwr 13y agoThe problem is not that bugs happen, but that certain categories of bugs still happen when we have means to avoid them altogether.
- venomsnake 13y agoDoes static code analysis or something like that would have caught the bug?
- systematical 13y agoWe lack perfection and we are not always programming at peak form even when are programming at near peak (personal) efficiency we are still not perfect. This bug even made it through a code review. Makes me wonder how many serious bugs I have pushed to production in the last year or two. Yikes.
- sillysaurus3 13y agoI believe it. Crafting a weapon that can be used by both you and your enemies would be pyrrhic. 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.
- flatline 13y ago> Crafting a weapon that can be used by both you and your enemies would be pyrrhic. 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.
- iwwr 13y agoIt may be impossible to distinguish genuine bugs from bug-backdoors, which is why it's important to start developing crypto in safer frameworks and languages. C considered harmful.
- sillysaurus3 13y agoThe problem is that GCs are considered harmful to crypto code, though that may be changing with Go. We won't know for about 5 years whether it's trustworthy, and even then, the side channel threat posed by GC may be worth worrying about. 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?
- gsnedders 13y agoRust provides memory safety without a GC, which seems more promising than anything else for this sort of application.
- pornel 13y agoC vs GC is a false dichotomy. 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.
- sillysaurus3 13y agoRefcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.
- anextio 13y agoObjective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.
- dexen 13y agoCompare with the attempted 2003 Linux kernel backdoor [1], which gave root when sys_wait4() is passed uncommon combination of flags. The bug looked inconspicuous and honest enough. [1] http://lkml.iu.edu//hypermail/linux/kernel/0311.0/0635.html http://lkml.iu.edu//hypermail/linux/kernel/0311.0/0635.html --
- weavie 13y agoI can't imagine what this guy must be feeling right now. I find it embarrassing enough when I am outed in my small team for producing a bug that makes it into production. To be known around the entire internet to have caused the largest security bug in recent times must be quite a slammer. I really hope it doesn't affect his career..
- Karunamon 13y agoThe armchair crypto brigade aren't helping much, either, by passing around these completely unfounded accusations of malfeasance. 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.
- kmkemp 13y ago"Never attribute to malice that which is adequately explained by stupidity." Obviously "stupidity" is way too strong here, but the principle still applies.
- senorprogrammer 13y agoIn this case I would replace "stupidity" with "assumption". It was code-reviewed so that level assumed correctness. It's in OpenSSL, which is written by experts, so the millions of us that use it every day assumed correctness. Our customers know little about the workings of the internet, so they assume correctness. 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/?forceredirect=yes#/?part=tunnel-creek http://www.nytimes.com/projects/2012/snow-fall/?forceredirec...)
- anonbanker 13y agoThe rest of the quote is "...but don't rule out malice."
- 13y ago
- krstck 13y agoIt we start naming and shaming the coder for each flaw instead of working on fixing the process that allowed it to sneak through, we'll see a chilling effect on open source software. There's a reason we have tests and code reviews and security audits...
- talmand 13y agoUnfortunately the tech industry seems to be in mob mode recently so I would think the chilling effect is already well underway. The fact that it has been suggested this was done intentionally before they know the whole story suggests this to me. 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.
- danielweber 13y agoPart of me wants to see the team give the industry a big middle finger and quit the project, and now companies relying on it have to start spending money to keep it up instead of expecting it to be provided for free. If something is important to you, you should spend more resources than zero on it.
- talmand 13y agoDoes anyone know of a resource that shows who contributed and how?
- phazmatis 13y agoThat would be great. Maybe we could get some TDD people in there. Some competent c engineers, rather than code cowboys.
- MetaCosm 13y agoBecause TDD is the "new" magic bullet, replacing all the magic bullets before it. Also, TDD works great retroactively on large open source projects with vast histories.
- chiph 13y agoAny C programmers who have never failed to check their bounds? Anyone? Anyone? Because everyone has done it. 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.
- bunderbunder 13y agoOr better yet, start seriously talking about moving to a language that doesn't make it so stupendously easy for trivial bugs like these to get so far out of hand. 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.
- tptacek 13y agoStrangely, nobody's tracking down the nginx developer who inserted the exact same bug into nginx just a few years back (a NUL in a header would cause the header copies, done using strncpy, to abort early and expose uninitialized memory). He must have been an NSA plant too, right?
- deleted 13y ago[deleted]
- anonbanker 13y agoWhy aren't we doing exactly that? While its best not to attribute to malice what could easily be explained by human stupidity, shouldn't we try to rule out malice?
- tptacek 13y agoYes! More witch hunts! That's what I was suggesting! Seriously, this place is like Lord of the Flies sometimes.
- anonbanker 13y agoI was recently moderated[1] by dang for attempting the same aggressive sarcasm you are now exhibiting. You might do well to heed the same advice I was given. With that in mind, please forgive any misinterpretation of your position you may have inferred. now, perhaps you could answer the original question I was asking: shouldn't we rule out malice? [1] https://news.ycombinator.com/item?id=7542802 https://news.ycombinator.com/item?id=7542802
- Symmetry 13y agoMy priors on this being deliberate are pretty low, but I'd expect this denial either way so it really isn't evidence against the idea.
- fit2rule 13y agoI just can't understand why such critical components as OpenSSL just don't use Code Coverage tools like Coverity to find such things as this? Testing, coverage certification, static analysis: this would have been caught if these tools were being used.
- peeters 13y agoIt would shock me if those tools would actually have caught this bug. That would imply that no benevolent contributor or researcher had run them against OpenSSL in the last two years, which I find incredibly hard to believe, as static analysis is a logical first step in researching a code for vulnerabilities, and OpenSSL is probably in the top 5 most valuable pieces of software to validate.
- fit2rule 13y agoI just ran Coverity on code that is similar to Heartbleed's bug, and it caught it. So, I think this is really just a glaring omission on a lot of peoples' part - but like you I also find it hard to believe nobody ran this code through static analysis. Its mind-boggling.
- ajanuary 13y agoI don't know how Coverity works - is it possible that surrounding it with more complex code will cause it to miss the bug because it doesn't have enough information to not constantly raise false positives?
- notacoward 13y agoMaybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" - which was always total BS from the day it was uttered. There's so much code out there, much of it highly specialized and even project-specific, that there are very few eyes looking at any particular piece of code, and not all eyes are connected to the greatest of brains. 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.
- nikcub 13y ago> Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" 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.
- sp332 13y agoThe article says there was a reviewer who looked at this code before it was moved to the release branch.
- nikcub 13y agoIt refers to 'review' as in reviewing the features and how it is implemented. Here is the log: http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest&pass=guest 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=262978 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 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.
- raesene3 13y agoHopefully one positive thing that will come out of this whole Heartbleed thing is that companies making extensive use of Open Source software for security critical purposes will consider contributing to ensure that security reviews are carried out on them. 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.
- JPKab 13y agoI work with both private and public sectors in the DC area. 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.
- tptacek 13y agoSo your theory is that nobody in the last couple years ever ran Coverity or Fortify on one of the top 5 security codebases on the whole Internet?