Slashdot Mirror
OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks
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.
"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!
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.
Someone had to do it.
Now how are we supposed to collect people's private information without their knowledge? Think of the children and all of the terrorists captured with this exploit in the wild!
sincerely,
NSA
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Never trusted openssl - only use GnuTLS.
http://www.theregister.co.uk/2...
Irony rears it's head on the day that patches for a Linux vulnerability are announced at the same time Microsoft ends its patching and update service for Windows XP.
How is a vulnerability in OpenSSL, which is a library that can be compiled for multiple platforms, a "Linux vulnerability"?
can someone link to the git blame of the bug please?
Is there anyone on the planet using TLS heartbeats via TCP for anything except exploiting this bug? What is even the point of heartbeats without DTLS?
Bugs are bugs yet decision to enable a mostly useless feature for non-DTLS by default in my view is not so easily excusable.
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
NSA, I am sure, know plenty of holes — if not custom-made by the authors doors — into proprietary software too.
I am disappointed at the quality of open source software — especially pieces as famous and fundamental as OpenSSL, and I agree, that open source's claimed advantage of there being "thousands of eyeballs" verifying its correctness is overblown.
But to declare it to be "losing" is a silly jump just as far in the direction opposite to the enthusiastic proclamations of the above mentioned ideology-driven advocates.
In Soviet Washington the swamp drains you.
Any data kept in RAM on an open-ssl box has probably been compromised. It sounds like that includes private keys, root certs, passwords, etc.
This is why passwords etc should be encrypted in RAM. It's funny, there's a Security Technical Implementation Guides (STIG) on that very item. It always sounded sort of ridiculous, but now I know why it was there.
But the actual announcement is not among them.
https://www.openssl.org/news/secadv_20140407.txt
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
No, you got it quite right. A server could grab browsing history, JS memory contents, stored passwords, and authentication cookies from a browser. It's not just web browsers, though; a malicious server could also steal email (from other email accounts) out of a mail client, and so on. For the handful of services that use client certificates, a server could steal the *client's* secret key.
Browsers (or other clients) that use multiple processes have some degree of safety, as this exploit can't read across process boundaries. It's also completely passive; just because every Chrome tab *can* get the cookies that are currently being used in every other Chrome tab doesn't mean that they are always loaded in each tab's process' address space (though I don't know if they are in practice or not).
Still, this is a grade-A clusterfuck security-wise. The ability for an unauthenticated attacker (all you need is an open TLS connection; that could be the login screen) to read memory off the other side of the connection is the kind of exploit you can make movie-grade "hacker" scenes out of. For a simple example you might see somebody pulling, you could use this exploit to decrypt any connection you recorded, assuming the server hadn't rotated its private key since then. If you can be fast enough and are in an intercept (MitM) position rather than just monitoring passively, you could even grab the keys in real-time and have complete control, invisibly, over the connection. From there, you could even read memory from the client and (continue reading from) the server at the same time!
You could probably do it automatically using a Raspberry Pi hiding behind the flowerpot in a café. I'm not joking.
I've been in the security world for years and I don't think I've ever seen so bad a vuln. Yes, things like "goto fail" were mind-blowingly stupid, but they still only let you MitM connections if you were in the right place at the right time. This one is strictly better and enables a huge number of alternative attacks.
There's no place I could be, since I've found Serenity...
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
It's not the fix of the code that's messy. It's the fix of the trusts using that code to function. They are all broken. After the upgrade keys need to be replaced, certificates re-issued, endpoints and clients reconfigured to trust new keys, and in some cases customers and end-users may need to be involved. For anything of CDE level security or higher, it's as big a cleanup job than the one that gave us openssl-blacklist, but the blacklist for this would be neither complete nor easy to assemble.
I predict a lot more interest in turning on CRL pathways in the future.
Someone had to do it.
Good thing I use WIndows, so I'm safe.
Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.
But hey, it's faster.
Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.
Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?
As long as all our personal information relies on really smart people who never make mistakes, we're doomed.
Natural != (nontoxic || beneficial)
*air-punch*
I knew procrastinating Debian upgrades for most of a decade would pay off! I am VINDICATED!
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
...
systemd devs seem bound and determined to prove you wrong there...
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.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
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.
But, regardless of the root cause (intentional malice or just sloppiness) I'm glad eyes have been checking these code bases with more diligence over the past several months. In the end it means more security for us users, regardless of our platform of choice.
Thank you again, Edward Snowden, for the collective wake up call!
Now if we could just get our governing officials to fix some of these egregious laws...
#DeleteChrome
There may seem to be more now because there is more auditing going on since the NSA revelations reminded people what had to be done, and also the slower trend of case law starting to punish mishandling of customer data. The halcyon days are over and the backlog is being cleared up.
Someone had to do it.
RHEL updates are available:
https://rhn.redhat.com/errata/RHSA-2014-0376.html
CentOS updates are available:
http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html
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
https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html
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/
There's no place I could be, since I've found Serenity...
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.
Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:
* OpenSSH links to the libcrypto.so shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/libcrypto.so.X (you'll find OpenSSL references in there). Truth: because OpenSSH links to a cryptographic library that's part of OpenSSL doesn't mean it's necessarily using the code that's bugged (see below poster's sig and note function names are DTLS-related (keep reading)), but it also doesn't mean it isn't. When was the last time you ran truss/strace with all flags (for children, all syscalls, fd I/O, etc.) and looked at it closely?
* SSH, as a protocol, is not SSL (but keep reading): http://www.comforte.com/solutions/tls-vs-ssh/ and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl (see replies to primary thumbs-up'd answer)
* However, SSH does rely on at least some part of TLS, the one that's known is X.509 (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html
* ...but then things like this seem to imply the OpenSSH folks don't use X.509 at all and that you have to run a special OpenSSH build for this to work: http://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication
* ...but then you find things like this which are open-ended and seem to imply otherwise (and the link mentioned on that blog, by the way, is also worth skimming/reading to see what's being done): http://trueg.wordpress.com/2012/09/06/use-an-x-509-certificate-for-ssh-login/
* The "heartbleed" bug, which refers to RFC 6520, pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html (yes same link)
* There are repeated/continual news references to "use of X.509" (which could apply to either SSH or SSL from the above references) in every single news announcement. I shouldn't need to link them all.
There is nothing even remotely definitive on either the OpenSSL or OpenSSH mailing list, and that's a bit shocking if you ask me. Therefore, to me, the OP's question is quite valid.
Does the answer to his/her question change the severity of the situation? Yes it does. Yes you should still upgrade OpenSSL, but what some of us senior system administrators are trying to figure out is whether or not we need to inform every employee that they need to generate new SSH keys. I think everyone at this point is aware webservers (ex. nginx, Apache, etc.) doing SSL need to have OpenSSL upgraded + the daemons restarted + keys re-generated + re-signed, but the concern here is whether or not any part of OpenSSH's function calls into the OpenSSL crypto library rely on anything related to RFC 6520.
My opinion: the reason nobody has definitive answer with references (and I hope this Slashdot post induces such) is because there's a serious disconnect between using security-focused software (end-users, SAs, companies using security software, etc.), the writing of cryptographic algorithms (cryptologists), and ac
This is a read overrun, so ASLR won't save you. Ignore the guy above who posted about ASLR bypasses--that's not really relevant to this.
Silly, all "Open*" projects are owned by OpenBSD. Like OpenGL. And OpenOffice. :p
I read TFA and all I got was this lousy cookie
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.
Distributions using OpenSSL 0.9.8 are not vulnerable
This is why I haven't upgraded my Linux servers in 23 years.
Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability 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!
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
This bug is almost 10 years old
Well look who natively counts in binary.
Hello Joshua! Give my regards to Dr Falken.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC