15 ms·

"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

497 points by anon1385 13y ago

greatsuccess 13y ago
And why are we making excuses for a excuse me fucking idiot who wouldnt bounds check a goddamn len??? In SSL? What are we a bunch of pretentious fucking children who forgot how to code? Untrusted input HELL fucking LO!
bananas 13y ago
Great analysis. Theo is always up front on this sort of stuff which is commendable.
- simias 13y ago
  Could have done without the final line though, but I guess it's his equivalent of a signature...
  - baq 13y ago
    theo's an asshole, but he's quite often right. i don't like his attitude too, but it has to be said that in this particular case, consequences have been - and/or will be - extraordinary.
    - Gigablah 13y ago
      "OpenSSL is not developed by a responsible team" is downright benign compared to "OpenSSL is written by monkeys".
    - caf 13y ago
      Well, really the consequences would have been virtually the same either way, since the number of OpenSSL deployments where the system malloc uses guard pages is a rounding error.
      - Sanddancer 13y ago
        Yes, but because of the caching malloc, the OpenBSD implementations are just as affected as the rest of the world's. Irresponsible software design sucks, plain and simple.
        caf 13y ago
        It is a stretch to call this irresponsible. Is there any evidence that the OpenBSD people ever drew upstream's attention to this?
      - usefulcat 13y ago
        Not necessarily. It's probably still more likely that the bug would have been discovered sooner, even if only via a relatively small number of crashes.
  - kzrdude 13y ago
    No, that's essential, that line is the message. A secure library should be defensive in coding style and implementation, not sloppy. It should have defaults that err on the safe side, not the fast side, if you have to choose.
    - simias 13y ago
      It's a massive open source project that's more than 15 years in the making and supports a massive range of architectures and ever-moving standards. Shit happens, we need to figure out how to make sure it won't happen again at this scale, there's really no need for name calling.
      - kryptiskt 13y ago
        We need to stop have such a fucking accepting attitude about sloppy engineering in security-critical code. People who don't want to be held to a high standard should get out of there and go do something that can't break the internet.
        mattgreenrocks 13y ago
        This entire thread is eye-opening. It's as if open source gets a pass on almost everything related to quality because it's free and open. The unspoken belief is that a magic person will come along and fix everything in the indeterminate future. Also, the mantra: "all bugs are shallow." If you refuse to understand the reasons for engineering, conceptual integrity, and discipline in writing code that needs to be readable (read: dull and boring), then I don't know what to say.
        simias 13y ago
        I'm not saying we should accept sloppy engineering in security-critical code, I'm saying that it's pointless to insult people who contribute to free open source projects from the outside. We want to incite more people to audit and contribute to these projects, not the other way around. Insult the engineering, not the engineers. Or, alternatively, don't insult and propose improvements.
  - MrBuddyCasino 13y ago
    To quote Ted Dziuba: "Anyone who ever told you that swear words have no place in technical discussion is right. They're right, and sadly, they're part of the problem because they miss the point. The sterile word placement that's supposed to support an argument makes any true motivation indistinguishable from all the hired bullshit. [...] However, when someone starts swearing in technical discussion, showing emotion, that's a strong indicator that I'm about to receive wisdom. Wisdom is earned the hard way, and it is permanent, not like some statistically shaky performance benchmark that we'll all forget about next week." I feel the same - I'd rather have people feeling passionate about their work and use swear words, than work with polite non-personalities that don't give a fuck.
    - spacemanmatt 13y ago
      I absolutely depend on some swearing to draw a clear line between the factual presentation and everything else. I think this is why beer:30 and stepping away from the office with coworkers is important. People matter. The way software makes them feel matters. Code smell and related concerns are best conveyed in profoundly human ways. Fuck it. Say it like you mean it.
    - Tyrannosaurs 13y ago
      Swearing isn't required for passion. Martin Luthor King didn't have an (expletive of choice) dream, he just had a dream. There are plenty of people who care about their work and manage to express that without swearing. Similarly there are plenty of people who swear about stuff who may well be committed but it's highly questionable about what they're committed to and whether it's to the benefit of the project / team. If someone does swear (and as it goes, I'm fine with swearing for emphasis and swear way more than I feel I should) they need to be aware that some people find it offensive and that if they don't moderate their behaviour it may be taken very personally which can result in barriers between colleagues and / or low morale. You can choose to say that that's the person reacting's problem but if you do so you need to be aware of the price that comes with (that they're working in an environment with which they're not completely comfortable which is unlikely to get the best out of them). The alternative is that the swearer moderates themselves (with which they in turn may not be comfortable). Obviously the better you know your colleagues the more leeway you have. If you've built up trust and togetherness overtime you can get away with anything but even then you need to consider what happens when new people join the team. But ultimately this is about people and where it's about people there are no absolutes - what works for one group will be kryptonite for another.
  - SixSigma 13y ago
    Theo is such a "character" that his "work" has been incorproated into the plan9 spin-off 9front as a theo (1) specific fortune file. http://man.cat-v.org/9front/1/fortune http://man.cat-v.org/9front/1/fortune
    - bananas 13y ago
      The mg implementation that ships with OpenBSD has a fair few insults in it as well under the command "theo": http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?rev=1.133 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?...
    - groovy2shoes 13y ago
      And here's the theo fortune file: https://plan9front.googlecode.com/hg/lib/theo https://plan9front.googlecode.com/hg/lib/theo
  - rbanffy 13y ago
    You must be joking. "OpenSSL is not developed by a responsible team" is probably the most benign criticism Theo has ever issued. And he's quite right. This is a class of bug that should not exist or, at least, be restricted to the OSs where "malloc() performance is bad enough" to justify using their own implementation. Memory management is a non-trivial problem.
  - mattgreenrocks 13y ago
    The lower you are on the stack, the more you need quality. And the more you need quality, the more likely you are to run into hackers with 'tough love' personalities, because they simply cannot tolerate poor excuses for code. How they express it is a reflection of their character, but they will let you know when you screw up. Theo was extremely tact given the enormous impact of this bug.
