Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

11–20 of 89 posts

Re: OpenSSL Security Advisory

#11

Post by reaperhulk »

Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00...

Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html

Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html

Ubuntu advisory: https://lists.ubuntu.com/archives/ubuntu-security-announce/2...

Re: OpenSSL Security Advisory

#12

Post by kijin »

thefreeman wrote: post #8

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,…

"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.

Re: OpenSSL Security Advisory

#13

Post by reaperhulk »

Logos are now prerequisite, so of course CVE-2014-0224 has you covered. 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-sta...

OpenSSL 1.0.0: 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-sta...

Re: OpenSSL Security Advisory

#14

Post by reaperhulk »

JacobAldridge wrote: post #10
ctz wrote: post #5

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 T…

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.

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

Re: OpenSSL Security Advisory

#15

Post by jgrahamc »

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.

Re: OpenSSL Security Advisory

#17

Post by Jare »

ctz wrote: post #5

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 T…

Note also that this type of failure to strictly adhere to spec behaviour, for any specific case, is perfectly possible in other implementations, whereas coding errors like goto fail or heartbleed are much less likely to duplicate in different codebases. Thus, I wouldn't rule out other SSL implementations being vulnerable to this exact issue as well.

Re: OpenSSL Security Advisory

#18

Post by mnw21cam »

reaperhulk wrote: post #14
JacobAldridge wrote: post #10

Earlier quoted context omitted.

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.

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

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.

Re: OpenSSL Security Advisory

#19

Post by rdl »

jgrahamc wrote: post #15

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…

This should be interesting for OpenVPN.
Post reply on HN