7 ms·

OpenSSL Security Advisory

385 points by davidroetzel 12y ago

gamed 12y ago
The large volume of vulnerabilities coming out of OpenSSL are worrying, but it likely reflects the increased effort being put into auditing and fuzzing the code after Heartbleed. What is more worrying is the many other critical pieces of software that have nowhere near the level of scrutiny that OpenSSL is receiving currently.
- gtirloni 12y ago
  Yes, the current situation is (probably) bad. The Core Infrastructure Initiative is starting to address that: http://www.linuxfoundation.org/programs/core-infrastructure-initiative http://www.linuxfoundation.org/programs/core-infrastructure-...
- jacquesm 12y ago
  Searching for vulnerabilities is just like mining for gold: you go for the richest veins first and OpenSSL is deployed widely enough and in enough places where it really matters that it is currently a priority item. I guess until a couple of weeks ago OpenSSL was 'one of many other critical pieces of software that have nowhere near the level of scrutiny that WordPress (and I know you don't meant Wordpress) is receiving currently'. So we'll see a re-focusing on other software when people feel that either the OpenSSL well of exploits has at least temporarily dried up or when something else that is crucial breaks. But as long as vulnerabilities in OpenSSL are discovered at this rate it seems to be an effort well-spent, and we will all reap the benefit of that effort. Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'. It's a bit like the news cycle, these things tend to burn out. But right now OpenSSL exploits are very much in the spotlight, and guarantee almost instant fame for the person discovering one. So I think we'll see a few more of these before it will quiet down. (I actually hope that we won't see more of these but given the past couple of weeks that hope is not very realistic).
  - Florin_Andrei 12y ago
    > Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'. Having been around in the '90s, with the instant root shell exploits and whatnot, I tend to think of Heartbleed as more of a 6.
    - TillE 12y ago
      I think some people have also forgotten what a complete disaster Microsoft was right up until the mid 2000s. IE exploits, Windows exploits, IIS exploits (remember Code Red?). They well and truly earned their reputation.
      - Florin_Andrei 12y ago
        Teardrop was fantastic.
deleted 12y ago
[deleted]
ctz 12y ago
CVE-2014-0224 looks the worst of this bunch. It seems openssl will accept ChangeCipherSpec messages much too early. CCS in TLS means "we've finished handshake/renegotiation and will now start using the new keys". It looks likely that a MITM can send CCS to both ends during handshake, and have them agree on the empty master secret (and therefore trivial application data encryption keys). This is pretty bad as far as TLS bugs go (as bad as "goto fail", but not as bad as "heartbleed"). Given that accepting TLS messages only within the right constraints is fundamental to correctness of TLS and openssl seemingly can't get this right (this, and heartbeat messages before/during handshake), it seems likely this isn't the last problem of this kind.
- JacobAldridge 12y ago
  as bad as "goto fail", but not as bad as "heartbleed" Thank you for this excellent description for we who recognise this must be a problem, but lack the area knowledge to immediately appreciate how bad (or not) it may be.
  - reaperhulk 12y ago
    I would even dispute it being as bad as goto fail. For this to work both client and server must be vulnerable and the attacker must be in a privileged network position. A malicious server can do it, but it's significantly more difficult to exploit this than goto fail. Edit: agl has a good writeup of the bug and what it might take to exploit https://www.imperialviolet.org/2014/06/05/earlyccs.html https://www.imperialviolet.org/2014/06/05/earlyccs.html
    - mnw21cam 12y ago
      It would mean (for example) that your local coffee shop could MITM their clients connecting to the bank through their free wifi. Being in a privileged network position isn't that hard, with all the mobile devices flying around everywhere.
      - jacquesm 12y ago
m4r71n 12y ago
Red Hat advisory for RHEL6 seems to be already available: https://rhn.redhat.com/errata/RHSA-2014-0625.html https://rhn.redhat.com/errata/RHSA-2014-0625.html Edit: They also released a blog entry about the CCS injection issue: https://access.redhat.com/site/blogs/766093/posts/908133 https://access.redhat.com/site/blogs/766093/posts/908133
thefreeman 12y ago
I feel like there is a (potentially bad) typo in the second paragraph of this advisory. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. It seems to me that users on versions earlier then 1.0.1 would be advised not to upgrade since they stated in the sentence before that 1.0.1 is vulnerable. ------ edit: Oops, I feel kind of dumb. Literally the next line is describing the recommended upgrade for 0.9.8 users: OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
- adrianb 12y ago
  They say, versions earlier than 1.0.1 might be vulnerable, we're not sure, so upgrade to the latest (presumably a newer version than 1.0.2-beta1).
