10 ms·

OpenSSL Security Advisory

283 points by runesoerensen 11y ago

mykhal 11y ago
Changes between 1.0.2c and 1.0.2d [9 Jul 2015] *) Alternate chains certificate forgery During certificate verfification, OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue was reported to OpenSSL by Adam Langley/David Benjamin (Google/BoringSSL). [Matt Caswell]
jarofgreen 11y ago
In case it's slow: OpenSSL Security Advisory [9 Jul 2015] ======================================= Alternative chains certificate forgery (CVE-2015-1793) ====================================================== Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html https://www.openssl.org/about/secpolicy.html
pilif 11y ago
> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be broken. Additionally, your callers will start to depend on your behaviour and suddenly you have what amounts to two separate implementations in your code. I learned that while blowing up (though don't call exit if you're a library. Please.) is initially annoying for callers, in the end, it will be better for you and your callers because code will be testable, correct and more secure (because there's less of it)
- kaeso 11y ago
  This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
  - stonemetal 11y ago
    I wouldn't say he is wrong, so much as you just need a dev mode where strict acceptance is the order of the day. You need people to learn to produce correct results, but still be resilient in the field.
    - parasubvert 11y ago
      This x10. Strict Dev modes are helpful. Strict everywhere just means that there will only be one successful implementation that everyone uses.
  - parasubvert 11y ago
    The problem isnt so simple in the world of large scale protocol design - standards are rarely successful when imposed, they're usually adopted as a reflection of the current implementations. And when you're dealing with multiple independent implementations the variance can be subtle, and the standards often are broken or at best under-specified at first. When dealing with integration among many parties, there is tremendous pressure to just "make it work". The web arguably is an example of this - the standards were post-facto representations of what's already implemented. Of course we are all hating the long term implications on our codebases , but "let's force everyone to do it one way through strict behaviour" seems to discount the social dynamics of interoperability. Moving away from Postel's principle in production will not lead to successful open and interoperable implementations, it will rather trend towards towards one single implementation , likely open source, that is shared and tweaked by all. That has some positive (interop!) and negative implications (limited ability to innovate / dragged down into programmer religions, etc).
Mojah 11y ago
This appears to be the actual code fix: https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6904d3a9aa09c5db6cefd0d https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6... Some more details & patching guide here: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/
- edwintorok 11y ago
  This is relevant too: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365...
eatonphil 11y ago
I've got a few sites using OpenSSL certs; do I need to do anything?
- nkozyra 11y ago
  SSL does not necessarily mean OpenSSL is involved, but it could. Follow the advisories.
- marcosdumay 11y ago
  Unless you are using client side certificates, this one is not your problem. But everybody must upgrade their browsers ASAP.
  - calpaterson 11y ago
    Is that right? My reading of it is that this affects all cases where you verify the certificate
    - ultramancool 11y ago
      Yes and most web servers do not use client certificates and do not have any need to validate certificates.
      - tedunangst 11y ago
        Any proxy or loadbalancer that uses https should validate certificates, however.
      - calpaterson 11y ago
        Yes but in practice a lot of them do, for example, when they download a library from PyPI or rubygems...? Unless we're talking just about when people use client certificates as authentication?
        ultramancool 11y ago
runesoerensen 11y ago
It's worth noting that only releases since June 2015 are affected
- marcosdumay 11y ago
  That means, only releases that have no other known high severity bugs...
0x0 11y ago
Debian stable/oldstable is not affected. Only in unstable: https://security-tracker.debian.org/tracker/CVE-2015-1793 https://security-tracker.debian.org/tracker/CVE-2015-1793
- therealmarv 11y ago
  Well on Ubuntu I see nothing yet... http://www.ubuntu.com/usn/trusty/ http://www.ubuntu.com/usn/trusty/ I do not know if this is good or bad :(
  - mugsie 11y ago
    http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-1793.html http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...
    - therealmarv 11y ago
      Thanks for the link +1
mykhal 11y ago
from test/verify_extra_test.c: Test for CVE-2015-1793 (Alternate Chains Certificate Forgery) Chain is as follows: rootCA (self-signed) | interCA | subinterCA subinterCA (self-signed) | | leaf ------------------ | bad rootCA, interCA, subinterCA, subinterCA (ss) all have CA=TRUE leaf and bad have CA=FALSE subinterCA and subinterCA (ss) have the same subject name and keys interCA (but not rootCA) and subinterCA (ss) are in the trusted store (roots.pem) leaf and subinterCA are in the untrusted list (untrusted.pem) bad is the certificate being verified (bad.pem) Versions vulnerable to CVE-2015-1793 will fail to detect that leaf has CA=FALSE, and will therefore incorrectly verify bad
- mvanotti 11y ago
  So, bad certificate HAS to be signed by leaf certificate, and leaf certificate HAS to be trusted. (And you need two CAs with the same keys) openssl would accept certs that have been issued by a non-ca cert (which is trusted). So if you have control over the leaf cert, you can just use it for contacting openssl. If you don't have control over the leaf cert, you can't issue a bad cert. Am I missing something?
  - caf 11y ago
    The leaf cert is signed for evil-bastard.net, but the "bad" cert can be for mail.google.com.
sneak 11y ago
agl++;
- namtrac 11y ago
  https://twitter.com/agl__/status/619129579580469248 https://twitter.com/agl__/status/619129579580469248
jgrahamc 11y ago
Interesting part is that the bug was introduced in the latest versions and has been fixed by the person who inserted it :-) Bug added: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae27f2463ebe4a50bb840fa5 https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae... Bug removed: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365... Although that's just the committer: https://twitter.com/agl__/status/619129579580469248 https://twitter.com/agl__/status/619129579580469248
- amirmc 11y ago
  Yep, that the bug was recently introduced was implied from the notice they put out. For interest, the line that was fixed from the first commit is: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae27f2463ebe4a50bb840fa5#diff-06463ef55f4d9d5411a243b09e66c06fR385 https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae...
- acqq 11y ago
  Looking at the changes that introduced the bug, it's obvious that the nature of the problems being solved is too complex for the changes to be only "visually" reviewed. There must be enough external tests to "uncover" the potential issues. And the tests of course can have the bugs too, not covering what needed to be covered. That's why for so sensitive code the testers should be the best programmers with additional preference to search for the combinations that don't work as intended.
  - thrownaway2424 11y ago
    You're confused. This thread is about OpenSSL. OpenSSL doesn't have tests.
    - acqq 11y ago
      Even if doesn't have tests at the moment that doesn't mean that it should always remain that way.
    - deleted 11y ago
hackerhamza 11y ago
am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number
Sharker 11y ago
It´s for old version. For example actual debian not affected. https://security-tracker.debian.org/tracker/CVE-2015-1793 https://security-tracker.debian.org/tracker/CVE-2015-1793
- mykhal 11y ago
  s/old/recent/
- tP5n 11y ago
  'actual debian' made me smile .) all quibbling aside, most people would probably need an explanation to understand your post, as the recent version of debian is indeed affected, as in debian-unstable (sid)'s openssl.
hackerhamza 11y ago
am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number
mugsie 11y ago
Seems to be OK for anyone using non beta versions of Ubuntu as well: http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-1793.html http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...
hackerhamza 11y ago
am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number
d_theorist 11y ago
So, updating server side OpenSSL will not close this vulnerability (for servers offering https-protected websites)? Is that correct? If I understand the advisory correctly then this means that somebody could set up a webserver with a specially-crafted certificate and pretend to be somebody else, assuming that the client is running a vulnerable version of OpenSSL. Is that right? I wish they would write these advisories in a slightly more helpful fashion.
- tedunangst 11y ago
  Yes, this is a client side bug.
  - zwp 11y ago
    And servers that are authenticating client certs? (clearly there are far fewer of those around but they do exist)
    - tedunangst 11y ago
      Good point.
acqq 11y ago
We probably don't need to worry this time: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ "The vulnerability appears to exist only in OpenSSL releases that happened in June 2015 and later. That leaves a lot of Linux distributions relatively safe, since they haven't gotten an OpenSSL update in a while. Red Hat, CentOS and Ubuntu appear to be entirely unaffected by this vulnerability, since they had no OpenSSL updates since June 2015."
- drzaiusapelord 11y ago
  Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcomes for such critical libraries.
  - Alupis 11y ago
    You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it being introduced, realized, and fixed. A lot of folks like to lean on LibreSSL and cite "supposed problems" with OpenSSL, just as you have done now. This is a naive approach -- LibreSSL took OpenSSL, cannibalized and gutted it, and all sorts of new, untested, un-vetted code injected. OpenSSL was written largely by crypto specialists, where LibreSSL is mostly a bunch of grumbling developers, with little to no prior crypto experience. There's a reason the world is not jumping on LibreSSL just yet. There's a reason foundations outside of the LibreSSL home (OpenBSD) such as the Core Infrastructure Foundation have not backed it -- it's simply not ready, is very unproven, and won't be for a long, long time, if ever. Give OpenSSL a break. It works far better than nay-sayers want to let on, and has done so for almost 2 decades.
