4 ms·

According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wh

According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wheezy (oldstable): Much to old OpenSSL versions, according to the info site Jessy (stable): Still to old OpenSSL version. Stretch (testing): Still to old OpenSSL version. Sid (unstable): The same version of OpenSSL as Stretch -- Still to old. What to do?

anc84 11y ago
Disable SSLv2 everywhere.
- PythonicAlpha 11y ago
  To make it more clear: According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found). (I also updated my original post)
  - r1ch 11y ago
    SSLv2 and SSLv3 are dropped at compile time in Jessie.
  - drewcrawford 11y ago
    You misunderstand how Debian works. Debian practically never updates to new versions of software (until you upgrade Debian). Instead they "backport" security fixes into the older software versions, preserving the old version numbers but adding some stuff on the end to reflect Debian's changes. The intent is that you get "only" security fixes, never features or improvements. So when you see "OpenSSL-1.0.c-stuffgoeshere" you are not looking at "OpenSSL" openssl anymore, but a version that Debian customized, probably to add security fixes. I say "Debian" here, but really most distros do it (RHEL, Ubuntu, CentOS, etc.) I'm just not familiar enough with their processes to comment specifically. Debian has disabled SSLv2 in its OpenSSL packages since 2010 [0], and if you are running a Debian OpenSSL version later than 1.0.0c-2 your OpenSSL version is not vulnerable. The current version of OpenSSL in stable is 1.0.1k-3+deb8u2, so unless your server has been under a rock for 5 years you should be fine. And if it's been under a rock for 5 years you have a lot of security vulnerabilities to be worried about. Of course you may have installed OpenSSL from somewhere else, or you may be using some other software for SSLv2 that doesn't involve OpenSSL at all. So merely upgrading your OpenSSL version is not a silver bullet, you need to think about every TLS deployment you have and how it might be used. More broadly, use this vulnerability as a wakeup call to learn about "where your software comes from", because everybody has a role to play in staying secure, including users. Debian is maintained by volunteers; you might be happier with a commercial vendor who guarantees response times. Debian backports security fixes; you might be happier with a distribution that upgrades to new vendor versions which may have avoided the confusion here. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706
    - PythonicAlpha 11y ago
      > you might be happier with a commercial vendor Might be a viable option. I just don't know a commercial vendor, that also gives more transparency. I knew, that there are also fixes from the Debian team, that add to the core functionality. But still my problem is the transparency. It is just very difficult in such a case, to find out the relevant changes, if you lack the time to observe all security changes in the distribution. When such a thing pops up, like today, it is very tedious work for people like me, to find all the strings involved. So many packages, that can potentially involved, so many applications (eg. WebServer, SSH-Server, ...) and everywhere could be a hole. Here, I would appreciate, some more focused information, about the particular distribution. I am using Debian because of its good reputation -- but of course if you could point out a commercial distribution with more transparency, it would be worthwhile!
xuhu 11y ago
Jessie has 5 changesets on top of 1.0.1k which fix 14 CVE's: http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/jessie/debian/changelog?revision=756&view=markup http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branche... And similar for the other debian versions.
- PythonicAlpha 11y ago
  Ok, is there any CVE that covers this attack / disables SSLv2? This is rather in-transparent to me. Would be nice, if somebody could give better advice on this soon.
  - xuhu 11y ago
    DROWN is CVE-2016-0800. There are a lot of CVE's in openssl's advisory released 10 minutes ago: https://www.openssl.org/news/secadv/20160301.txt https://www.openssl.org/news/secadv/20160301.txt None are fixed yet of course in debian. And not in ubuntu either: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.2d-0ubuntu1.3/changelog http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...
    - rlpb 11y ago
      Actually Ubuntu is not affected because it already has SSLv2 disabled: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-0800.html http://people.canonical.com/~ubuntu-security/cve/2016/CVE-20... You won't see a fix appear in the changelog because there is nothing to fix in the Ubuntu packages.