- kijin 12y ago
  "Upgrade" doesn't necessarily mean "upgrade to 1.0.1". Older versions are still getting updates. Unfortunately, this might not be clear to some readers because OpenSSL uses a weird versioning scheme. The three numbers stay the same, but the alphabetical part at the end gets incremented each time there's an update. > OpenSSL 0.9.8 SSL/TLS users should upgrade to 0.9.8za. > OpenSSL 1.0.0 SSL/TLS users should upgrade to 1.0.0m. > OpenSSL 1.0.1 SSL/TLS users should upgrade to 1.0.1h.
reaperhulk 12y ago
Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00129.html https://lists.debian.org/debian-security-announce/2014/msg00... Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html https://rhn.redhat.com/errata/RHSA-2014-0625.html Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html https://rhn.redhat.com/errata/RHSA-2014-0624.html Ubuntu advisory: https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-June/002532.html https://lists.ubuntu.com/archives/ubuntu-security-announce/2...
- mdtancsa 12y ago
  And FreeBSD http://www.freebsd.org/security/advisories/FreeBSD-SA-14:14.openssl.asc http://www.freebsd.org/security/advisories/FreeBSD-SA-14:14....
- dorfsmay 12y ago
  Anybody know what the difference is between Ubuntu package openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4
  - helper 12y ago
    1.0.1e-3ubuntu1.2 is older and doesn't have the fix for this CVE.
  - aendruk 12y ago
    This page [1] links to the package's changelog [2], which should answer your question. [1]: http://packages.ubuntu.com/saucy/openssl http://packages.ubuntu.com/saucy/openssl [2]: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.1e-3ubuntu1.4/changelog http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...
reaperhulk 12y ago
Logos are now prerequisite, so of course CVE-2014-0224 has you covered. http://ccsinjection.lepidum.co.jp http://ccsinjection.lepidum.co.jp If you want to see the patches they're now up on GitHub: OpenSSL 1.0.1: https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-sta... OpenSSL 1.0.0: https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-stable https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-sta... OpenSSL 0.9.8: https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-stable https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-sta...
- kerneis 12y ago
  "Q. How did you find this bug? A. This bug was discovered by Masashi Kikuchi of Lepidum. He found this bug while studying safe TLS implementations using a proof assistant system Coq." So they are starting to find actual bugs with Coq? I'm impressed, and would love to know if anybody has more details (lepidum's blog seems down at the moment).
  - johnkeeping 12y ago
    The ImperialViolet post linked above gives a different URL for the blog post which does work: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...
  - bashinator 12y ago
    There's some good discussion of it on the netsec subreddit. http://www.reddit.com/r/netsec/comments/27dhcn/openssl_security_advisory_seven_security_fixes/chzv3j6?context=2 http://www.reddit.com/r/netsec/comments/27dhcn/openssl_secur...
- deleted 12y ago
  [deleted]
jgrahamc 12y ago
Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common. Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading. (1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know if it is vulnerable to this problem.
- rdl 12y ago
  This should be interesting for OpenVPN.
  - peterwwillis 12y ago
    I think people underestimate how many products use OpenSSL... http://www.pcworld.com/article/2143440/server-makers-rushing-out-heartbleed-patches.html http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartbleed-bug-hits-at-heart-of-many-cisco--juniper-products.html http://www.networkworld.com/article/2176022/router/heartblee... It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.
    - woodrow 12y ago
      OpenVPN already sort of supports this: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).
ishatmypants 12y ago
Is LibreSSL also vulnerable to this?
- X-Istence 12y ago
  Yes, there have been no audits of the protocol code yet. I have a feeling it will be patched shortly. See Ted's comment here: https://news.ycombinator.com/item?id=7851949 https://news.ycombinator.com/item?id=7851949