tomjen3 11y ago
How is it that we still depend on something so broken?
- joosters 11y ago
  The world awaits your perfect unbroken code...
- valarauca1 11y ago
  If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. If not, submit patches. An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitters.
  - ctz 11y ago
    The bit you don't cover is where you repeatedly submit patches (in my case, for example, to fix documentation and improve testing) which are ignored.
    - Alupis 11y ago
      This is not true anymore. At the time, OpenSSL had really a single maintainer, and was only receiving $2,000 a year in "donations". Not exactly something to keep someone working full time on the project with. A lot of that has now changed with the Core Infrastructure Initiative.
      - richm44 11y ago
        I do agree the situation is now better, but personally I've still found contributing to be a lot harder than it should be even for trivial fixes.
  - itistoday2 11y ago
    > If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. Here you go! https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-tls
ck2 11y ago
Nothing I can find in yum for CentOS 6 or 7
- jlgaddis 11y ago
  They aren't affected.
arenaninja 11y ago
Well this isn't how I wanted to start my morning
aninteger 11y ago
Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.
- dozzie 11y ago
  Because despite bug history of OpenSSL, nothing proved to be more reliable to this moment.
  - glass- 11y ago
    > nothing proved to be more reliable to this moment. Huh? Of the 22 vulnerabilities OpenSSL has disclosed since March (4 high severity, 14 moderate, 4 low), LibreSSL has been vulnerable to 8 (0 high, 6 moderate, 2 low). References: March: https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2 https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2 June: https://marc.info/?l=openbsd-announce&m=143406498020131&w=2 https://marc.info/?l=openbsd-announce&m=143406498020131&w=2 Today: https://marc.info/?l=openbsd-tech&m=143645910727507&w=2 https://marc.info/?l=openbsd-tech&m=143645910727507&w=2
    - dozzie 11y ago
      And how long is LibreSSL on the market? A year? It's hard to call it proof. It's easy to point intervals longer than whole LibreSSL lifetime with no security bugs in OpenSSL.
      - jandrese 11y ago
        LibreSSL is a cleanup of the OpenSSL base. They started with OpenSSL and worked from there. They have mostly deleted code, not added it, so they shouldn't be adding many new vulerabilities. On top of this, it is being written by the OpenBSD/OpenSSH people, who have a good history with writing secure software.
        dozzie 11y ago
coolowencool 11y ago
"No Red Hat products are affected by this flaw (CVE-2015-1793), so no actions need to be performed to fix or mitigate this issue in any way." https://access.redhat.com/solutions/1523323 https://access.redhat.com/solutions/1523323
- batou 11y ago
  Well there goes my long laborious afternoon of sysadmin work that I wasn't looking forward to! :-)
ericfrederich 11y ago
At first I thought this was the result of that Hacking Team dump, but it seems this was reported prior to that.
dwcmpfrt 11y ago
Did these changes (and subsequent fixes) get into libressl as well?
0x0 11y ago
This sounds really familiar to the old IE bug that didn't check the CA flag - http://www.thoughtcrime.org/ie-ssl-chain.txt http://www.thoughtcrime.org/ie-ssl-chain.txt
judemelancon 11y ago
I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug. Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files suggests the function length matches actual practice elsewhere, too.
- ajross 11y ago
  You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard idioms.
  - ectoplasm 11y ago
    The use of shorthand names like that is a strong indication that the variables don't need to be live for ~319 lines. If you reduce the live range of your variables, you reduce the complexity of your function. Less complex functions are less likely to have bugs and are easier to diagnose when they do.
    - jfoster 11y ago
      Good points, but if you are able to do that, doesn't it suggest the function could easily be split into multiple, more specific functions?
      - ectoplasm 11y ago
        Yes, of course, it's just the first step. In fact you'd probably need to introduce a couple more variables. For example, i gets defined three times: i = sk_X509_num(ctx->chain); i = check_trust(ctx); i = X509_chain_check_suiteb(&ctx->error_depth, NULL, ctx->chain, ctx->param->flags); What a mess. I would probably start by moving towards a module / class for all the functions that take either an X509_STORE_CTX *ctx pointer or something accessed through ctx.