- tjaerv 13y ago
  For the benefit of those who don't know who he is: http://en.wikipedia.org/wiki/Theo_de_Raadt http://en.wikipedia.org/wiki/Theo_de_Raadt
btown 13y ago
This should be a case study about why people developing system-critical software shouldn't write their own memory allocators.
- jwr 13y ago
  At a first approximation, no one should write their own memory allocator. Just as no one should write their own garbage collector, and no one should write their own filesystem. All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.
  - pwang 13y ago
    I disagree. These are complex to make robust, but they are not hard concepts. I think everyone should write their own GC, write a filesystem, and handle their own memory layer, at least once. Treating lower levels of the stack as "too complex, there be dragons, just write some Javascript that hits RESTful API for JSON" is a great way to ensure you never progress as a software dev or an engineer. I agree that reinventing the wheel poorly - without understanding geometry or physics - is a terrible idea. But I also think that we don't have enough people nowadays making toy wheels to learn about geometry and physics. For each of the things you mentioned, there are concrete and good reasons why they grow complexity: filesystems need to be robust to media corruption and power faults; memory allocators need to be highly tuned to OS and architecture memory layouts; GCs need to be optimized for the code patterns of the particular language they serve, as well as understand the same OS and hardware memory constraints as allocators. But much of the complexity of these layers is not intrinsic to the problem, and not related to the above. In fact, most of the complexity and bugs of production code at these layers have to do with legacy compatibility, or code inheritance. (If you look at what Theo says about this specific OpenSSL bug, it arises because the OpenSSL team wrote their own allocator that doesn't use malloc() protection bits because those are not compatible across some platforms.) As the old saying goes: in science, we advance by standing on each others' shoulders; in software, we stand on each others' toes.
    - arethuza 13y ago
robin_reala 13y ago
So what are the options then if OpenSSL isn’t fit for purpose? Is it possible to move wholesale to a different project? Are any of them trying to ease migration over from OpenSSL to themselves?
- antocv 13y ago
  GnuTLS exists. And NSS in mozilla. Probably others too.
  - reidrac 13y ago
    cURL makes a nice comparison: http://curl.haxx.se/docs/ssl-compared.html http://curl.haxx.se/docs/ssl-compared.html GnuTLS had its own problems recently (see: http://www.gnutls.org/security.html http://www.gnutls.org/security.html), and regarding NSS... I couldn't find a proper public "security" page for it (eg, release notes for 3.16 point to CVE-2014-1492; but the link to the bugzilla issue is not public), so I don't know. Obviously a good security record doesn't imply things like a good code base, good practices, etc; (although it could).
    - recentdarkness 13y ago
      Regarding the NSS CVE-2014-1492: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1492 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-14... Quote: "The cert_TestHostName function in lib/certdb/certdb.c in the certificate-checking implementation in Mozilla Network Security Services (NSS) before 3.16 accepts a wildcard character that is embedded in an internationalized domain name's U-label, which might allow man-in-the-middle attackers to spoof SSL servers via a crafted certificate." Edit: Added Quote
      - reidrac 13y ago
        Thanks, I can look for a CVE myself ;) My point is that having a proper security page is a good practice and I really appreciate it as user.
    - 13y ago
