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.
Re:Ironic (Score:5, Insightful)
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"?
Re:Things are starting to turn around (Score:5, Insightful)
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.
Re:Things are starting to turn around (Score:5, Insightful)
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.
Yet again C bites us in the ass (Score:5, Insightful)
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.
Re:Things are starting to turn around (Score:5, Insightful)
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...
All these bugs are mind blowing (Score:4, Insightful)
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...
Re:It's really annoying (Score:4, Insightful)
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.
Re:Yet again C bites us in the ass (Score:2, Insightful)
Because "bounds checking" is no silver bullet - it's an artificial limitation that DOES slow things down, unlike seatbelts and airbags, which have infinitesimal impacts on vehicle performance.
That's not true. Safety features like seatbelts, airbags, roll cage, etc. add an appreciable amount of weight to the car. "some hypermilers take it to the extreme, removing important safety features like rearview mirrors or even the car's airbags." [howstuffworks.com]
Either that, or you're too stupid to program successfully in C.
Apparently so are the OpenSSL developers, and all the other people who have been bitten by bounds errors over the years. Too bad there's no operating system written by perfect beings.
Re:Not necessarily known since 2012 (Score:5, Insightful)
Context: "Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. "
After so many years of this shit, it has to be intentional, just so people will post corrections.
Re:Is SSH affected? (Score:3, Insightful)
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 [freebsd.org] (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/ [comforte.com] and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl [stackoverflow.com] (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 [wikipedia.org] (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html [snailbook.com]
* ...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 [stackexchange.com]
* ...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/ [wordpress.com]
* The "heartbleed" bug, which refers to RFC 6520 [ietf.org], pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html [snailbook.com] (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
Re:ASLR anyone? hype? (Score:5, Insightful)
Older Versions Safe (Score:5, Insightful)
Distributions using OpenSSL 0.9.8 are not vulnerable
This is why I haven't upgraded my Linux servers in 23 years.
Re:Gee, that's worse than no encryption isn't it? (Score:4, Insightful)
"known for 2 years"
No, no, this has been the code part of the stable release of OpenSSL for 2 years. The bug has only been known by non-blackhats for up to a few weeks.
If anyone else like a blackhats or NSA or whoever knew about the bug before hand, we don't know.