kfreds 11y ago
The latest version (2.3.7) of the official OpenVPN client is vulnerable, as is Tunnelblick for OSX. No fix has been published yet. The OpenVPN clients for Android and iOS are not affected. See https://mullvad.net/en/v2/news https://mullvad.net/en/v2/news for more details.
- namtrac 11y ago
  OpenVPN already updated: http://article.gmane.org/gmane.network.openvpn.devel/9900 http://article.gmane.org/gmane.network.openvpn.devel/9900
- syzzer 11y ago
  Note that this is specifically OpenVPN on Windows, since the Windows installers ship with their own openssl dll (and as already said by the other commenter, a new installer was made available around the time of your post). All other platforms simply use the system library.
ca98am79 11y ago
AWS response: http://aws.amazon.com/security/security-bulletins/openssl-security-advisory---july-2015/ http://aws.amazon.com/security/security-bulletins/openssl-se...
- clebio 11y ago
  Welp, you saved me some work today! I was considering using the `ec2.py` script from Vagrant's dynamic inventory docs and then running SSH command execution over all our instances to upgrade the packages for both Ubuntu and AWS AMIs (yum), just to be safe. Guess I don't need to after all!
benmmurphy 11y ago
An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method (https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-L81 https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it. in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072 https://twitter.com/benmmurphy/status/613733887211139072) 'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.' and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this: RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE | V VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set) | V EVIL CERTIFICATE SIGNED BY PREVIOUS CERT
- yuhong 11y ago
  AFAIK the Baseline Requirements don't allow it but old certs that are not expired may still exist. It was one of the reasons why the e-Guven root was removed from Mozilla.
api 11y ago
A lot of these SSL vulnerabilities show that complexity is an inherently bad thing for security. In general, bugs in a system are exponentially not linearly proportional to system complexity. With security that means that the addition of a feature, option, or extension to the security layer of a system exponentially decreases its trustworthiness.
mrmondo 11y ago
Good work on finding and fixing the bug to those involved. I don't think this is said often enough.

283 points by runesoerensen 11y ago

Changes between 1.0.2c and 1.0.2d [9 Jul 2015] *) Alternate chains certificate forgery During certificate verfification, OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue was reported to OpenSSL by Adam Langley/David Benjamin (Google/BoringSSL). [Matt Caswell]

jarofgreen 11y ago

In case it's slow: OpenSSL Security Advisory [9 Jul 2015] ======================================= Alternative chains certificate forgery (CVE-2015-1793) ====================================================== Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html https://www.openssl.org/about/secpolicy.html