Orangeair 13y ago
I echo what someone said earlier on another OpenSSL thread: security applications should not be handling their own memory at a low level like this. It's just too easy to mess up, and it often leads to the worst vulnerabilities.
jokoon 13y ago
yeah, why not rename this to NSASSL
greatsuccess 13y ago
If this post is truth, its a shocking condemnation of open source custodianship of security software. Im shocked, dismayed and disheartened. OpenSSL if still maintained by these folks should be wholesale deprecated in all versions and forever more. Over and out.
bhouston 13y ago
Has anyone started a rumor yet that the NSA infiltrated the OpenSSL development team to make OpenSSL ineffective and full of holes? The convoluted code of OpenSSL alone (from yesterday's Hackernews post) seems like a great way to add all sorts of "bugs" inadvertent or not. Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA. Remember that the Snowden docs says that the NSA can break SSL/TLS/https/VPN, etc., but we do not know the full details: http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html http://blog.cryptographyengineering.com/2013/12/how-does-nsa... But the one thing all of these technologies (SSL,TLS,https,VPNs) have in common is usually OpenSSL.
- simias 13y ago
  Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy. That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible. Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.
  - bhouston 13y ago
    > no need for tinfoil hat theories Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA. For example of NSA efforts in related areas (which I figured you would already know): http://www.cnbc.com/id/101301261 http://www.cnbc.com/id/101301261 http://nation.time.com/2013/11/04/google-shocked-the-nsa-hacked-its-servers/ http://nation.time.com/2013/11/04/google-shocked-the-nsa-hac... http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331 http://www.reuters.com/article/2014/03/31/us-usa-security-ns... https://www.techdirt.com/articles/20130909/11430124454/john-gilmore-how-nsa-sabotaged-key-security-standard.shtml https://www.techdirt.com/articles/20130909/11430124454/john-...
maxbucknell 13y ago
If there are so many problems with OpenSSL, why are there no alternatives that are readily available and anywhere near as functional? The whole internet runs OpenSSL, but why hasn't anyone tried to do something different? I know it's complicated, but if a few big companies really chose to put some muscle behind it, it could happen, right?
- davidw 13y ago
  This sums up some of the difficulties with the production of open source software: https://en.wikipedia.org/wiki/Public_good https://en.wikipedia.org/wiki/Public_good
  - icebraining 13y ago
    If this is a consequence of the difficulties with the production of open source software, does that mean there are much more secure proprietary implementations of SSL/TLS? Which ones?
    - davidw 13y ago
      A quick search with Google reveals various commercial SSL implementations. I have no idea how good they are. Most people probably think openssl is good enough and are not willing to pay for something else.
  - ef4 13y ago
    That really doesn't illuminate anything, because you'd also need to explain why open source has been spectacularly successful generating other public goods (linux and others). The economics of open source are pretty clear at this point. The software industry spends a lot of money supporting open source, because it's in their own interest to do so -- it's cheaper to share the costs than to build your own infrastructure from scratch every time, when the infrastructure is not part of your competitive advantage. This particular bug was found by people that Google pays to audit open source code all day, in an effort to improve said code.
supersnap 13y ago
This is pretty much proof that open source fails to maintain security software in a responsible way. Look kids ssl is not that hard to implement. Time to let the cargo cult go have a campfire and sing songs. This is too important to leave to lazy paid for nothing programmers who want to write lazy ass c code after too many beers. Grow up
- throwaway7767 13y ago
  I know I'm replying to a troll, but... you have been following the news, right? Would you rather have us use the backdoored RSA bSAFE library? That was developed by paid professionals, who by your logic should be the paragons of competence. All software has bugs.
- goldenkey 13y ago
  I guess we should just let you code it in Enterprise java and pay you dividends.. Get a hold of yourself - most open source is actually funded by large companies in the first place. And being drunk has nothing to do with bad code, I for one code better when inebriated. Your straw man banter doesn't need to be on HN.
  - supersnap 13y ago
    Java has nothing to do with it. Untrusted input is untrusted input. Any moron can figure that out. OpenSSL, no code review, no tests, and bad code. Why are we responsible for finding these bugs? And no just FYI my code has no bugs
- linuxydave 13y ago
  0/10 Try harder next time
deleted 13y ago
[deleted]
stiff 13y ago
It is surprising that a project that is quite mission critical is completely at the bottom of the scale when it comes to how much the development process is oriented toward reliability. There are no systematic unit tests, no systematic documentation, the best you get is a bunch of disorganized integration tests, so it is not even at the level you would expect for a decently maintained business project: https://github.com/openssl/openssl https://github.com/openssl/openssl Perhaps the open source model of development is just not very good for software of this kind. Of course it's good that the source is open for everyone to look and potentially contribute, but without funding and without having a real process and a full time team it seems to me it is hard to get the level of quality required. I also wonder how much in the end the big institutions care about this stuff. Intel hires a bunch of guys to do formal models of their processors to ensure bugs aren't shipped to millions of customers, why is nobody funding a formally specified version of SSL? For other mission critical systems, like what goes into spacecrafts, or hospitals, or gets developed in the military there are rigorous processes in use to prevent stupid mistakes, so it's somewhat disappointing that the major infrastructure pieces don't receive this kind of treatment.
- zmguy 13y ago
  Stiff, I think you answered your own question. Intel HIRES them, open source projects don't generally hire people. They sit around and wait for someone to contribute. Are you truly surprised that a volunteer created software is not as rigorously tested as software created by Intel?
  - icebraining 13y ago
    Being FOSS doesn't have to mean relying on volunteers. Linux is mostly written by paid developers; why isn't OpenSSL, considering its reach in the commercial world?
    - hrjet 13y ago
      Slightly off topic, but do you know whether the paid developers of Linux work on the core kernel, or on device drivers?
gpvos 13y ago
OpenSSL was derived from SSLeay. Was SSLeay already that bad?
- rdl 13y ago
  Worse.
josteink 13y ago
I may be biased in that I have not written much C-code in years (decades?), but whenever I find a codebase covered in IFDEFs, I start assuming that every single new IFDEF introduces a new condition into the system which has not been properly nor recently tested, and that the software is horribly broken. For me, fixing software, is just as often removing IFDEFs together with unmaintained and broken code. It's IMO much better to be honest about "this isn't supported", than pretend you support something you don't. And this seems to be another one of those stories, coupled with a (bad?) case of NIH.
keithgabryelski 13y ago
the lesson: general and up-to-date understanding of larger systems is sometimes required to make the most innocuous changes. be a generalist keep up on current technologies
dimsumdumdum 13y ago
As soon as "open source" looks like a sloppy blow job everyone as in "idiot brogrammers", hey man, "I dont even work here", walks away and goes its SO hard...so HARD. Fuck you, you are a bunch of juvenlie misfits of the HIGHEST order who should not only never maintain security software, but get a real estate certification. Fuck off and die you 20 year old loser idiots
jimrandomh 13y ago
Here is the patch Theo is talking about: https://github.com/openssl/openssl/commit/8671b898609777c95aedf33743419a523874e6e8 https://github.com/openssl/openssl/commit/8671b898609777c95a...
mannykannot 13y ago
The 'many eyes' hypothesis has now been empirically tested.
- xuu 13y ago
  Many eyes worked in this case.. It just took a long time to find. The question now is what will it find next and when?
  - lttlrck 13y ago
    even with a comment in the code...
  - mannykannot 13y ago
    It worked in the sense that the lifeboats on the Titanic worked - they did, after all, save hundreds of lives. The combination of time and severity in this case should mean that we can move on from naive 'all bugs are shallow' dogma towards developing a more evidence-based approach to the verification of critical software.
- nosefrog 13y ago
  Yes, and that's how this bug was found.
  - awj 13y ago
    So "many eyes" means "paid researches at Google and a security firm"? Also, this bug was in place for what, two years? If the many eyes hypothesis has a two year lead time to find bugs this severe, we can stop talking about it because it's fucking worthless.
    - charonn0 13y ago
      > two years If that's how we're measuring things, then closed source isn't going to win either, e.g. [1]. [1]: http://www.computerworld.com/s/article/9146820/Microsoft_confirms_17_year_old_Windows_bug http://www.computerworld.com/s/article/9146820/Microsoft_con...
renox 13y ago
I find this remark quite funny from someone who is using C to write a "secure" OS..
- Sanddancer 13y ago
  Yes, C gives you a machine gun and no guard against your foot. However, the OpenBSD team also has a philosophy, and design measures, to ensure that said machine gun never gets anywhere near your foot. Given their security track record, I think they've done a pretty good job of such. Can you give an example of a "secure" OS not written in C so I can see what this mythical beast looks like?
  - tokenrove 13y ago
    SPIN is probably the most well-known example: http://en.wikipedia.org/wiki/SPIN_%28operating_system%29 http://en.wikipedia.org/wiki/SPIN_%28operating_system%29
deleted 13y ago
[deleted]
ScottBurson 13y ago
So what if someone tried to crowdfund a new implementation (or a thorough rewrite of OpenSSL, if that makes more sense). Could they raise something on the order of $1M? It seems like it would cost that much for, I'm guessing, three absolutely top developers for two years. Unlike a lot of crowdfunded projects, this one would not launch a business -- there's no additional revenue opportunity for the developers once it's completed -- so the amount would have to compensate them not just for their time but also for their opportunity cost. On the other hand, given the importance of TLS to the Internet, $1M seems less than trivial -- literally pocket change, if the cost were well distributed among the millions of websites using SSL. What do you think? Could it be done?

497 points by anon1385 13y ago

And why are we making excuses for a excuse me fucking idiot who wouldnt bounds check a goddamn len??? In SSL? What are we a bunch of pretentious fucking children who forgot how to code? Untrusted input HELL fucking LO!

bananas 13y ago

Great analysis. Theo is always up front on this sort of stuff which is commendable.

simias 13y ago
Could have done without the final line though, but I guess it's his equivalent of a signature...
- baq 13y ago
  theo's an asshole, but he's quite often right. i don't like his attitude too, but it has to be said that in this particular case, consequences have been - and/or will be - extraordinary.
  - Gigablah 13y ago
    "OpenSSL is not developed by a responsible team" is downright benign compared to "OpenSSL is written by monkeys".
  - caf 13y ago
    Well, really the consequences would have been virtually the same either way, since the number of OpenSSL deployments where the system malloc uses guard pages is a rounding error.
    - Sanddancer 13y ago
      Yes, but because of the caching malloc, the OpenBSD implementations are just as affected as the rest of the world's. Irresponsible software design sucks, plain and simple.
      - caf 13y ago
        It is a stretch to call this irresponsible. Is there any evidence that the OpenBSD people ever drew upstream's attention to this?
    - usefulcat 13y ago
      Not necessarily. It's probably still more likely that the bug would have been discovered sooner, even if only via a relatively small number of crashes.
- kzrdude 13y ago
  No, that's essential, that line is the message. A secure library should be defensive in coding style and implementation, not sloppy. It should have defaults that err on the safe side, not the fast side, if you have to choose.
  - simias 13y ago
    It's a massive open source project that's more than 15 years in the making and supports a massive range of architectures and ever-moving standards. Shit happens, we need to figure out how to make sure it won't happen again at this scale, there's really no need for name calling.
    - kryptiskt 13y ago
      We need to stop have such a fucking accepting attitude about sloppy engineering in security-critical code. People who don't want to be held to a high standard should get out of there and go do something that can't break the internet.
      - mattgreenrocks 13y ago
        This entire thread is eye-opening. It's as if open source gets a pass on almost everything related to quality because it's free and open. The unspoken belief is that a magic person will come along and fix everything in the indeterminate future. Also, the mantra: "all bugs are shallow." If you refuse to understand the reasons for engineering, conceptual integrity, and discipline in writing code that needs to be readable (read: dull and boring), then I don't know what to say.
      - simias 13y ago
        I'm not saying we should accept sloppy engineering in security-critical code, I'm saying that it's pointless to insult people who contribute to free open source projects from the outside. We want to incite more people to audit and contribute to these projects, not the other way around. Insult the engineering, not the engineers. Or, alternatively, don't insult and propose improvements.
- MrBuddyCasino 13y ago
  To quote Ted Dziuba: "Anyone who ever told you that swear words have no place in technical discussion is right. They're right, and sadly, they're part of the problem because they miss the point. The sterile word placement that's supposed to support an argument makes any true motivation indistinguishable from all the hired bullshit. [...] However, when someone starts swearing in technical discussion, showing emotion, that's a strong indicator that I'm about to receive wisdom. Wisdom is earned the hard way, and it is permanent, not like some statistically shaky performance benchmark that we'll all forget about next week." I feel the same - I'd rather have people feeling passionate about their work and use swear words, than work with polite non-personalities that don't give a fuck.
  - spacemanmatt 13y ago
    I absolutely depend on some swearing to draw a clear line between the factual presentation and everything else. I think this is why beer:30 and stepping away from the office with coworkers is important. People matter. The way software makes them feel matters. Code smell and related concerns are best conveyed in profoundly human ways. Fuck it. Say it like you mean it.
  - Tyrannosaurs 13y ago
    Swearing isn't required for passion. Martin Luthor King didn't have an (expletive of choice) dream, he just had a dream. There are plenty of people who care about their work and manage to express that without swearing. Similarly there are plenty of people who swear about stuff who may well be committed but it's highly questionable about what they're committed to and whether it's to the benefit of the project / team. If someone does swear (and as it goes, I'm fine with swearing for emphasis and swear way more than I feel I should) they need to be aware that some people find it offensive and that if they don't moderate their behaviour it may be taken very personally which can result in barriers between colleagues and / or low morale. You can choose to say that that's the person reacting's problem but if you do so you need to be aware of the price that comes with (that they're working in an environment with which they're not completely comfortable which is unlikely to get the best out of them). The alternative is that the swearer moderates themselves (with which they in turn may not be comfortable). Obviously the better you know your colleagues the more leeway you have. If you've built up trust and togetherness overtime you can get away with anything but even then you need to consider what happens when new people join the team. But ultimately this is about people and where it's about people there are no absolutes - what works for one group will be kryptonite for another.
- SixSigma 13y ago
  Theo is such a "character" that his "work" has been incorproated into the plan9 spin-off 9front as a theo (1) specific fortune file. http://man.cat-v.org/9front/1/fortune http://man.cat-v.org/9front/1/fortune
  - bananas 13y ago
    The mg implementation that ships with OpenBSD has a fair few insults in it as well under the command "theo": http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?rev=1.133 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?...
  - groovy2shoes 13y ago
    And here's the theo fortune file: https://plan9front.googlecode.com/hg/lib/theo https://plan9front.googlecode.com/hg/lib/theo
- rbanffy 13y ago
  You must be joking. "OpenSSL is not developed by a responsible team" is probably the most benign criticism Theo has ever issued. And he's quite right. This is a class of bug that should not exist or, at least, be restricted to the OSs where "malloc() performance is bad enough" to justify using their own implementation. Memory management is a non-trivial problem.
- mattgreenrocks 13y ago
  The lower you are on the stack, the more you need quality. And the more you need quality, the more likely you are to run into hackers with 'tough love' personalities, because they simply cannot tolerate poor excuses for code. How they express it is a reflection of their character, but they will let you know when you screw up. Theo was extremely tact given the enormous impact of this bug.
tjaerv 13y ago
For the benefit of those who don't know who he is: http://en.wikipedia.org/wiki/Theo_de_Raadt http://en.wikipedia.org/wiki/Theo_de_Raadt