0x0 12y ago
There's also a linux kernel update today, for a local root exploit(?) (CVE-2014-3153): https://lists.debian.org/debian-security-announce/2014/msg00130.html https://lists.debian.org/debian-security-announce/2014/msg00... https://news.ycombinator.com/item?id=7851535 https://news.ycombinator.com/item?id=7851535
fomb 12y ago
https://status.heroku.com/incidents/636 https://status.heroku.com/incidents/636
pling 12y ago
Interested to see if LibreSSL has knocked these ones on the head.
- tedunangst 12y ago
  Two of them, CVE-2014-0198 and CVE-2010-5298. We haven't even started looking at the protocol code. I'll also note that "This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common." is pretty misleading. nginx is affected, is not multithreaded, but is fairly common.
  - pling 12y ago
    Thanks for the reply. This is exactly why I have more faith in you guys with LibreSSL. You're right on the case, know what's going on all the time and communications are good (as they always are with the OpenBSD project). Please keep up the great work.
  - jacquesm 12y ago
    Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?
    - clarry 12y ago
      That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding enables them to hack more (i.e. hackathons, hardware for developers who need it, infra, etc.) and to share the result with the rest of us (servers & infra). Can you imagine someone saying "I want to give you this gift but only if you focus on thing X (which I care about) and not on things Y and Z (which you care about)"? Keep in mind that the BSDs strive to be a complete, integrated operating system. While some devs focus on small parts of the tree, many or most work on the larger whole. Improvements to specific parts are a part of improvements to the whole. Working on LibreSSL is a byproduct or part of working on OpenBSD. Can you buy a faster server and more bandwidth to serve this one subdirectory in your project? But don't spend that money on anything else? EDIT: Having said that, developers are and have been funded to work on specific things.. IIRC the kms work was sponsored, and gilles works on smtpd as a part of his job. But I think it would be kind of rude to disregard the effort the core OpenBSD devs have spent on LibreSSL and only donate if you can give that money to one or two paid developers. Look at it this way: Theo works on many many parts of the system. So does Miod. And so does Bob. As do many other developers who commit changes to LibreSSL. They're in it for OpenBSD. Can you tell them to forget OpenBSD and do LibreSSL for you? EDIT: Or how about this? Sorry guys, this hackathon we're allowed to touch libssl only. Why? Because some people "donated" for us to work on LibreSSL and LibreSSL only. I don't think it can go like that. It becames work for money. Work on specific things people pay you to work on. Work for people who are voluntarily working on OpenBSD. I doubt many OpenBSD developers would attend such a hackathon.
billpg 12y ago
Does this one have a logo? I'm not going to take it seriously unless it has a logo.
- korstiaan 12y ago
  It does: http://ccsinjection.lepidum.co.jp/ http://ccsinjection.lepidum.co.jp/
  - billpg 12y ago
    That's me told.
zekenie 12y ago
Is it recommended to cycle ssl certs?
- danielweber 12y ago
  From http://ccsinjection.lepidum.co.jp/ http://ccsinjection.lepidum.co.jp/ Q. Do I have to re-create my private keys or certificates? A. No. Attackers cannot steal your private keys through this bug itself. However if you have transferred your private keys via paths protected by SSL/TLS, the keys could be sniffed. If this is the case, consider regenerating the keys or certificates.
leorocky 12y ago
Does this vulnerability compromise the private key? Should people generate new key pairs?
- danielweber 12y ago
  http://ccsinjection.lepidum.co.jp/ http://ccsinjection.lepidum.co.jp/ > No. Attackers cannot steal your private keys through this bug itself.
lucaspiller 12y ago
The change can be seen here: https://github.com/openssl/openssl/commit/bc8923b1ec9c467755cd86f7848c50ee8812e441 https://github.com/openssl/openssl/commit/bc8923b1ec9c467755... I noticed (in that commit anyway) there were no tests changed. Is it pretty standard not to test things like this? If I find a major bug in code I write, I usually write a test first and TTD until it's fixed.
dk8996 12y ago
Anyone know if this has any impact on AWS Load Balancer?
- TheCustos 12y ago
  It did, and it's being patched. http://aws.amazon.com/security/security-bulletins/openssl-security-advisory/ http://aws.amazon.com/security/security-bulletins/openssl-se...
anon12 12y ago
Looking at all the attention openSSL is getting these days, I'd use another solution in my production servers (if security was an important concern).
mnicky 12y ago
It seems that both Heartbleed and this MITM vulnerability were introduced by Robin Seggelmann [1], which will surely drive a lot of speculations... [1] http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-14-173-CVE-2014-0195-OpenSSL-DTLS-Fragment-Out-of-Bounds/ba-p/6501002#.U5Cjpnmx3UY http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-1...