pilif 11y ago

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be broken. Additionally, your callers will start to depend on your behaviour and suddenly you have what amounts to two separate implementations in your code. I learned that while blowing up (though don't call exit if you're a library. Please.) is initially annoying for callers, in the end, it will be better for you and your callers because code will be testable, correct and more secure (because there's less of it)

kaeso 11y ago
This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
- stonemetal 11y ago
  I wouldn't say he is wrong, so much as you just need a dev mode where strict acceptance is the order of the day. You need people to learn to produce correct results, but still be resilient in the field.
  - parasubvert 11y ago
    This x10. Strict Dev modes are helpful. Strict everywhere just means that there will only be one successful implementation that everyone uses.
- parasubvert 11y ago
  The problem isnt so simple in the world of large scale protocol design - standards are rarely successful when imposed, they're usually adopted as a reflection of the current implementations. And when you're dealing with multiple independent implementations the variance can be subtle, and the standards often are broken or at best under-specified at first. When dealing with integration among many parties, there is tremendous pressure to just "make it work". The web arguably is an example of this - the standards were post-facto representations of what's already implemented. Of course we are all hating the long term implications on our codebases , but "let's force everyone to do it one way through strict behaviour" seems to discount the social dynamics of interoperability. Moving away from Postel's principle in production will not lead to successful open and interoperable implementations, it will rather trend towards towards one single implementation , likely open source, that is shared and tweaked by all. That has some positive (interop!) and negative implications (limited ability to innovate / dragged down into programmer religions, etc).

Mojah 11y ago

This appears to be the actual code fix: https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6904d3a9aa09c5db6cefd0d https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6... Some more details & patching guide here: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/

edwintorok 11y ago
This is relevant too: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365...

eatonphil 11y ago

I've got a few sites using OpenSSL certs; do I need to do anything?

nkozyra 11y ago
SSL does not necessarily mean OpenSSL is involved, but it could. Follow the advisories.
marcosdumay 11y ago
Unless you are using client side certificates, this one is not your problem. But everybody must upgrade their browsers ASAP.
- calpaterson 11y ago
  Is that right? My reading of it is that this affects all cases where you verify the certificate
  - ultramancool 11y ago
    Yes and most web servers do not use client certificates and do not have any need to validate certificates.
    - tedunangst 11y ago
      Any proxy or loadbalancer that uses https should validate certificates, however.
    - calpaterson 11y ago
      Yes but in practice a lot of them do, for example, when they download a library from PyPI or rubygems...? Unless we're talking just about when people use client certificates as authentication?
      - ultramancool 11y ago

runesoerensen 11y ago

It's worth noting that only releases since June 2015 are affected

marcosdumay 11y ago
That means, only releases that have no other known high severity bugs...

0x0 11y ago

Debian stable/oldstable is not affected. Only in unstable: https://security-tracker.debian.org/tracker/CVE-2015-1793 https://security-tracker.debian.org/tracker/CVE-2015-1793

therealmarv 11y ago
Well on Ubuntu I see nothing yet... http://www.ubuntu.com/usn/trusty/ http://www.ubuntu.com/usn/trusty/ I do not know if this is good or bad :(
- mugsie 11y ago
  http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-1793.html http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...
  - therealmarv 11y ago
    Thanks for the link +1

mykhal 11y ago

from test/verify_extra_test.c: Test for CVE-2015-1793 (Alternate Chains Certificate Forgery) Chain is as follows: rootCA (self-signed) | interCA | subinterCA subinterCA (self-signed) | | leaf ------------------ | bad rootCA, interCA, subinterCA, subinterCA (ss) all have CA=TRUE leaf and bad have CA=FALSE subinterCA and subinterCA (ss) have the same subject name and keys interCA (but not rootCA) and subinterCA (ss) are in the trusted store (roots.pem) leaf and subinterCA are in the untrusted list (untrusted.pem) bad is the certificate being verified (bad.pem) Versions vulnerable to CVE-2015-1793 will fail to detect that leaf has CA=FALSE, and will therefore incorrectly verify bad

mvanotti 11y ago
So, bad certificate HAS to be signed by leaf certificate, and leaf certificate HAS to be trusted. (And you need two CAs with the same keys) openssl would accept certs that have been issued by a non-ca cert (which is trusted). So if you have control over the leaf cert, you can just use it for contacting openssl. If you don't have control over the leaf cert, you can't issue a bad cert. Am I missing something?
- caf 11y ago
  The leaf cert is signed for evil-bastard.net, but the "bad" cert can be for mail.google.com.

sneak 11y ago

agl++;

namtrac 11y ago
https://twitter.com/agl__/status/619129579580469248 https://twitter.com/agl__/status/619129579580469248

jgrahamc 11y ago

Interesting part is that the bug was introduced in the latest versions and has been fixed by the person who inserted it :-) Bug added: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae27f2463ebe4a50bb840fa5 https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae... Bug removed: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365... Although that's just the committer: https://twitter.com/agl__/status/619129579580469248 https://twitter.com/agl__/status/619129579580469248

amirmc 11y ago
Yep, that the bug was recently introduced was implied from the notice they put out. For interest, the line that was fixed from the first commit is: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae27f2463ebe4a50bb840fa5#diff-06463ef55f4d9d5411a243b09e66c06fR385 https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae...
acqq 11y ago
Looking at the changes that introduced the bug, it's obvious that the nature of the problems being solved is too complex for the changes to be only "visually" reviewed. There must be enough external tests to "uncover" the potential issues. And the tests of course can have the bugs too, not covering what needed to be covered. That's why for so sensitive code the testers should be the best programmers with additional preference to search for the combinations that don't work as intended.
- thrownaway2424 11y ago
  You're confused. This thread is about OpenSSL. OpenSSL doesn't have tests.
  - acqq 11y ago
    Even if doesn't have tests at the moment that doesn't mean that it should always remain that way.
  - deleted 11y ago

hackerhamza 11y ago

am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number