pfg 11y ago
Typically, most server software has configuration options that allow you to specify which protocol versions are permitted (i.e. ssl_protocols in nginx, SSLProtocol in apache). Sometimes, they also bring defaults that are stricter than what OpenSSL supports by default. The difference between older OpenSSL versions shipped by distributions and the latest version is not that newer protocols aren't supported, but that they haven't completely removed support for older, insecure protocols. For example, SSLv2 was only disabled by default in OpenSSL 1.0.2g, which was released today. Meanwhile, a lot of server software (e.g. nginx) had it disabled by default for quite some time now. This is mostly relevant if you have code that uses OpenSSL directly - but then it's probably not a good idea to rely on OpenSSL defaults anyway. tl;dr Older OpenSSL versions are probably fine as long as your server software has good defaults.
- PythonicAlpha 11y ago
  Ok, can you tell in short, which server software is involved? Nginx is not the only one, I guess. At least ssh should also be in the boat ... and the mail server .... and ....
  - pfg 11y ago
    OpenSSH is a different project that doesn't use OpenSSL, so that's not affected. As for other software, it depends on the defaults and how their code disables SSLv2 (i.e. whether they just disable all SSLv2 ciphers, or disable the actual protocol with SSL_OP_NO_SSLv2). Anyway, it's likely that most distributions will backport the fix soon for all supported OS versions (either by disabling SSLv2 too or by including the fix from OpenSSL 1.0.2f that allows SSLv2 handshakes even if SSLv2 ciphers are disabled).
cjbprime 11y ago
> According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. Not quite. If you disable the SSLv2 protocol, you're fine. If you have the SSLv2 protocol enabled but all the SSLv2 ciphersuites disabled, you're not fine. You can disable the SSLv2 protocol in versions of openssl previous to today's.
pferde 11y ago
From the recent Debian security advisory (DSA-3500-1) about this: "Additionally the EXPORT and LOW ciphers were disabled since thay could be used as part of the DROWN (CVE-2016-0800) and SLOTH (CVE-2015-7575) attacks, but note that the oldstable (wheezye)[sic!] and stable (jessie) distributions are not affected by those attacks since the SSLv2 protocol has already been dropped in the openssl package version 1.0.0c-2." So it seems that neither Jessie nor Wheezy are affected by this.
- PythonicAlpha 11y ago
  Thank you very much!

anc84 11y ago

Disable SSLv2 everywhere.

PythonicAlpha 11y ago
To make it more clear: According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found). (I also updated my original post)
- r1ch 11y ago
  SSLv2 and SSLv3 are dropped at compile time in Jessie.
- drewcrawford 11y ago
  You misunderstand how Debian works. Debian practically never updates to new versions of software (until you upgrade Debian). Instead they "backport" security fixes into the older software versions, preserving the old version numbers but adding some stuff on the end to reflect Debian's changes. The intent is that you get "only" security fixes, never features or improvements. So when you see "OpenSSL-1.0.c-stuffgoeshere" you are not looking at "OpenSSL" openssl anymore, but a version that Debian customized, probably to add security fixes. I say "Debian" here, but really most distros do it (RHEL, Ubuntu, CentOS, etc.) I'm just not familiar enough with their processes to comment specifically. Debian has disabled SSLv2 in its OpenSSL packages since 2010 [0], and if you are running a Debian OpenSSL version later than 1.0.0c-2 your OpenSSL version is not vulnerable. The current version of OpenSSL in stable is 1.0.1k-3+deb8u2, so unless your server has been under a rock for 5 years you should be fine. And if it's been under a rock for 5 years you have a lot of security vulnerabilities to be worried about. Of course you may have installed OpenSSL from somewhere else, or you may be using some other software for SSLv2 that doesn't involve OpenSSL at all. So merely upgrading your OpenSSL version is not a silver bullet, you need to think about every TLS deployment you have and how it might be used. More broadly, use this vulnerability as a wakeup call to learn about "where your software comes from", because everybody has a role to play in staying secure, including users. Debian is maintained by volunteers; you might be happier with a commercial vendor who guarantees response times. Debian backports security fixes; you might be happier with a distribution that upgrades to new vendor versions which may have avoided the confusion here. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706
  - PythonicAlpha 11y ago
    > you might be happier with a commercial vendor Might be a viable option. I just don't know a commercial vendor, that also gives more transparency. I knew, that there are also fixes from the Debian team, that add to the core functionality. But still my problem is the transparency. It is just very difficult in such a case, to find out the relevant changes, if you lack the time to observe all security changes in the distribution. When such a thing pops up, like today, it is very tedious work for people like me, to find all the strings involved. So many packages, that can potentially involved, so many applications (eg. WebServer, SSH-Server, ...) and everywhere could be a hole. Here, I would appreciate, some more focused information, about the particular distribution. I am using Debian because of its good reputation -- but of course if you could point out a commercial distribution with more transparency, it would be worthwhile!

