OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks 303
Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012."
Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.
Gee, that's worse than no encryption isn't it? (Score:5, Informative)
"We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."
Yikes. And it's been known for 2 years. That's some shit!
Not necessarily known since 2012 (Score:5, Informative)
Who knows who knew what and when, but the 2012 statement is a misinterpretation of TFA where they seem to be saying it essentially started "hitting the shelves" in distros about then, whereas before then it was mostly only distributed in beta builds and head code.
Re:Chrome's SSL uses a lot of the OS certificate m (Score:4, Informative)
My understanding is that Chrome and Mozilla both use NSS. It's a bit outdated, so I could be wrong (given that Google forked webkit, I can imagine them forking NSS too).
Actually, with a quick Google search, it seems that Chrome on Android uses (used?) OpenSSL for certain functions. I'm curious to know if secure communication via Android devices can be compromised via those functions. At first glance, I'd say no, but I don't have enough domain knowledge to make this assertion.
NSS is thus far secure, but I really, really would like to see the results of multiple full and independent audits. If there's a problem in NSS, that would be about as big as it can get.
Like I said, it's a bit frightening that there are such large and somewhat obvious holes in these major crypto libraries found within three months of each other, but it's good to know that they're being found and fixed.
original eyeballs meant the FIX to a known bug (Score:4, Informative)
On a side note, regarding advantage of there being "thousands of eyeballs" verifying its correctness" -
ESR's famous quote is "with enough eyeballs, all bugs are shallow - the fix will be obvious to someone."
The quote doesn't say anything about correctness. It says that when strange behavior is noticed, someone will see a clear fix. A shallow bug is one that's right there on the surface, where you can see the source of the problem. That's in contrast to one where you have to spend hours searching for what's causing the problem. It makes no claim of how quickly or easily a bug will be discovered - just how it can be fixed once it's discovered.
RHEL / CentOS / Fedora updates now available (Score:5, Informative)
RHEL updates are available:
https://rhn.redhat.com/errata/RHSA-2014-0376.html [redhat.com]
CentOS updates are available:
http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html [centos.org]
Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:
https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html [fedoraproject.org]
https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html [fedoraproject.org]
Minimal jargon explanation (Score:5, Informative)
Basically, an attacker can connect to many secure Internet services - could be a banking website, or your email server, or a server hosting software updates, or possibly your corporate VPN - and learn everything that the server knows. This includes the private key (sort of like a super-complex and super-secret password) that is used to *make* the service secure. The attacker can then get all the data that the server sees, ranging from normal user passwords to all your emails and banking info.
This vulnerability is many, many kinds of bad. I'm simplifying a lot here. Basically, an awful lot of data is at risk right now, because of this bug.
This site has a pretty great explanation that most people likely to be found on /. will be able to follow, even if not normally security types: http://heartbleed.com/ [heartbleed.com]
Re:Is SSH affected? (Score:4, Informative)
OpenSSH uses the libcrypto portion of OpenSSL for crypto primitives. It does not use TLS, and therefore SSH is not vulnerable to this attack.
Shut the fuck up when you don't know what you're talking about.
Re:Gee, that's worse than no encryption isn't it? (Score:2, Informative)
Existed != Known. Unknown if known until now.
Re:git blame of the bug please (Score:5, Informative)
There's an analysis of the bug here [existentialize.com].
Re:I take it this is a server concern (Score:5, Informative)
I don't think Chrome uses OpenSSL, although they are thinking about switching to it. They use NSS, same as Firefox. I'm not sure any browsers use OpenSSL - it's mostly used on the server.
Re:Is this for real? (Score:3, Informative)
It's disabled in the base system OpenSSL in FreeBSD, so it can't be that critical.
Incidentally, that also means that the summary is ... imprecise: FreeBSD, by default, isn't vulnerable to this. If you have OpenSSL from ports installed, it is - though that also means the fix is a simple package/port upgrade. (The fixed version is in ports already, and packages are, I believe, being built.)
Re:Is SSH affected? (Score:2, Informative)
OpenSSL does many things.
It is both a crypto library (Access to ciphers) and a TLS protocol implementation, amongst other things (eg: PKI implementation)
This OpenSSL bug is in the TLS protocol implementation. TLS heartbeat is an optional extension to TLS.
OpenSSH uses the crypto library component for access to ciphers.
As OpenSSH does not use TLS, I can't fathom any reason it would be vulnerable to this particular bug.
Quick test shows Yahoo user passwords (Score:5, Informative)
Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability [filippo.io] is quite an eye opener. As well as telling you whether the server is vulnerable, it displays a small snippet of the memory it retrieved (there are scripts on Github that will show you the whole 64KB I believe).
In the quick tests I did on login.yahoo.com (used for Yahoo's email and probably all other Yahoo services), I saw three different user's passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!
Re:ASLR anyone? hype? (Score:4, Informative)
Read or write overruns will only throw an exception if they go beyond the bounds of the applications total allocated memory so they hit an unallocated page. (page fault)
If you simply read into some memory that has been allocated by some other component, no exception will be thrown.
Reading outside the bounds of the application application pages is unlikely as you'd have to be the last or close to the last allocated block (when the application space has to be grown, doesn't work if its a realloc of a previously allocated page, so lower in the address space and not near the end of allocated pages) and/or have a large overrun so you went through all the other allocated blocks.