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.

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

  3. RHEL / CentOS / Fedora updates now available by seifried · · Score: 4, Informative
  4. 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...
  5. 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.

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

    There's an analysis of the bug here.

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

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