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

The DROWN Attack

drownattack.com

Post reply on HN
Print view View original

41–50 of 206 posts

Re: The DROWN Attack

#41

Post by PythonicAlpha »

xuhu wrote: post #39
PythonicAlpha wrote: post #25

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?

Jessie has 5 changesets on top of 1.0.1k which fix 14 CVE's: http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branche... And similar for the other debian versions.

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.

Re: The DROWN Attack

#42

Post by PythonicAlpha »

pfg wrote: post #40
PythonicAlpha wrote: post #25

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?

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

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

Re: The DROWN Attack

#44

Post by xuhu »

PythonicAlpha wrote: post #41
xuhu wrote: post #39

Earlier quoted context omitted.

Jessie has 5 changesets on top of 1.0.1k which fix 14 CVE's: http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branche... And similar for the other debian versions.

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.

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

None are fixed yet of course in debian. And not in ubuntu either: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...

Re: The DROWN Attack

#45

Post by dadrian »

jvehent wrote: post #17

From a pool of 11 million scans of HTTPS sites, I could only find ~265k targets with SSLv2 enabled [1]. That's 2.4%, not 25%. A breakdown of the type of target that have SSLv2 enabled would be useful to understand how they reached that number. It's possible that they scanned much much more than HTTPS on port 443, and found a lot of embedded devices with poor SSL configurations. At any rate, you should verify the conf…

Due to CVE-2015-3197, many servers using OpenSSL reported they supported no SSLv2 ciphers, which causes OpenSSL-based SSLv2 clients to hang up. However, if you aggressively choose a cipher and continue the handshake, the server will still negotiate the connection. As a result, most existing scanning tools vastly underestimate SSLv2 support.

Re: The DROWN Attack

#46

Post by r1ch »

PythonicAlpha wrote: post #34
anc84 wrote: post #33

Earlier quoted context omitted.

Disable SSLv2 everywhere.

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)

SSLv2 and SSLv3 are dropped at compile time in Jessie.

Re: The DROWN Attack

#47

Post by [deleted] »

rmc wrote: post #29
bencollier49 wrote: post #3

These marketed attacks with special logos drive me up the wall. If I ever discover one I'll give it a rude name and force everyone to look at a silly picture to go with it.

But Heartbleed was the first one, and it's marketing made it get everywhere. Regular newspapers, etc. Instead of hating people marketing vulnerbilities, tackle why people-in-power don't care about vuln when communicated the old way.

[deleted]

Re: The DROWN Attack

#48

Post by ColinDabritz »

From the article: "For the third time in a year, a major Internet security vulnerability has resulted from the way cryptography was weakened by U.S. government policies that restricted exporting strong cryptography until the late 1990s."

The bearing of this on the ongoing "backdoor" and "just one device" discussions is critical. This is direct evidence of real harm done by weakening encryption.

Re: The DROWN Attack

#49

Post by pfg »

cjbprime wrote: post #38
Mojah wrote: post #18

Oh come on, it targets SSLv2. You better have a _damn_ good reason for still having SSLv2 enabled on your systems. If you didn't, you had this one coming.

> Oh come on, it targets SSLv2. You better have a _damn_ good reason for still having SSLv2 enabled on your systems. "Unfortunately, during our experiments we discovered that OpenSSL servers do not respect the cipher suites advertised in the ServerHello message. That is, the client can select an arbitrary cipher suite in the ClientMasterKey message and force the use of ex- port cipher suites even if they are explicit…

I think it's a little bit more complicated than that, and depends on how SSLv2 was disabled.

From the OpenSSL 1.0.2f release notes:

  SSLv2 doesn't block disabled ciphers

  A malicious client can negotiate SSLv2 ciphers that have been disabled on
  the server and complete SSLv2 handshakes even if all SSLv2 ciphers have
  been disabled, provided that the SSLv2 protocol was not also disabled via
  SSL_OP_NO_SSLv2.
So if you disabled all SSLv2 ciphers, but didn't actually disable SSLv2 itself, you could still complete a SSLv2 handshake. If your server software disables SSLv2 via SSL_OP_NO_SSLv2, then you're fine. This seems to be the case for (at least) nginx, based on how I read the code.

Re: The DROWN Attack

#50

Post by Steuard »

skywhopper wrote: post #19

So, disable SSLv2. That is not new information. I like how the FAQ insists you are still at risk if you've disabled SSLv2 because you still might be using it somewhere else!!! In other words, if you've not disabled SSLv2 everywhere, then there are still places where SSLv2 is enabled. Thank you.

I expect you already understand this, but to be clear: the risk appears to be that even one forgotten old server (or service) running SSLv2 can put your up to date, highly secure servers at risk (if you've shared keys between them).

To my eye, the way you've phrased it here could be read to imply "any server with SSLv2 disabled is safe". The linked report says this is incorrect, and its inaccuracy is responsible for roughly half of the vulnerabilities that they have observed.

Post reply on HN