385 points by davidroetzel 12y ago

gamed 12y ago

The large volume of vulnerabilities coming out of OpenSSL are worrying, but it likely reflects the increased effort being put into auditing and fuzzing the code after Heartbleed. What is more worrying is the many other critical pieces of software that have nowhere near the level of scrutiny that OpenSSL is receiving currently.

gtirloni 12y ago
Yes, the current situation is (probably) bad. The Core Infrastructure Initiative is starting to address that: http://www.linuxfoundation.org/programs/core-infrastructure-initiative http://www.linuxfoundation.org/programs/core-infrastructure-...
jacquesm 12y ago
Searching for vulnerabilities is just like mining for gold: you go for the richest veins first and OpenSSL is deployed widely enough and in enough places where it really matters that it is currently a priority item. I guess until a couple of weeks ago OpenSSL was 'one of many other critical pieces of software that have nowhere near the level of scrutiny that WordPress (and I know you don't meant Wordpress) is receiving currently'. So we'll see a re-focusing on other software when people feel that either the OpenSSL well of exploits has at least temporarily dried up or when something else that is crucial breaks. But as long as vulnerabilities in OpenSSL are discovered at this rate it seems to be an effort well-spent, and we will all reap the benefit of that effort. Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'. It's a bit like the news cycle, these things tend to burn out. But right now OpenSSL exploits are very much in the spotlight, and guarantee almost instant fame for the person discovering one. So I think we'll see a few more of these before it will quiet down. (I actually hope that we won't see more of these but given the past couple of weeks that hope is not very realistic).
- Florin_Andrei 12y ago
  > Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'. Having been around in the '90s, with the instant root shell exploits and whatnot, I tend to think of Heartbleed as more of a 6.
  - TillE 12y ago
    I think some people have also forgotten what a complete disaster Microsoft was right up until the mid 2000s. IE exploits, Windows exploits, IIS exploits (remember Code Red?). They well and truly earned their reputation.
    - Florin_Andrei 12y ago
      Teardrop was fantastic.

deleted 12y ago

[deleted]

ctz 12y ago

CVE-2014-0224 looks the worst of this bunch. It seems openssl will accept ChangeCipherSpec messages much too early. CCS in TLS means "we've finished handshake/renegotiation and will now start using the new keys". It looks likely that a MITM can send CCS to both ends during handshake, and have them agree on the empty master secret (and therefore trivial application data encryption keys). This is pretty bad as far as TLS bugs go (as bad as "goto fail", but not as bad as "heartbleed"). Given that accepting TLS messages only within the right constraints is fundamental to correctness of TLS and openssl seemingly can't get this right (this, and heartbeat messages before/during handshake), it seems likely this isn't the last problem of this kind.

JacobAldridge 12y ago
as bad as "goto fail", but not as bad as "heartbleed" Thank you for this excellent description for we who recognise this must be a problem, but lack the area knowledge to immediately appreciate how bad (or not) it may be.
- reaperhulk 12y ago
  I would even dispute it being as bad as goto fail. For this to work both client and server must be vulnerable and the attacker must be in a privileged network position. A malicious server can do it, but it's significantly more difficult to exploit this than goto fail. Edit: agl has a good writeup of the bug and what it might take to exploit https://www.imperialviolet.org/2014/06/05/earlyccs.html https://www.imperialviolet.org/2014/06/05/earlyccs.html
  - mnw21cam 12y ago
    It would mean (for example) that your local coffee shop could MITM their clients connecting to the bank through their free wifi. Being in a privileged network position isn't that hard, with all the mobile devices flying around everywhere.
    - jacquesm 12y ago

m4r71n 12y ago

Red Hat advisory for RHEL6 seems to be already available: https://rhn.redhat.com/errata/RHSA-2014-0625.html https://rhn.redhat.com/errata/RHSA-2014-0625.html Edit: They also released a blog entry about the CCS injection issue: https://access.redhat.com/site/blogs/766093/posts/908133 https://access.redhat.com/site/blogs/766093/posts/908133

thefreeman 12y ago

I feel like there is a (potentially bad) typo in the second paragraph of this advisory. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. It seems to me that users on versions earlier then 1.0.1 would be advised not to upgrade since they stated in the sentence before that 1.0.1 is vulnerable. ------ edit: Oops, I feel kind of dumb. Literally the next line is describing the recommended upgrade for 0.9.8 users: OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.

adrianb 12y ago
They say, versions earlier than 1.0.1 might be vulnerable, we're not sure, so upgrade to the latest (presumably a newer version than 1.0.2-beta1).
kijin 12y ago
"Upgrade" doesn't necessarily mean "upgrade to 1.0.1". Older versions are still getting updates. Unfortunately, this might not be clear to some readers because OpenSSL uses a weird versioning scheme. The three numbers stay the same, but the alphabetical part at the end gets incremented each time there's an update. > OpenSSL 0.9.8 SSL/TLS users should upgrade to 0.9.8za. > OpenSSL 1.0.0 SSL/TLS users should upgrade to 1.0.0m. > OpenSSL 1.0.1 SSL/TLS users should upgrade to 1.0.1h.

reaperhulk 12y ago

Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00129.html https://lists.debian.org/debian-security-announce/2014/msg00... Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html https://rhn.redhat.com/errata/RHSA-2014-0625.html Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html https://rhn.redhat.com/errata/RHSA-2014-0624.html Ubuntu advisory: https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-June/002532.html https://lists.ubuntu.com/archives/ubuntu-security-announce/2...

mdtancsa 12y ago
And FreeBSD http://www.freebsd.org/security/advisories/FreeBSD-SA-14:14.openssl.asc http://www.freebsd.org/security/advisories/FreeBSD-SA-14:14....
dorfsmay 12y ago
Anybody know what the difference is between Ubuntu package openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4
- helper 12y ago
  1.0.1e-3ubuntu1.2 is older and doesn't have the fix for this CVE.
- aendruk 12y ago
  This page [1] links to the package's changelog [2], which should answer your question. [1]: http://packages.ubuntu.com/saucy/openssl http://packages.ubuntu.com/saucy/openssl [2]: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.1e-3ubuntu1.4/changelog http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...

reaperhulk 12y ago

Logos are now prerequisite, so of course CVE-2014-0224 has you covered. http://ccsinjection.lepidum.co.jp http://ccsinjection.lepidum.co.jp If you want to see the patches they're now up on GitHub: OpenSSL 1.0.1: https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-sta... OpenSSL 1.0.0: https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-stable https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-sta... OpenSSL 0.9.8: https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-stable https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-sta...

kerneis 12y ago
"Q. How did you find this bug? A. This bug was discovered by Masashi Kikuchi of Lepidum. He found this bug while studying safe TLS implementations using a proof assistant system Coq." So they are starting to find actual bugs with Coq? I'm impressed, and would love to know if anybody has more details (lepidum's blog seems down at the moment).
- johnkeeping 12y ago
  The ImperialViolet post linked above gives a different URL for the blog post which does work: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...
- bashinator 12y ago
  There's some good discussion of it on the netsec subreddit. http://www.reddit.com/r/netsec/comments/27dhcn/openssl_security_advisory_seven_security_fixes/chzv3j6?context=2 http://www.reddit.com/r/netsec/comments/27dhcn/openssl_secur...
deleted 12y ago
[deleted]

jgrahamc 12y ago

Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common. Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading. (1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know if it is vulnerable to this problem.

rdl 12y ago
This should be interesting for OpenVPN.
- peterwwillis 12y ago
  I think people underestimate how many products use OpenSSL... http://www.pcworld.com/article/2143440/server-makers-rushing-out-heartbleed-patches.html http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartbleed-bug-hits-at-heart-of-many-cisco--juniper-products.html http://www.networkworld.com/article/2176022/router/heartblee... It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.
  - woodrow 12y ago
    OpenVPN already sort of supports this: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).

ishatmypants 12y ago

Is LibreSSL also vulnerable to this?

X-Istence 12y ago
Yes, there have been no audits of the protocol code yet. I have a feeling it will be patched shortly. See Ted's comment here: https://news.ycombinator.com/item?id=7851949 https://news.ycombinator.com/item?id=7851949

0x0 12y ago

There's also a linux kernel update today, for a local root exploit(?) (CVE-2014-3153): https://lists.debian.org/debian-security-announce/2014/msg00130.html https://lists.debian.org/debian-security-announce/2014/msg00... https://news.ycombinator.com/item?id=7851535 https://news.ycombinator.com/item?id=7851535

fomb 12y ago