xuhu 11y ago

Jessie has 5 changesets on top of 1.0.1k which fix 14 CVE's: http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/jessie/debian/changelog?revision=756&view=markup http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branche... And similar for the other debian versions.

PythonicAlpha 11y ago
Ok, is there any CVE that covers this attack / disables SSLv2? This is rather in-transparent to me. Would be nice, if somebody could give better advice on this soon.
- xuhu 11y ago
  DROWN is CVE-2016-0800. There are a lot of CVE's in openssl's advisory released 10 minutes ago: https://www.openssl.org/news/secadv/20160301.txt https://www.openssl.org/news/secadv/20160301.txt None are fixed yet of course in debian. And not in ubuntu either: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.2d-0ubuntu1.3/changelog http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...
  - rlpb 11y ago
    Actually Ubuntu is not affected because it already has SSLv2 disabled: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-0800.html http://people.canonical.com/~ubuntu-security/cve/2016/CVE-20... You won't see a fix appear in the changelog because there is nothing to fix in the Ubuntu packages.

pfg 11y ago

Typically, most server software has configuration options that allow you to specify which protocol versions are permitted (i.e. ssl_protocols in nginx, SSLProtocol in apache). Sometimes, they also bring defaults that are stricter than what OpenSSL supports by default. The difference between older OpenSSL versions shipped by distributions and the latest version is not that newer protocols aren't supported, but that they haven't completely removed support for older, insecure protocols. For example, SSLv2 was only disabled by default in OpenSSL 1.0.2g, which was released today. Meanwhile, a lot of server software (e.g. nginx) had it disabled by default for quite some time now. This is mostly relevant if you have code that uses OpenSSL directly - but then it's probably not a good idea to rely on OpenSSL defaults anyway. tl;dr Older OpenSSL versions are probably fine as long as your server software has good defaults.

PythonicAlpha 11y ago
Ok, can you tell in short, which server software is involved? Nginx is not the only one, I guess. At least ssh should also be in the boat ... and the mail server .... and ....
- pfg 11y ago
  OpenSSH is a different project that doesn't use OpenSSL, so that's not affected. As for other software, it depends on the defaults and how their code disables SSLv2 (i.e. whether they just disable all SSLv2 ciphers, or disable the actual protocol with SSL_OP_NO_SSLv2). Anyway, it's likely that most distributions will backport the fix soon for all supported OS versions (either by disabling SSLv2 too or by including the fix from OpenSSL 1.0.2f that allows SSLv2 handshakes even if SSLv2 ciphers are disabled).

cjbprime 11y ago

> According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. Not quite. If you disable the SSLv2 protocol, you're fine. If you have the SSLv2 protocol enabled but all the SSLv2 ciphersuites disabled, you're not fine. You can disable the SSLv2 protocol in versions of openssl previous to today's.

pferde 11y ago

From the recent Debian security advisory (DSA-3500-1) about this: "Additionally the EXPORT and LOW ciphers were disabled since thay could be used as part of the DROWN (CVE-2016-0800) and SLOTH (CVE-2015-7575) attacks, but note that the oldstable (wheezye)[sic!] and stable (jessie) distributions are not affected by those attacks since the SSLv2 protocol has already been dropped in the openssl package version 1.0.0c-2." So it seems that neither Jessie nor Wheezy are affected by this.

PythonicAlpha 11y ago
Thank you very much!