btown 13y ago

This should be a case study about why people developing system-critical software shouldn't write their own memory allocators.

jwr 13y ago
At a first approximation, no one should write their own memory allocator. Just as no one should write their own garbage collector, and no one should write their own filesystem. All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.
- pwang 13y ago
  I disagree. These are complex to make robust, but they are not hard concepts. I think everyone should write their own GC, write a filesystem, and handle their own memory layer, at least once. Treating lower levels of the stack as "too complex, there be dragons, just write some Javascript that hits RESTful API for JSON" is a great way to ensure you never progress as a software dev or an engineer. I agree that reinventing the wheel poorly - without understanding geometry or physics - is a terrible idea. But I also think that we don't have enough people nowadays making toy wheels to learn about geometry and physics. For each of the things you mentioned, there are concrete and good reasons why they grow complexity: filesystems need to be robust to media corruption and power faults; memory allocators need to be highly tuned to OS and architecture memory layouts; GCs need to be optimized for the code patterns of the particular language they serve, as well as understand the same OS and hardware memory constraints as allocators. But much of the complexity of these layers is not intrinsic to the problem, and not related to the above. In fact, most of the complexity and bugs of production code at these layers have to do with legacy compatibility, or code inheritance. (If you look at what Theo says about this specific OpenSSL bug, it arises because the OpenSSL team wrote their own allocator that doesn't use malloc() protection bits because those are not compatible across some platforms.) As the old saying goes: in science, we advance by standing on each others' shoulders; in software, we stand on each others' toes.
  - arethuza 13y ago