Sharker 11y ago

It´s for old version. For example actual debian not affected. https://security-tracker.debian.org/tracker/CVE-2015-1793 https://security-tracker.debian.org/tracker/CVE-2015-1793

mykhal 11y ago
s/old/recent/
tP5n 11y ago
'actual debian' made me smile .) all quibbling aside, most people would probably need an explanation to understand your post, as the recent version of debian is indeed affected, as in debian-unstable (sid)'s openssl.

hackerhamza 11y ago

am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number am a hacker looking for those who got old bank account in usa and canada td bank to load no upfront fee charge iload it we share it 5050 email me hamzaben.d@hackermail.com leave your phone number

mugsie 11y ago

Seems to be OK for anyone using non beta versions of Ubuntu as well: http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-1793.html http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...

hackerhamza 11y ago

d_theorist 11y ago

So, updating server side OpenSSL will not close this vulnerability (for servers offering https-protected websites)? Is that correct? If I understand the advisory correctly then this means that somebody could set up a webserver with a specially-crafted certificate and pretend to be somebody else, assuming that the client is running a vulnerable version of OpenSSL. Is that right? I wish they would write these advisories in a slightly more helpful fashion.

tedunangst 11y ago
Yes, this is a client side bug.
- zwp 11y ago
  And servers that are authenticating client certs? (clearly there are far fewer of those around but they do exist)
  - tedunangst 11y ago
    Good point.

acqq 11y ago

We probably don't need to worry this time: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ "The vulnerability appears to exist only in OpenSSL releases that happened in June 2015 and later. That leaves a lot of Linux distributions relatively safe, since they haven't gotten an OpenSSL update in a while. Red Hat, CentOS and Ubuntu appear to be entirely unaffected by this vulnerability, since they had no OpenSSL updates since June 2015."

drzaiusapelord 11y ago
Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcomes for such critical libraries.
- Alupis 11y ago
  You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it being introduced, realized, and fixed. A lot of folks like to lean on LibreSSL and cite "supposed problems" with OpenSSL, just as you have done now. This is a naive approach -- LibreSSL took OpenSSL, cannibalized and gutted it, and all sorts of new, untested, un-vetted code injected. OpenSSL was written largely by crypto specialists, where LibreSSL is mostly a bunch of grumbling developers, with little to no prior crypto experience. There's a reason the world is not jumping on LibreSSL just yet. There's a reason foundations outside of the LibreSSL home (OpenBSD) such as the Core Infrastructure Foundation have not backed it -- it's simply not ready, is very unproven, and won't be for a long, long time, if ever. Give OpenSSL a break. It works far better than nay-sayers want to let on, and has done so for almost 2 decades.

tomjen3 11y ago

How is it that we still depend on something so broken?

joosters 11y ago
The world awaits your perfect unbroken code...
valarauca1 11y ago
If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. If not, submit patches. An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitters.
- ctz 11y ago
  The bit you don't cover is where you repeatedly submit patches (in my case, for example, to fix documentation and improve testing) which are ignored.
  - Alupis 11y ago
    This is not true anymore. At the time, OpenSSL had really a single maintainer, and was only receiving $2,000 a year in "donations". Not exactly something to keep someone working full time on the project with. A lot of that has now changed with the Core Infrastructure Initiative.
    - richm44 11y ago
      I do agree the situation is now better, but personally I've still found contributing to be a lot harder than it should be even for trivial fixes.
- itistoday2 11y ago
  > If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. Here you go! https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-tls

ck2 11y ago

Nothing I can find in yum for CentOS 6 or 7

jlgaddis 11y ago
They aren't affected.

arenaninja 11y ago

Well this isn't how I wanted to start my morning

aninteger 11y ago

Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

dozzie 11y ago
Because despite bug history of OpenSSL, nothing proved to be more reliable to this moment.
- glass- 11y ago
  > nothing proved to be more reliable to this moment. Huh? Of the 22 vulnerabilities OpenSSL has disclosed since March (4 high severity, 14 moderate, 4 low), LibreSSL has been vulnerable to 8 (0 high, 6 moderate, 2 low). References: March: https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2 https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2 June: https://marc.info/?l=openbsd-announce&m=143406498020131&w=2 https://marc.info/?l=openbsd-announce&m=143406498020131&w=2 Today: https://marc.info/?l=openbsd-tech&m=143645910727507&w=2 https://marc.info/?l=openbsd-tech&m=143645910727507&w=2
  - dozzie 11y ago
    And how long is LibreSSL on the market? A year? It's hard to call it proof. It's easy to point intervals longer than whole LibreSSL lifetime with no security bugs in OpenSSL.
    - jandrese 11y ago
      LibreSSL is a cleanup of the OpenSSL base. They started with OpenSSL and worked from there. They have mostly deleted code, not added it, so they shouldn't be adding many new vulerabilities. On top of this, it is being written by the OpenBSD/OpenSSH people, who have a good history with writing secure software.
      - dozzie 11y ago

