28 ms·
OpenSSL Security Advisory
- _jomo 10y agoThe relevant commit (fix): https://github.com/openssl/openssl/commit/e408c09bbf7c3057bda4b8d20bec1b3a7771c15b https://github.com/openssl/openssl/commit/e408c09bbf7c3057bd... Edit: This is only the commit for the HIGH severity CVE-2016-6304.
- 0x0 10y agoThat's just one of many commits related to today's advisory. https://security-tracker.debian.org/tracker/source-package/openssl https://security-tracker.debian.org/tracker/source-package/o... has a good overview of each issue with links to commits etc on each CVE entry.
- VeejayRampay 10y agoMy first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.
- deleted 10y ago[deleted]
- hannob 10y agoWhat never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact things as vulns. More severe stuff still happens, but I'm pretty positive there is a decline in severe issues.
- nine_k 10y agoExactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.
- bjourne 10y agoIt won't end with Rust either since it is so appealing and easy to jump into unsafe territory.
- mbrock 10y agoThis kind of resource DoS attack doesn't seem like it's directly related to safe/unsafe. I think you would be just as likely to forget to put a resource limit if you were writing in Haskell.
- danarmak 10y agoEasy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.
- bjourne 10y agoYou could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)
- easytiger 10y agoWhat never ends? Dramatic over reaction for the ske of internet prosthelytising
- barkingcat 10y agoWhy would it end? There is no perfect software if that's what you're looking for.
- cm3 10y agoShort answer: unlikely to end anytime soon, but likely that we start to focus on higher level bugs more than lower level issues. Long answer: If Unix and C hadn't won the fight in the 1980s like VHS did, we wouldn't deal with such low-level bugs. It took 30 years, but we're finally getting CPUs (like lowRISC) that were inspired by BS5000 or i960 and the languages to go with it are getting mainstream. To be fair, had we as an industry taken security more seriously decades ago, we would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production. We can extend 1960s kernel designs with all kinds of features, but without a coherent design it's impossible to provide the same assurance. This is why it's great that we have L4 descendants that incorporate a capability scheme and also support a multikernel scheme (ala Barrelfish) for making better use of a cluster of cpu cores.
- sitkack 10y agoWe can't burn the world down and remake it. These things WILL happen over time, the next generations definitely are focused on safety and correctness. 1 we need to remove unsafe-machismo for the landscape, vector that energy into correctness instead of living with danger. 2, we need to figure out how to partition, segment, wrap the unsafe legacy stuff into a safe operating regime. The single biggest win is if we could load a library in another process and make cross-process calls to it.
- ygjb-dupe 10y ago> The single biggest win is if we could load a library in another process and make cross-process calls to it. What? Setting aside the fact that this can already be done in numerous different ways on many platforms, how is this a win? It's hard enough for developers to write correct code, let alone maintaining the correctness of that code while loading and executing unknown code from other parties (see web browsers, and the last 20 years of security bugs related to plugins, extensions, addons, etc).
- sitkack 10y agoThe user should be able to load 3rd party libraries in out of process sandboxes, transparently for applications which weren't written with that in mind. I am not asking for new programmer features, new end user / sys admin features in the loader.
- adekok 10y agoI maintain a project (http://freeradius.org http://freeradius.org) which a similar amount of code, and (arguably) similar complexity. While we've had issues, they aren't as numerous as OpenSSL. And, the issues in the latest major version are negligible. Why? We have a requirement for code quality. The code can't just work, it has to make sense. The OpenSSL people don't seem to care about badly formatted and/or non-understandable code. All commits MUST build cleanly without warnings on multiple operating systems, and under multiple compilers. We have test cases for a large chunk of the code base. We scan all releases through three different static analysis tools. Security is important. We make it important because we care. I wish other projects would do the same.
- cortesoft 10y agoI would posit another reason you don't have as many issues; you don't have as many people trying to find them. I think it is pretty foolhardy to assume that just because security issues haven't been found means they don't exist.
- ultramancool 10y agoThere's definitely some truth to this, FreeRADIUS is just not that valuable of a target since not many people have RADIUS exposed to the world, however if you look at other highly valuable targets like OpenSSH, which is probably in the top 10 if not the most valuable target in the world, you see far fewer significant exploits. It's definitely possible to have better quality than OpenSSL and a lot of OpenSSL's issues are due to legacy code and what amount to experiments being run in production software.
- adekok 10y agoFor the record, the fixes for that CVE contain new CVEs. https://www.openssl.org/news/secadv/20160926.txt https://www.openssl.org/news/secadv/20160926.txt <sigh> No one can reasonably say that the practices of the OpenSSL programmers result in secure code. No one can reasonably say that lots of people examining it later for defects is a good idea. We have lots of legacy code in C. The only sane way to maintain it is tests: unit tests, functional tests, and static code analysis. > a lot of OpenSSL's issues are due to legacy code i.e. the OpenSSL people don't care to actively maintain / clean up their software. What a depressing statement to make.
- throwaway12344 10y agoIf you don't know what you're talking about, please refrain from commenting. It only proves your ignorance. In the Rails land (as your profile says you are), you wouldn't have these issues, and quite frankly these types of thing seem to be beyond you at this point. You're in no position to criticize the OpenSSL project.
- MichaelMoser123 10y agoif i understand correctly this one is relevant to certificate issuers that publish certificate revocation lists via the OCSP protocol; could be used for denial of service but not for hacking into the certificate issue, is that correct? Also most bugs in OpenSSL seem to be during renegotiation of protocol zzzz defined by some obscure RFC that nobody really understands how to implement, is that correct? Why can't they simplify these protocols, do we really need these fancy renegotiation features? Actually Daniel Bernstein says that over-complicating the protocols is a clever way to make sure that software infrastructure remains insecure. https://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf https://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf
- pfg 10y agoAIUI this affects the code that handles the TLS extension with which a client tells the server that it supports OCSP stapling, so any server with an affected openssl version would be vulnerable.
- AlyssaRowan 10y agoSimplifying the protocol, making it easier to analyse (and prove) and especially removing legacy things we know are troublesome is the main goal of the draft TLS 1.3: now already live and rolled out across CloudFlare and Chrome, and which removes such things as renegotiation, all non-AEAD ciphersuites, MD5, SHA-1, static RSA, and many of the other classic TLS bugbears which keep bearing interesting vulnerabilities. Which isn't to say the optional (but usefully fast) 0-RTT mode might not introduce a few more, for those lackadaisical devs who inevitably ignore all dire warnings and abuse it for non-idempotent requests like POSTs (or GETs that do something - bad idea!). But even if it's not how I would have designed it afresh (the Noise Protocol Framework from Trevor Perrin is how I would have designed a new connection protocol now) it's still a big improvement over previous TLS/SSL iterations and a drastic enough change it probably deserves to be called TLS 2.0.
- dijit 10y agoLuckily I moved everything to openbsd's libressl which is /mostly/ compatible. I wonder if this bug affects them, typically the HIGH's haven't[0] It really feels like every other week there is a bug in OpenSSL and after following along with the libressl blog I understand why- the code is an absolute mess[1] [0] http://undeadly.org/cgi?action=article&sid=20150319145126 http://undeadly.org/cgi?action=article&sid=20150319145126 [1] http://opensslrampage.org/page/49 http://opensslrampage.org/page/49
- pawadu 10y agoNot much seems to have happened in LibreSSL since the initial rage-sprint. For now, watch this spot: https://marc.info?l=libressl&r=1&b=201609&w=2 https://marc.info?l=libressl&r=1&b=201609&w=2
- parfe 10y ago>Not much seems to have happened in LibreSSL since the initial rage-sprint. Where did you get that impression? https://github.com/libressl-portable/openbsd/commits/master https://github.com/libressl-portable/openbsd/commits/master shows an actively developed project
- throwaway7767 10y agoThe interesting thing about LibreSSL is that it's got such a halo around it that people just assume it's not vulnerable to any OpenSSL bugs. Practically every OpenSSL bug posted here gets the standard "Luckily LibreSSL isn't affected by this kind of thing" response. On a couple of occasions I've taken the bait and linked to the LibreSSL source to show that the relevant bits are in fact not changed at all, so they were both vulnerable. Not saying LibreSSL isn't doing good stuff, I just wish people would actually check if it's affected before using any opportunity to jump on the let's-hate-on-openssl bandwagon. (I haven't looked into these bugs in the LibreSSL code since I don't have time for it right now, but I'm sure some message is forthcoming).
- OrpheanBeholder 10y ago
- Yuioup 10y agoIf it does not have a home page and a catchy name like "Heartbleed", then this bug does not exist.
- hannob 10y agoIt has a logo! http://security.360.cn/cve/CVE-2016-6304/ http://security.360.cn/cve/CVE-2016-6304/
- discreditable 10y agoThere's one in the advisory for CVE-2016-2183 - https://sweet32.info https://sweet32.info. I'm trying to track these sites, mainly for my own amusement: https://github.com/KeenRivals/Bugsite-Index https://github.com/KeenRivals/Bugsite-Index
- slavik81 10y agoThanks to you, my new favourite is http://backronym.fail http://backronym.fail
- turingbook 10y ago>This issue was reported to OpenSSL by Shi Lei (Gear Team,Qihoo 360 Inc.) A Chinese hacker
- rurban 10y agoNo. See https://en.wikipedia.org/wiki/Qihoo_360 https://en.wikipedia.org/wiki/Qihoo_360 A very popular chinese anti-virus company which fashions the US freemium model, with advertising on their homepage being the biggest revenue, and a market cap of $11.42B. Not a hacker.
- justinmayer 10y agoAs far as I can tell, patched OpenSSL packages for affected Debian/Ubuntu releases are not yet available. https://security-tracker.debian.org/tracker/CVE-2016-6304 https://security-tracker.debian.org/tracker/CVE-2016-6304 https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-6304.html https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...
- jaryd 10y agoYou'll typically see these come through USN (Ubuntu Security Notices) as they're available. http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/
- beezle 10y agoWonderful. Glad I recently added OCSP support to servers. Arg! So does this affect TLSv1.2 only servers that do NOT support client renegotiation of any type?
- deweerdt 10y agoThis is the only claim that i've found saying that throttling (or disabling, for that matter) renegotiation would prevent the issue: https://twitter.com/Unreal_IRCd/status/778975019829489664 https://twitter.com/Unreal_IRCd/status/778975019829489664 The advisory makes it sound like that would be the case, but it would have been great if that was explicitly stated.
- robryk 10y agoWhy is the severity of the first vulnerability high? It allows a denial of service on the server's side by a client and nothing else. The second vulnerability seems to be very similar in severity, except that it can be used both against clients and servers, and yet it is of just moderate severity. What am I missing?
- adekok 10y agoPresumably because fewer applications use SSL_peek(). But yes, that issue is a serious problem, too.
- pdevr 10y ago>"Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default configuration [..]" In case anyone is using older versions, like we do in our production environment.
- cperciva 10y agoOK, now we can go ahead with FreeBSD 11.0-RELEASE. In my time as security officer, it was a rare and surprising occurrence when we didn't need to hold an upcoming release due to a pending OpenSSL advisory. It got to the point of the release engineer saying "I think we're ready to start the release builds tomorrow, any news from OpenSSL" and me replying "nothing yet, but I'm sure it will come" -- their timing was absolutely impeccable.
- astrodust 10y agoLibreSSL isn't up to speed yet? http://www.libressl.org http://www.libressl.org
- cperciva 10y agoIt certainly wasn't when I was Security Officer -- it didn't exist yet. I believe some people are working on bringing libressl into the FreeBSD base system, but there are some challenges; for example, FreeBSD supports stable branches for 5 years, while libressl follows OpenBSD's "break everything once a year" model.
- tedunangst 10y agoCould be biased, but I think we're more careful about bundling breaking changes in security patches though.
- cperciva 10y agoIf you try at all, then you're trying harder than OpenSSL. But that doesn't necessarily help if there has been so much code churn over the past 5 years that we can't figure out how or if we should apply the security patch.
- nodesocket 10y agoDoes not appear that SSL Labs (https://www.ssllabs.com/ssltest https://www.ssllabs.com/ssltest) tests for this exploit (CVE-2016-6304) yet. Anybody have instruction on how to test your server?