https://status.heroku.com/incidents/636 https://status.heroku.com/incidents/636

pling 12y ago

Interested to see if LibreSSL has knocked these ones on the head.

tedunangst 12y ago
Two of them, CVE-2014-0198 and CVE-2010-5298. We haven't even started looking at the protocol code. I'll also note that "This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common." is pretty misleading. nginx is affected, is not multithreaded, but is fairly common.
- pling 12y ago
  Thanks for the reply. This is exactly why I have more faith in you guys with LibreSSL. You're right on the case, know what's going on all the time and communications are good (as they always are with the OpenBSD project). Please keep up the great work.
- jacquesm 12y ago
  Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?
  - clarry 12y ago
    That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding enables them to hack more (i.e. hackathons, hardware for developers who need it, infra, etc.) and to share the result with the rest of us (servers & infra). Can you imagine someone saying "I want to give you this gift but only if you focus on thing X (which I care about) and not on things Y and Z (which you care about)"? Keep in mind that the BSDs strive to be a complete, integrated operating system. While some devs focus on small parts of the tree, many or most work on the larger whole. Improvements to specific parts are a part of improvements to the whole. Working on LibreSSL is a byproduct or part of working on OpenBSD. Can you buy a faster server and more bandwidth to serve this one subdirectory in your project? But don't spend that money on anything else? EDIT: Having said that, developers are and have been funded to work on specific things.. IIRC the kms work was sponsored, and gilles works on smtpd as a part of his job. But I think it would be kind of rude to disregard the effort the core OpenBSD devs have spent on LibreSSL and only donate if you can give that money to one or two paid developers. Look at it this way: Theo works on many many parts of the system. So does Miod. And so does Bob. As do many other developers who commit changes to LibreSSL. They're in it for OpenBSD. Can you tell them to forget OpenBSD and do LibreSSL for you? EDIT: Or how about this? Sorry guys, this hackathon we're allowed to touch libssl only. Why? Because some people "donated" for us to work on LibreSSL and LibreSSL only. I don't think it can go like that. It becames work for money. Work on specific things people pay you to work on. Work for people who are voluntarily working on OpenBSD. I doubt many OpenBSD developers would attend such a hackathon.

billpg 12y ago

Does this one have a logo? I'm not going to take it seriously unless it has a logo.

korstiaan 12y ago
It does: http://ccsinjection.lepidum.co.jp/ http://ccsinjection.lepidum.co.jp/
- billpg 12y ago
  That's me told.

zekenie 12y ago

Is it recommended to cycle ssl certs?

danielweber 12y ago
From http://ccsinjection.lepidum.co.jp/ http://ccsinjection.lepidum.co.jp/ Q. Do I have to re-create my private keys or certificates? A. No. Attackers cannot steal your private keys through this bug itself. However if you have transferred your private keys via paths protected by SSL/TLS, the keys could be sniffed. If this is the case, consider regenerating the keys or certificates.

leorocky 12y ago

Does this vulnerability compromise the private key? Should people generate new key pairs?

danielweber 12y ago
http://ccsinjection.lepidum.co.jp/ http://ccsinjection.lepidum.co.jp/ > No. Attackers cannot steal your private keys through this bug itself.

lucaspiller 12y ago

The change can be seen here: https://github.com/openssl/openssl/commit/bc8923b1ec9c467755cd86f7848c50ee8812e441 https://github.com/openssl/openssl/commit/bc8923b1ec9c467755... I noticed (in that commit anyway) there were no tests changed. Is it pretty standard not to test things like this? If I find a major bug in code I write, I usually write a test first and TTD until it's fixed.

dk8996 12y ago

Anyone know if this has any impact on AWS Load Balancer?

TheCustos 12y ago
It did, and it's being patched. http://aws.amazon.com/security/security-bulletins/openssl-security-advisory/ http://aws.amazon.com/security/security-bulletins/openssl-se...

anon12 12y ago

Looking at all the attention openSSL is getting these days, I'd use another solution in my production servers (if security was an important concern).

mnicky 12y ago

It seems that both Heartbleed and this MITM vulnerability were introduced by Robin Seggelmann [1], which will surely drive a lot of speculations... [1] http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-14-173-CVE-2014-0195-OpenSSL-DTLS-Fragment-Out-of-Bounds/ba-p/6501002#.U5Cjpnmx3UY http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-1...