Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks

Posted by Unknown on from the check-your-bounds dept.

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.

28 of 303 comments (clear)

  1. Gee, that's worse than no encryption isn't it? by Anonymous Coward · · 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!

  2. Not necessarily known since 2012 by skids · · 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.

    --
    Someone had to do it.
    1. Re:Not necessarily known since 2012 by Bite+The+Pillow · · Score: 4, 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.

    2. Re:Not necessarily known since 2012 by FriendlyLurker · · Score: 4, Interesting

      After so many years of this shit, it has to be intentional, just so people will post corrections.

      Of course it is intentional, and yet no naming and shaming appears to be going on... why is that? Only a small handful of people are responsible for bringing this to our linux distros, and a few more responsible for keeping it there. Those people have lost the trust of the community and should never have any of their code submissions or bug priority lists accepted ever again, otherwise there is just no consequence for nefariously subverting the security of us all.

  3. Thanks Jerks by s.petry · · Score: 5, Funny

    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.

  4. No Problem Here by sk999 · · Score: 5, Funny

    Never trusted openssl - only use GnuTLS.
    http://www.theregister.co.uk/2...

  5. Re:Ironic by DigitAl56K · · 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"?

  6. git blame of the bug please by Anonymous Coward · · Score: 5, Interesting

    can someone link to the git blame of the bug please?

    1. Re:git blame of the bug please by Anonymous Coward · · Score: 5, Informative

      There's an analysis of the bug here.

  7. Is this for real? by WaffleMonster · · Score: 5, Interesting

    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.

  8. Re:Things are starting to turn around by mi · · Score: 4, Insightful

    But unfortunately open source is not written by professionals, but ideologically driven amateurs and other random hobbyists.

    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.

    Fixing this bug will be humongous amount of work, and there are likely to be even more like it in OpenSSL

    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.

    I am sure NSA know several more bugs like this that remain undisclosed.

    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.
  9. We're all fucked by mveloso · · Score: 5, Interesting

    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.

    1. Re:We're all fucked by cbhacking · · Score: 4, Interesting

      Don't just encrypt them - move them out of process entirely. Have a security broker that knows your secrets, but doesn't talk to *anything* except local clients (on the assumption that if the attacker has arbitrary code execution, it's game over anyhow). Use inter-process communication to get secrets when needed, but preferably don't *ever* hold sensitive data in memory (for example, instead of using your private key directly, you ask he broker process to sign a binary blob for you, and it does so using your key and returns just the signature). Use "secure buffers" in managed code, or "secure zero" functions otherwise, to eliminate any sensitive data from memory as quickly as possible.

      Yes, this used to sound paranoid. Actually, it still does sound paranoid. But, there's now a great example of a scenario where this is a Good Idea.

      Of course, you have to make sure that broker is Really Damn Secure. Keep its attack surface minimal, make sure the mechanism by which it identifies whose key to use is extremely robust, and if possible make it a trusted part of the OS that is as secure from tampering as possible (Microsoft already has something like this built into Windows). There's also a question of how far to take it. For example, you could have the broker handle the symmetric encryption and decryption of TLS data (the bulk data part, after handshaking is completed) but that could impact performance a lot. Keeping the symmetric key in memory isn't so bad, really; it's ephemeral. However, if an attacker has a vuln like this and wants to read the traffic of a target user, they could attack the server while the user is using it, extract the symmetric key, and use it to decrypt the captured TLS stream. Keeping the key in-memory only while actually losing and (securely) purging it between response and the next request might be a good middle ground, perhaps?

      --
      There's no place I could be, since I've found Serenity...
  10. Re:I take it this is a server concern by cbhacking · · Score: 5, Interesting

    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...
  11. Re:Things are starting to turn around by skids · · 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.

    --
    Someone had to do it.
  12. Windows by Kaenneth · · Score: 5, Funny

    Good thing I use WIndows, so I'm safe.

    1. Re:Windows by Anonymous Coward · · Score: 5, Funny

      Unfortunately it is XP, so you are safe until 12:00.

  13. Yet again C bites us in the ass by rabtech · · Score: 4, 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.

    --
    Natural != (nontoxic || beneficial)
  14. Yes!!! by Areyoukiddingme · · Score: 5, Funny

    *air-punch*

    I knew procrastinating Debian upgrades for most of a decade would pay off! I am VINDICATED!

  15. Re:Things are starting to turn around by Anonymous Coward · · Score: 5, Insightful

    But unfortunately open source is not written by professionals, but ideologically driven amateurs and other random hobbyists.

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

  16. RHEL / CentOS / Fedora updates now available by seifried · · Score: 4, Informative

    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

  17. Minimal jargon explanation by cbhacking · · Score: 4, 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/

    --
    There's no place I could be, since I've found Serenity...
  18. Re:Is SSH affected? by Anonymous Coward · · 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.

  19. Re:ASLR anyone? hype? by AlphaBro · · Score: 5, Insightful

    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.

  20. Re:Ironic by Mitchell314 · · Score: 5, Funny

    Silly, all "Open*" projects are owned by OpenBSD. Like OpenGL. And OpenOffice. :p

    --
    I read TFA and all I got was this lousy cookie
  21. Re:I take it this is a server concern by IamTheRealMike · · Score: 4, 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.

  22. Older Versions Safe by StormReaver · · Score: 4, Insightful

    Distributions using OpenSSL 0.9.8 are not vulnerable

    This is why I haven't upgraded my Linux servers in 23 years.

  23. Quick test shows Yahoo user passwords by monkeyhybrid · · Score: 5, Informative

    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!