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.
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"?
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.
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.
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)
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...
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.
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.
Distributions using OpenSSL 0.9.8 are not vulnerable
This is why I haven't upgraded my Linux servers in 23 years.