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

51–60 of 206 posts

Re: The DROWN Attack

#51

Post by drewcrawford »

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)

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

Re: The DROWN Attack

#52

Post by cjbprime »

fulafel wrote: post #37

Quote from paper: "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 export cipher suites even if they are explicitly disabled in the server configuration. The SSLv2 protocol itself was still enabled by default in th…

Yes, seems that way.

Re: The DROWN Attack

#53

Post by PakG1 »

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.

Honestly, I think that would require a generation or two of a modified education system to bring about the desired result. You gotta deal with the here and now sometimes.

Re: The DROWN Attack

#54

Post by cjbprime »

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?

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

Re: The DROWN Attack

#57

Post by tptacek »

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…

It's not enough to not run SSLv2 on the target; SSLv2 can't be available on any server that shares the same RSA keypair. It's a cross protocol attack, where attackers use the SSLv2 server as a tool to attack the TLS server.

Re: The DROWN Attack

#58

Post by laumars »

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.

> But Heartbleed was the first one

Perhaps with a logo - I never really pay much attention to logos - but it wasn't the first to have an accessible name. Just off the top of my head I can name 3 SSL vulnerabilities that predated Heartbleed: BEAST, CRIME, BREACH.

Personally I can't see how having a logo changes much in terms of press coverage since radio and printed newspapers tend not to publish the logos, online publications have a large resource of stock images they can use (eg Getty) and the TV would likely want video footage anyway.

I think the nature of the bug with Heartbleed also played an important factor in it's coverage. It was quite a simple exploit to explain to the lay-person (albeit imprecisely) when compared to BEAST, CRIME, BREACH, POODLE, etc which require a much greater understanding of SSL/TLS. We do see other unbranded exploits are reported by the mainstream media, such as websites being hacked, DDoS attacks, etc, and in all of those instances the content is easily communicated in a 30 second soundbite.

Re: The DROWN Attack

#59

Post by pfg »

PythonicAlpha wrote: post #42
pfg wrote: post #40

Earlier quoted context omitted.

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

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

Re: The DROWN Attack

#60

Post by tptacek »

ColinDabritz wrote: post #48

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.

The attack is viable without export ciphers. The real issue here is the continued and unabated prevalence of PKCS#1 v1.5 padding (really, of RSA in general).
Post reply on HN