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

61–70 of 89 posts

Re: OpenSSL Security Advisory

#61

Post by aendruk »

dorfsmay wrote: post #42
reaperhulk wrote: post #11

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

Anybody know what the difference is between Ubuntu package openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4

This page [1] links to the package's changelog [2], which should answer your question.

[1]: http://packages.ubuntu.com/saucy/openssl

[2]: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...

Re: OpenSSL Security Advisory

#62

Post by agwa »

peterwwillis wrote: post #52
syzzer wrote: post #44

Earlier quoted context omitted.

You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do). OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is…

Since tls-auth merely creates an HMAC around all the TLS message types, it makes me wonder if there's still an aspect of initiating a TLS connection (or flaws in the HMAC generation?) that could leave tls-auth vulnerable to future TLS-related flaws. But that could be excessive paranoia.

I think that whether tls-auth protects you against CCS Injection will hinge not on the HMAC but on tls-auth's replay protection. An attacker can always replay a previously-sniffed CCS packet with a valid HMAC, so it all comes down to whether that replay will be properly discarded.

Re: OpenSSL Security Advisory

#63

Post by e12e »

thegeomaster wrote: post #43
mnw21cam wrote: post #18

Earlier quoted context omitted.

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.

Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.

Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)?

And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot...

Reminds me that I had an idea to wrap up some kind of hot-spot with an easy to use internet cafe style time-limited access software distribution and offer up to local businesses... I suppose these days providing a screen for qr-code sharing of details would be a viable option...

Re: OpenSSL Security Advisory

#64

Post by apendleton »

e12e wrote: post #63
thegeomaster wrote: post #43

Earlier quoted context omitted.

Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.

Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)? And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot.…

To make them immune to the ARP spoofing in the general case is hard, but as I understand it, to make them immune to the specific case of clients other than the gateway impersonating the gateway (which is what people want to do for most MitM) is pretty straightforward. The access point is probably itself the gateway most of the time, so it knows the gateway's MAC (its own), and it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway.

Re: OpenSSL Security Advisory

#65

Post by [deleted] »

e12e wrote: post #63
thegeomaster wrote: post #43

Earlier quoted context omitted.

Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.

Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)? And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot.…

[deleted]

Re: OpenSSL Security Advisory

#66

Post by thegeomaster »

e12e wrote: post #63
thegeomaster wrote: post #43

Earlier quoted context omitted.

Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.

Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)? And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot.…

With Wi-Fi, the AP knows the physical addresses of its connected clients because it needs them in order to maintain 802.11 state. A solution would be to keep a MAC-IP mapping table and then refuse to deliver any ARP packets with erroneous IPs, but keeping these mappings can be tricky because of the limited memory, and I imagine one can do something like a MAC flood. The best protection is if the clients themselves are secure, and I know some Windows antiviruses block ARP spoofing attack. MikroTik RouterOS logs you out (blocking your Internet access) forcefully when you attempt an ARP spoof with forwarding, but oops: even when logged out, you can do it and see others' outbound packets, you just can't forward them via the same interface.

Our networks are broken. Hosts trust each other, but they shouldn't--this is not ARPAnet anymore. Everything shoild be encrypted and integrity-protected from bottom-up. I don't like how these stupid LAN attacks are never mentioned but are grossly powerful because of the insecurity by design.

Re: OpenSSL Security Advisory

#67

Post by TillE »

Florin_Andrei wrote: post #59
jacquesm wrote: post #6

Earlier quoted context omitted.

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

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

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.

Re: OpenSSL Security Advisory

#68

Post by bashinator »

kerneis wrote: post #25
reaperhulk wrote: post #13

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

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

There's some good discussion of it on the netsec subreddit.

http://www.reddit.com/r/netsec/comments/27dhcn/openssl_secur...

Re: OpenSSL Security Advisory

#69

Post by JoachimSchipper »

agwa wrote: post #62
peterwwillis wrote: post #52

Earlier quoted context omitted.

Since tls-auth merely creates an HMAC around all the TLS message types, it makes me wonder if there's still an aspect of initiating a TLS connection (or flaws in the HMAC generation?) that could leave tls-auth vulnerable to future TLS-related flaws. But that could be excessive paranoia.

I think that whether tls-auth protects you against CCS Injection will hinge not on the HMAC but on tls-auth's replay protection. An attacker can always replay a previously-sniffed CCS packet with a valid HMAC, so it all comes down to whether that replay will be properly discarded.

tls-auth does prevent replays: note the "packet-id for replay protection" at http://openvpn.net/index.php/open-source/documentation/secur....

OpenVPN does a pretty good job, as long as you choose a sane configuration (most importantly, use tls-auth and TLS key negotiation). It's definitely less vulnerable than other TLS stuff due to the tls-auth option.

(Full disclosure: my company provides the hardened OpenVPN-NL, and I've done a little work on that.)

Re: OpenSSL Security Advisory

#70

Post by gonzo »

tedunangst wrote: post #36
pling wrote: post #26

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

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.

Neither of these work if SSL_MODE_RELEASE_BUFFERS is enabled, and are the only two CVEs in secadv_20140605.txt that have a dependence on SSL_MODE_RELEASE_BUFFERS.

libreSSL isn't any better on this front than OpenSSL without SSL_MODE_RELEASE_BUFFERS.

Post reply on HN