robin_reala 13y ago

So what are the options then if OpenSSL isn’t fit for purpose? Is it possible to move wholesale to a different project? Are any of them trying to ease migration over from OpenSSL to themselves?

antocv 13y ago
GnuTLS exists. And NSS in mozilla. Probably others too.
- reidrac 13y ago
  cURL makes a nice comparison: http://curl.haxx.se/docs/ssl-compared.html http://curl.haxx.se/docs/ssl-compared.html GnuTLS had its own problems recently (see: http://www.gnutls.org/security.html http://www.gnutls.org/security.html), and regarding NSS... I couldn't find a proper public "security" page for it (eg, release notes for 3.16 point to CVE-2014-1492; but the link to the bugzilla issue is not public), so I don't know. Obviously a good security record doesn't imply things like a good code base, good practices, etc; (although it could).
  - recentdarkness 13y ago
    Regarding the NSS CVE-2014-1492: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1492 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-14... Quote: "The cert_TestHostName function in lib/certdb/certdb.c in the certificate-checking implementation in Mozilla Network Security Services (NSS) before 3.16 accepts a wildcard character that is embedded in an internationalized domain name's U-label, which might allow man-in-the-middle attackers to spoof SSL servers via a crafted certificate." Edit: Added Quote
    - reidrac 13y ago
      Thanks, I can look for a CVE myself ;) My point is that having a proper security page is a good practice and I really appreciate it as user.
  - 13y ago

Orangeair 13y ago

I echo what someone said earlier on another OpenSSL thread: security applications should not be handling their own memory at a low level like this. It's just too easy to mess up, and it often leads to the worst vulnerabilities.