coolowencool 11y ago

"No Red Hat products are affected by this flaw (CVE-2015-1793), so no actions need to be performed to fix or mitigate this issue in any way." https://access.redhat.com/solutions/1523323 https://access.redhat.com/solutions/1523323

batou 11y ago
Well there goes my long laborious afternoon of sysadmin work that I wasn't looking forward to! :-)

ericfrederich 11y ago

At first I thought this was the result of that Hacking Team dump, but it seems this was reported prior to that.

dwcmpfrt 11y ago

Did these changes (and subsequent fixes) get into libressl as well?

0x0 11y ago

This sounds really familiar to the old IE bug that didn't check the CA flag - http://www.thoughtcrime.org/ie-ssl-chain.txt http://www.thoughtcrime.org/ie-ssl-chain.txt

judemelancon 11y ago

I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug. Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files suggests the function length matches actual practice elsewhere, too.

ajross 11y ago
You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard idioms.
- ectoplasm 11y ago
  The use of shorthand names like that is a strong indication that the variables don't need to be live for ~319 lines. If you reduce the live range of your variables, you reduce the complexity of your function. Less complex functions are less likely to have bugs and are easier to diagnose when they do.
  - jfoster 11y ago
    Good points, but if you are able to do that, doesn't it suggest the function could easily be split into multiple, more specific functions?
    - ectoplasm 11y ago
      Yes, of course, it's just the first step. In fact you'd probably need to introduce a couple more variables. For example, i gets defined three times: i = sk_X509_num(ctx->chain); i = check_trust(ctx); i = X509_chain_check_suiteb(&ctx->error_depth, NULL, ctx->chain, ctx->param->flags); What a mess. I would probably start by moving towards a module / class for all the functions that take either an X509_STORE_CTX *ctx pointer or something accessed through ctx.

kfreds 11y ago

The latest version (2.3.7) of the official OpenVPN client is vulnerable, as is Tunnelblick for OSX. No fix has been published yet. The OpenVPN clients for Android and iOS are not affected. See https://mullvad.net/en/v2/news https://mullvad.net/en/v2/news for more details.

namtrac 11y ago
OpenVPN already updated: http://article.gmane.org/gmane.network.openvpn.devel/9900 http://article.gmane.org/gmane.network.openvpn.devel/9900
syzzer 11y ago
Note that this is specifically OpenVPN on Windows, since the Windows installers ship with their own openssl dll (and as already said by the other commenter, a new installer was made available around the time of your post). All other platforms simply use the system library.

ca98am79 11y ago

AWS response: http://aws.amazon.com/security/security-bulletins/openssl-security-advisory---july-2015/ http://aws.amazon.com/security/security-bulletins/openssl-se...

clebio 11y ago
Welp, you saved me some work today! I was considering using the `ec2.py` script from Vagrant's dynamic inventory docs and then running SSH command execution over all our instances to upgrade the packages for both Ubuntu and AWS AMIs (yum), just to be safe. Guess I don't need to after all!

benmmurphy 11y ago

An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method (https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-L81 https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it. in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072 https://twitter.com/benmmurphy/status/613733887211139072) 'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.' and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this: RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE | V VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set) | V EVIL CERTIFICATE SIGNED BY PREVIOUS CERT

yuhong 11y ago
AFAIK the Baseline Requirements don't allow it but old certs that are not expired may still exist. It was one of the reasons why the e-Guven root was removed from Mozilla.

api 11y ago

A lot of these SSL vulnerabilities show that complexity is an inherently bad thing for security. In general, bugs in a system are exponentially not linearly proportional to system complexity. With security that means that the addition of a feature, option, or extension to the security layer of a system exponentially decreases its trustworthiness.

mrmondo 11y ago

Good work on finding and fixing the bug to those involved. I don't think this is said often enough.