jokoon 13y ago

yeah, why not rename this to NSASSL

greatsuccess 13y ago

If this post is truth, its a shocking condemnation of open source custodianship of security software. Im shocked, dismayed and disheartened. OpenSSL if still maintained by these folks should be wholesale deprecated in all versions and forever more. Over and out.

bhouston 13y ago

Has anyone started a rumor yet that the NSA infiltrated the OpenSSL development team to make OpenSSL ineffective and full of holes? The convoluted code of OpenSSL alone (from yesterday's Hackernews post) seems like a great way to add all sorts of "bugs" inadvertent or not. Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA. Remember that the Snowden docs says that the NSA can break SSL/TLS/https/VPN, etc., but we do not know the full details: http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html http://blog.cryptographyengineering.com/2013/12/how-does-nsa... But the one thing all of these technologies (SSL,TLS,https,VPNs) have in common is usually OpenSSL.

simias 13y ago
Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy. That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible. Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.
- bhouston 13y ago
  > no need for tinfoil hat theories Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA. For example of NSA efforts in related areas (which I figured you would already know): http://www.cnbc.com/id/101301261 http://www.cnbc.com/id/101301261 http://nation.time.com/2013/11/04/google-shocked-the-nsa-hacked-its-servers/ http://nation.time.com/2013/11/04/google-shocked-the-nsa-hac... http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331 http://www.reuters.com/article/2014/03/31/us-usa-security-ns... https://www.techdirt.com/articles/20130909/11430124454/john-gilmore-how-nsa-sabotaged-key-security-standard.shtml https://www.techdirt.com/articles/20130909/11430124454/john-...

maxbucknell 13y ago

If there are so many problems with OpenSSL, why are there no alternatives that are readily available and anywhere near as functional? The whole internet runs OpenSSL, but why hasn't anyone tried to do something different? I know it's complicated, but if a few big companies really chose to put some muscle behind it, it could happen, right?

davidw 13y ago
This sums up some of the difficulties with the production of open source software: https://en.wikipedia.org/wiki/Public_good https://en.wikipedia.org/wiki/Public_good
- icebraining 13y ago
  If this is a consequence of the difficulties with the production of open source software, does that mean there are much more secure proprietary implementations of SSL/TLS? Which ones?
  - davidw 13y ago
    A quick search with Google reveals various commercial SSL implementations. I have no idea how good they are. Most people probably think openssl is good enough and are not willing to pay for something else.
- ef4 13y ago
  That really doesn't illuminate anything, because you'd also need to explain why open source has been spectacularly successful generating other public goods (linux and others). The economics of open source are pretty clear at this point. The software industry spends a lot of money supporting open source, because it's in their own interest to do so -- it's cheaper to share the costs than to build your own infrastructure from scratch every time, when the infrastructure is not part of your competitive advantage. This particular bug was found by people that Google pays to audit open source code all day, in an effort to improve said code.

supersnap 13y ago

This is pretty much proof that open source fails to maintain security software in a responsible way. Look kids ssl is not that hard to implement. Time to let the cargo cult go have a campfire and sing songs. This is too important to leave to lazy paid for nothing programmers who want to write lazy ass c code after too many beers. Grow up

throwaway7767 13y ago
I know I'm replying to a troll, but... you have been following the news, right? Would you rather have us use the backdoored RSA bSAFE library? That was developed by paid professionals, who by your logic should be the paragons of competence. All software has bugs.
goldenkey 13y ago
I guess we should just let you code it in Enterprise java and pay you dividends.. Get a hold of yourself - most open source is actually funded by large companies in the first place. And being drunk has nothing to do with bad code, I for one code better when inebriated. Your straw man banter doesn't need to be on HN.
- supersnap 13y ago
  Java has nothing to do with it. Untrusted input is untrusted input. Any moron can figure that out. OpenSSL, no code review, no tests, and bad code. Why are we responsible for finding these bugs? And no just FYI my code has no bugs
linuxydave 13y ago
0/10 Try harder next time

deleted 13y ago

[deleted]

stiff 13y ago

It is surprising that a project that is quite mission critical is completely at the bottom of the scale when it comes to how much the development process is oriented toward reliability. There are no systematic unit tests, no systematic documentation, the best you get is a bunch of disorganized integration tests, so it is not even at the level you would expect for a decently maintained business project: https://github.com/openssl/openssl https://github.com/openssl/openssl Perhaps the open source model of development is just not very good for software of this kind. Of course it's good that the source is open for everyone to look and potentially contribute, but without funding and without having a real process and a full time team it seems to me it is hard to get the level of quality required. I also wonder how much in the end the big institutions care about this stuff. Intel hires a bunch of guys to do formal models of their processors to ensure bugs aren't shipped to millions of customers, why is nobody funding a formally specified version of SSL? For other mission critical systems, like what goes into spacecrafts, or hospitals, or gets developed in the military there are rigorous processes in use to prevent stupid mistakes, so it's somewhat disappointing that the major infrastructure pieces don't receive this kind of treatment.

zmguy 13y ago
Stiff, I think you answered your own question. Intel HIRES them, open source projects don't generally hire people. They sit around and wait for someone to contribute. Are you truly surprised that a volunteer created software is not as rigorously tested as software created by Intel?
- icebraining 13y ago
  Being FOSS doesn't have to mean relying on volunteers. Linux is mostly written by paid developers; why isn't OpenSSL, considering its reach in the commercial world?
  - hrjet 13y ago
    Slightly off topic, but do you know whether the paid developers of Linux work on the core kernel, or on device drivers?

gpvos 13y ago

OpenSSL was derived from SSLeay. Was SSLeay already that bad?

rdl 13y ago
Worse.

josteink 13y ago

I may be biased in that I have not written much C-code in years (decades?), but whenever I find a codebase covered in IFDEFs, I start assuming that every single new IFDEF introduces a new condition into the system which has not been properly nor recently tested, and that the software is horribly broken. For me, fixing software, is just as often removing IFDEFs together with unmaintained and broken code. It's IMO much better to be honest about "this isn't supported", than pretend you support something you don't. And this seems to be another one of those stories, coupled with a (bad?) case of NIH.

keithgabryelski 13y ago

the lesson: general and up-to-date understanding of larger systems is sometimes required to make the most innocuous changes. be a generalist keep up on current technologies

dimsumdumdum 13y ago

As soon as "open source" looks like a sloppy blow job everyone as in "idiot brogrammers", hey man, "I dont even work here", walks away and goes its SO hard...so HARD. Fuck you, you are a bunch of juvenlie misfits of the HIGHEST order who should not only never maintain security software, but get a real estate certification. Fuck off and die you 20 year old loser idiots

jimrandomh 13y ago

Here is the patch Theo is talking about: https://github.com/openssl/openssl/commit/8671b898609777c95aedf33743419a523874e6e8 https://github.com/openssl/openssl/commit/8671b898609777c95a...

mannykannot 13y ago

The 'many eyes' hypothesis has now been empirically tested.

xuu 13y ago
Many eyes worked in this case.. It just took a long time to find. The question now is what will it find next and when?
- lttlrck 13y ago
  even with a comment in the code...
- mannykannot 13y ago
  It worked in the sense that the lifeboats on the Titanic worked - they did, after all, save hundreds of lives. The combination of time and severity in this case should mean that we can move on from naive 'all bugs are shallow' dogma towards developing a more evidence-based approach to the verification of critical software.
nosefrog 13y ago
Yes, and that's how this bug was found.
- awj 13y ago
  So "many eyes" means "paid researches at Google and a security firm"? Also, this bug was in place for what, two years? If the many eyes hypothesis has a two year lead time to find bugs this severe, we can stop talking about it because it's fucking worthless.
  - charonn0 13y ago
    > two years If that's how we're measuring things, then closed source isn't going to win either, e.g. [1]. [1]: http://www.computerworld.com/s/article/9146820/Microsoft_confirms_17_year_old_Windows_bug http://www.computerworld.com/s/article/9146820/Microsoft_con...

renox 13y ago

I find this remark quite funny from someone who is using C to write a "secure" OS..

Sanddancer 13y ago
Yes, C gives you a machine gun and no guard against your foot. However, the OpenBSD team also has a philosophy, and design measures, to ensure that said machine gun never gets anywhere near your foot. Given their security track record, I think they've done a pretty good job of such. Can you give an example of a "secure" OS not written in C so I can see what this mythical beast looks like?
- tokenrove 13y ago
  SPIN is probably the most well-known example: http://en.wikipedia.org/wiki/SPIN_%28operating_system%29 http://en.wikipedia.org/wiki/SPIN_%28operating_system%29

deleted 13y ago

[deleted]

ScottBurson 13y ago

So what if someone tried to crowdfund a new implementation (or a thorough rewrite of OpenSSL, if that makes more sense). Could they raise something on the order of $1M? It seems like it would cost that much for, I'm guessing, three absolutely top developers for two years. Unlike a lot of crowdfunded projects, this one would not launch a business -- there's no additional revenue opportunity for the developers once it's completed -- so the amount would have to compensate them not just for their time but also for their opportunity cost. On the other hand, given the importance of TLS to the Internet, $1M seems less than trivial -- literally pocket change, if the cost were well distributed among the millions of websites using SSL. What do you think? Could it be done?