Slashdot Mirror

← Back to Stories (view on slashdot.org)

Heartbleed OpenSSL Vulnerability: A Technical Remediation

Posted by samzenpus on from the protect-ya-neck dept.

An anonymous reader writes "Since the announcement malicious actors have been leaking software library data and using one of the several provided PoC codes to attack the massive amount of services available on the internet. One of the more complicated issues is that the OpenSSL patches were not in-line with the upstream of large Linux flavors. We have had a opportunity to review the behavior of the exploit and have come up with the following IDS signatures to be deployed for detection."

66 of 239 comments (clear)

  1. what? by Anonymous Coward · · Score: 5, Insightful

    Was this badly translated from another language, or have I been out of system administration too long?

    1. Re:what? by VortexCortex · · Score: 5, Informative

      Was this badly translated from another language, or have I been out of system administration too long?

      Allow me to translate from buzz-ard to sysopian:

      SSL-Ping Data Exfiltration Exploit: Detection and mitigation even a flaming lamer that can't patch OpenSSL can use

      "Since this 0-day vuln was published skiddies have been exploiting it to leak data available to OpenSSL 64KB at a time via running one of the pre-written exploit proof-of-concept sources (as skiddies are wont to do) against a bunch of affected Internet facing services. This SNAFU is particularly FUBAR since all the distros that noobs use are building an ancient OpenSSL ver so they can't even push out a simple patch, obviously. We fingered the exploit in use and have a signature so your punk-buster scripts can detect the crackers and ATH0 before your cipher keys get the five-finger discount."

    2. Re:what? by TheGratefulNet · · Score: 4, Funny

      let me run that thru the jive translator:

      "well, shit!" ==> "golly!"

      --

      --
      "It is now safe to switch off your computer."
    3. Re:what? by I+kan+Spl · · Score: 3, Insightful

      VortexCortex should be a slashdot editor then. That would be entertaining at least.

      --
      My UID is prime and so is this number: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0.
    4. Re:what? by Eunuchswear · · Score: 2, Informative

      If someone is using an ancient openssl library (0.9.8) they have nothing to worry about. The problem was introduced in 1.0.0

      --
      Watch this Heartland Institute video
    5. Re:what? by TCM · · Score: 2

      Wrong, in 1.0.1.

      --
      Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
    6. Re:what? by gweihir · · Score: 2

      It is some folks trying to drag IDS back out from the grave. The issue is that generally, IDS does work extremely poorly and causes extreme operations effort (somebody has to look at all the alerts). For this specific thing for once IDS can be used to detect the problem and the whole story revolves about that. Of course the approach is fundamentally flawed: If you patch management is so bad that you cannot fix all affected OpenSSL installations pretty fast, then you are doomed anyways security-wise.

      As this is pretty obvious, part of the IDS community is using deceptive and manipulative language to prop-up their meal-ticket and that is what makes the story sound so strange. The other part of the IDS community has realized that IDS as possible currently is a bad idea and has gone back to doing research on the issue. These are the hones ones that do not try to sell you an expensive box that is essentially worthless.

      That is not to say, IDS is completely worthless. If you have very specific, well-known signatures, it can help you find _old_ problems that somehow slipped by, but as such it just serves as one small element of a patch-management system.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  2. Thank you for the mess by manu0601 · · Score: 4, Insightful

    We have to thank the security researchers that chose to break the embargo on the news before OpenSSL coordinated with downstream project.

    Thank you for the mess, guys!

    1. Re:Thank you for the mess by Anonymous Coward · · Score: 5, Insightful

      To be fair, nobody knows if this was exploited in the wild or not already - so the "mess" was going to happen anyway (unless you planned to patch your server, assuming your certificate was still good, and not tell any of your users that their passwords may have been exposed in the last couple years).

    2. Re:Thank you for the mess by ChrisKnight · · Score: 4, Informative

      Sadly, this is not the case. The evidence is that bad actors had this exploit for months: http://arstechnica.com/securit...

      --
      -- This sig is only a test. If this were a real sig it would say something witty. --
    3. Re:Thank you for the mess by Midnight_Falcon · · Score: 2, Insightful

      I've read your link and can't find any statement that indicates malicious persons had knowledge of this exploit before the announcement.

    4. Re:Thank you for the mess by Midnight_Falcon · · Score: 5, Informative

      Ok, I read the wrong link from up above. This article does say as you claimed, and my above post is nonsense. :)

    5. Re:Thank you for the mess by ChrisKnight · · Score: 4, Insightful

      Midnight_Falcon, you are indeed a rare bird. :)

      --
      -- This sig is only a test. If this were a real sig it would say something witty. --
    6. Re:Thank you for the mess by phantomfive · · Score: 3, Insightful

      Wow, not at all.

      News about a vulnerability should never be delayed longer than a workaround is known. That is, if there is a way to defend your servers, you need to let people know about it so they can defend their servers. Attackers don't wait for disclosure.

      In this case, there was a simple fix, recompiling OpenSSL with the proper flag and going, so letting people know as soon as possible is the best option. Those who are serious about security don't wait for Ubuntu to update their apt servers.

      --
      "First they came for the slanderers and i said nothing."
    7. Re:Thank you for the mess by ras · · Score: 5, Informative

      For people who didn't follow the link chain, it has since been updated:

      Important update (10th April 2014): Original content of this blog entry stated that one of our SeaCat server detected Heartbleed bug attack prior its actual disclosure. EFF correctly pointed out that there are other tools, that can produce the same pattern in the SeaCat server log (see http://blog.erratasec.com/2014... ). I don't have any hard data evidence to support or reject this statement. Since there is a risk that our finding is false positive, I have modified this entry to neutral tone, removing any conclusions. There are real honeypots in the Internet that should provide final evidence when Heartbleed has been broadly exploited for a first time.

    8. Re:Thank you for the mess by davester666 · · Score: 5, Funny

      Not really. Lots of people are wrong on the internets! :-)

      --
      Sleep your way to a whiter smile...date a dentist!
    9. Re:Thank you for the mess by manu0601 · · Score: 2

      But the problem here is that no downstream distributions (either Linux or *BSD) were notified in advance. As a result there were no patch available for older versions that just had bugfixes backported, and no binary updates.

    10. Re:Thank you for the mess by phantomfive · · Score: 2, Informative

      Yes, there are some people who are incapable of compiling their own software who will have to wait until the patch comes through. Those people shouldn't be managing security for a large website (or any website really, in an ideal world).

      --
      "First they came for the slanderers and i said nothing."
    11. Re:Thank you for the mess by Fnord666 · · Score: 2

      Sadly, this is not the case. The evidence is that bad actors had this exploit for months: http://arstechnica.com/securit...

      One of the two sites cited as evidence have since taken a step back,

      Important update (10th April 2014): Original content of this blog entry stated that one of our SeaCat server detected Heartbleed bug attack prior its actual disclosure. EFF correctly pointed out that there are other tools, that can produce the same pattern in the SeaCat server log (see http://blog.erratasec.com/2014... ). I don't have any hard data evidence to support or reject this statement. Since there is a risk that our finding is false positive, I have modified this entry to neutral tone, removing any conclusions. There are real honeypots in the Internet that should provide final evidence when Heartbleed has been broadly exploited for a first time.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    12. Re:Thank you for the mess by QRDeNameland · · Score: 3, Informative

      Mark Twain, actually.

      --
      Momentarily, the need for the construction of new light will no longer exist.
    13. Re:Thank you for the mess by Pieroxy · · Score: 2

      Ubuntu did provide apt patches for all affected versions, including those not supported anymore (12.10 comes to mind). They did it right. If you had configured your security patches to install automatically, it was even transparent. I don't see a problem there.

      --
      Write boring code, not shiny code!
    14. Re:Thank you for the mess by Christian+Smith · · Score: 4, Interesting

      Yes, there are some people who are incapable of compiling their own software who will have to wait until the patch comes through. Those people shouldn't be managing security for a large website (or any website really, in an ideal world).

      Nonsense. I'd want only vendor supplied fixes applied, unless the vendor is so slow as to be incompetent (but then, why would you be using them?)

      Why? Because user applied fixes tend to be forgotten, and if the library isn't managed by the package system (you've uninstalled the package you're overwriting, right?) you might miss subsequent important updates.

      An example from a far from fuckwitted user:
      http://marc.info/?l=sqlite-use...

      Yes, the author of the SQLite library fell pray to this very issue. Let the package manager track packages.

      Of course, you could also build binary packages from source, but then that assumes the upstream source packages have been patched, or you're happy to patch the source packages yourself.

    15. Re:Thank you for the mess by Anonymous Coward · · Score: 2, Informative

      I usually agree, but this is a vulnerability where an extreme amount of damage can be avoided by taking down SSL servers as quickly as possible.

      Due to the nature of the bug, recorded traffic from up to two years ago can be decrypted if the site doesn't have PFS enabled, which most sites haven't. If you have packet dumps from the coffee shop wifi downstairs, all it takes is a little luck while running the attack on a couple of big mail providers to get the servers' private keys: Then you can decrypt everybody's mail sessions, web shopping and online banking, including user names, passwords and content, from up to two years ago! The exact nature of the bug should not have been revealed before telling everybody who's running OpenSSL 1.0.1 onward to shut down the server.

      Nobody should have kept a vulnerable SSL server running for even just a minute after the announcement. The right reaction would have been to halt the server immediately upon being told of the bug. Patching as quickly as possible is not quick enough.

      IDS patterns are pointless now: The attack is already being integrated into end user software to alert users of vulnerable sites. The servers will be hammered with this attack from thousands of IPs and the users who run these "attacks" won't even know they're doing it.

      I think most people have yet to realize the magnitude of this fuckup.

  3. IDS != Remedy by AcerbusNoir · · Score: 2

    An IDS provides the means to detect malicious patterns in traffic. It is by no mean a remedy.

  4. Situation is a Shambles by ObsessiveMathsFreak · · Score: 5, Insightful

    I'm running Linux Mint Olivia -- the next to current version -- an no openssl patch is yet available as of this afternoon. I image there are quite a few similar distros. Since I have actual work to do, and can't risk wasting two hours on a potentially borked upgrade, I'm stuck to trying not to use programs affected by the exploit for the duration.

    While something tells me this exploit is somewhat overblown, what really ticks me off is that this is all the result of delegating memory management to C pointers and basically mmap. As far as I'm concerned, in this day and age, that amounts to spaghetti code and I can't say it endears me to the reliability of openssl.

    Please, we need SSL to be secure, not fast. Just use a less efficient method to make things more secure.

    --
    May the Maths Be with you!
    1. Re:Situation is a Shambles by Anonymous Coward · · Score: 2, Informative

      You're amazingly wrong.

      http://article.gmane.org/gmane.os.openbsd.misc/211963

      This has nothing to do with unmanaged languages. It has to do with somebody actively sidestepping security devices that are already in place because they don't grok the way the world works outside of their test bench.

      What do you think Python was written in? Here's a hint, it wasn't another managed language.

    2. Re:Situation is a Shambles by The+Snowman · · Score: 4, Funny

      I agree 100%, since there have never been bugs in languages like Java.

      Also, managed languages like Java and .NET are written in other managed languages running bytecode, making them extra secure. At no time do any of these languages use libraries or environments written in lower level languages such as C++, C, or assembler. So to the GP's credit, programmers who know those languages are okay to die off since we do not need them anyway.

      --
      24 beers in a case, 24 hours in a day. Coincidence? I think not!
    3. Re:Situation is a Shambles by kiite · · Score: 5, Interesting

      This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):


      char *rec_p = record; // record pointer
      uint16_t rec_len = SSL3_RECORD_LEN; // hi! i'm ignored.
      uint16_t user_len = *(uint16_t*)rec_p; // user_len = user-supplied length
      rec_p += sizeof(uint16_t); // rec_p points to start of user payload
      char *buf = malloc(user_len); // allocate using user-supplied length
      memcpy(buf, rec_p, user_len); // copy user_len bytes from record
      reply(buf); // reply with said data

      Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

    4. Re:Situation is a Shambles by viperidaenz · · Score: 2

      Unmanaged languages have their place.
      C was designed to write operating systems.
      Java and the like are designed to write applications.

      Unmanaged languages are used to write the manages language virtual machines. You can't get away from that.

      JVM's are written in C and C++, the CLR is the same. Which managed language do you suggest to use that was not built with C?

    5. Re:Situation is a Shambles by MoonlessNights · · Score: 2

      This has little to do with any C-specific. If you were re-using a buffer in some managed runtime, you would still see the same problem.

      The problem is related to a missing check on a user-provided value. It is a pretty common kind of bug, really, since it is isn't often obvious which level of the stack was supposed to check it (hence why assertions are helpful - this would have been a crash, rather than a security hole).

      The unfortunate thing is that this kind of bug detection isn't easily automated (since it is a logical oversight, not something actually incorrect). The only reason why this one got so much attention is because so many people rely on it for, ironically, security.

      Logical oversight is not specific to one language or even kind of language so we will be fighting this kind of bug until the end of time (just like how we still deal with it in the real world - this isn't even computer-specific).

    6. Re:Situation is a Shambles by Jeremi · · Score: 4, Insightful

      It was Robin Seggelmann that submitted this bit of buggy openssl code. He either works for the NSA or is grossly incompetent...

      Or he made a dumb mistake, as 100% of programmers have done and will do again in the future. Anyone who expects programmers (even the best programmers) to never make mistakes is guaranteed to be disappointed.

      The real issue here is that the development process did not detect the mistake and correct it in a timely manner. Code that is as security-critical as OpenSSL should really be code-reviewed and tested out the wahzoo before it is released to the public, so either that didn't happen, or it did happen and the process didn't detect this fault; either way a process-failure analysis and process improvements are called for.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    7. Re:Situation is a Shambles by Raenex · · Score: 2, Interesting

      This is not a memory management issue per se, and has nothing to do with mmap or malloc.

      But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.

      Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

      It's the kind of mistake programmers make all the time in C. Sure, you can tell me battle-hardened, conscientious, professional programmers wouldn't make this mistake. Whatever, we've seen this kind of thing too many times for this sentiment to mean anything practically useful.

    8. Re:Situation is a Shambles by Jeremi · · Score: 3, Insightful

      JVM's are written in C and C++, the CLR is the same. Which managed language do you suggest to use that was not built with C?

      The point isn't to eliminate C code entirely, but to minimize the number of lines of C code that are executed.

      If (statistically speaking) there will are likely to be N memory-error bugs per million lines of C code, then the number of memory-error bugs in a managed language will be proportional to the size of the interpreter, rather than proportional to the size of the program as a whole.

      Add to that the fact that interpreters are generally written by expert programmers, and then they receive lots and lots of testing and debugging, and then (hopefully) become mature/stable shortly thereafter; whereas application code is often written by mediocre programmers and often receives only minimal testing and debugging.

      Conclusion: Even if the underlying interpreter is written in C, using a managed language for security-critical applications is still a big win.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    9. Re:Situation is a Shambles by iroll · · Score: 3, Informative

      That sounds like a Mint thing. Seriously, Debian (the great grandparent of Mint) had the patch as fast as anybody. Heck, by the time I logged into my Mac at work, MacPorts had pushed the patch.

      I wouldn't make such a sweeping statement about the "situation" when you've hitched your wagon to a project that's pulling from a project that's pulling from a project that's (etc).

      --
      Repetition does not transform a lie into the truth. - FDR
    10. Re:Situation is a Shambles by swillden · · Score: 2, Informative

      This is not a memory management issue per se, and has nothing to do with mmap or malloc.

      But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.

      No, that's not the issue, in fact there really isn't any significant pointer arithmetic used here. Yeah, it does use a bit to pull the size field out of the incoming request, but there's nothing wrong with that part of the code.

      The issue is that the code allocates a buffer of a size specified by the user, without validating it, and doesn't zero the allocated memory. Yes, many languages automatically zero heap-allocated arrays, which is good, but it's also a performance cost which is often unnecessary and there's nothing wrong (IMO) with not doing it by default. There is, however, plenty wrong with just accepting a user-provided value without validation, and with not completely overwriting heap-allocated memory before sending it.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    11. Re:Situation is a Shambles by kukulcan · · Score: 2

      The parent is right. The issue is with the memcpy(), not the malloc. Even if malloc() zeroed the memory there would still be an issue, because it is getting overwritten by memcpy. The issue is the size of the memcpy(), which is simply user-provided (up to max uint16).

    12. Re:Situation is a Shambles by Ash+Vince · · Score: 2

      That sounds like a Mint thing. Seriously, Debian (the great grandparent of Mint) had the patch as fast as anybody. Heck, by the time I logged into my Mac at work, MacPorts had pushed the patch.

      I wouldn't make such a sweeping statement about the "situation" when you've hitched your wagon to a project that's pulling from a project that's pulling from a project that's (etc).

      Interestingly our Debian servers are completely unaffected by this bug since we use Debian 6 :) Sometimes it pays to be a little behind the times.

      --
      I dont read /. to RTFA, I read /. to offend people in ignorance.
    13. Re:Situation is a Shambles by unrtst · · Score: 3, Interesting

      Add to that the fact that interpreters are generally written by expert programmers, and then they receive lots and lots of testing and debugging, and then (hopefully) become mature/stable shortly thereafter; whereas application code is often written by mediocre programmers and often receives only minimal testing and debugging.

      I'd wager that most of those writing/maintaining OpenSSL are not only expert programmers, but, overall, are more security concious than the authors/maintainers of interpreters. You point would be completely valid if the topic was some builitin board / wiki / chat program / etc. Sadly, that's not the case at hand.

  5. Re:Mountain out of a molehill by NiteMair · · Score: 5, Insightful

    Except now pretty much every affected machine needs to have its SSL certificates and private keys revoked and trashed, and new keys/certificates issued.

    In the meantime, thousands (if not millions) of sites leaked sensitive data to anyone who wanted to snoop on it.

    Yeah, no big deal, none at all...no repercussions will come of this.

  6. Re:Is OpenVPN affected? by ChrisKnight · · Score: 4, Informative

    Some versions are. The OpenVPN appliance I was running was affected, and there were no updates for it this morning so I had to kill it.

    https://security.stackexchange...

    I read somewhere that there is a TLS flag you can use in the config to disable the affected code, but for the life of me I can't find it for this post. :(

    --
    -- This sig is only a test. If this were a real sig it would say something witty. --
  7. Re:What version does OpenBSD use? by Phs2501 · · Score: 5, Informative

    Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action...

    Theo claims OpenSSH is unaffected, because it isn't. OpenSSL, even on OpenBSD, is quite affected.

  8. Coding Style versus Language by nanolith · · Score: 5, Insightful

    There is well written C, and there is poorly written C. I've been through the bowels of OpenSSL, and there are parts of it that frighten me. Ninety percent of the issues in OpenSSL could be solved by adopting a modern coding style and using better static analysis. While static analysis tools can't find vulnerabilities, they can root out code smell that hides vulnerabilities. If, for instance, I followed the advice of two of the quality commercial static analyzers that I ran against the OpenSSL code base, I would have been forced to refactor the code in such a way that this bug would have either been obvious to anyone casually reviewing it, if the refactor did not eliminate the bug all together.

    C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.

    1. Re:Coding Style versus Language by nanolith · · Score: 2

      I meant that the refactor would make the bug obvious. However, as is the case with any bit of refactoring, one often finds bugs, writes test cases to capture these bugs, and then comes back to eliminate them. While the pedantic would argue that refactoring keeps functionality the same, refactoring is just one step in a larger process of code stewardship that includes the isolation and elimination of bugs. When a refactor makes a bug obvious, I contend that the refactor helps to eliminate that bug.

      Either way, you are correct: refactoring does not fix bugs. But, in the larger sense, it brings them to light.

    2. Re:Coding Style versus Language by MoonlessNights · · Score: 2

      In my experience, focusing on "coding style" makes code quality drop since it creates a culture where "review" is simply making sure you dotted the i's and crossed the t's without actually reading the sentence.

      If there is one common belief held by all developers it is that their style is "correct" while everyone else is "wrong". The only difference is now the define wrong: "ugly", "inconsistent", "unclear", "confusing", "hard to maintain", "brittle", etc. If you want to see what they actually mean, ask them to quantify the problem and they will either get to the point or get very aggressive.

      At the end of the day, understanding the logical idea behind the code is the most important thing followed by the correct translation of the idea into a sequential language.

      While I don't like the OpenSSL style, personally, I don't see it as being related to this problem.

    3. Re:Coding Style versus Language by nanolith · · Score: 5, Insightful

      Style, or the lack thereof, is absolutely related to this issue. It created the festering environment that this bug hid in for two years before it was discovered.

      Style is about more than pretty print formatting. It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado. You may not appreciate the need for good style yet, but I bet you that the OpenSSL team is rethinking this now. To know that such a sophomoric mistake lingered for two years, even though hundreds of eyes passed over that code, is the epitome of why good programming style matters. The people who looked at this code are likely much smarter than you or I. They could not follow the logic of this code, because their eyes glossed right over this glaring bug. That's bad style. Everything else is window dressing.

  9. Re:Is OpenVPN affected? by Ingenium13 · · Score: 4, Informative

    I think if you had enabled the tls-auth option it prevents the attack.

  10. Re:Mountain out of a molehill by dreamchaser · · Score: 2

    Nope. I am a senior engineer for an IT security firm. I fix this shit for a living, thank you.

  11. Re:Mountain out of a molehill by Anrego · · Score: 4, Informative

    It's not easy to fix leaked data.

    You can revoke keys, change passwords, and patch the software, but you can't revoke the data that was already sent with them (and can now be decoded) no more than you can you revoke the bits of data that could have been stolen.

  12. Re:Mountain out of a molehill by bloodhawk · · Score: 4, Informative

    trivial? excellent then you can show us how to trivially identify what data has been leaked/exposed and what needs to be reported to the various authorities that require reports on exposed privacy data.

  13. Re:Mountain out of a molehill by dreamchaser · · Score: 4, Insightful

    I think you completely missed my point. The hand wringing is useless. Fix it, mitigate it, and try to move on. Any damage that has been done is one. All that cane be done now is to patch and mitigate. All the wrangling going on on the 'net is amusing. The past can't be changed. We can learn from it and move on. There are plenty of ways to stop the bleeding. People are acting like the sky is falling. It's truly sad that you're one of them.

  14. Re:OSX not affected? by Iarwain+Ben-adar · · Score: 2

    Phew. At least 2 websites are safe!

  15. Re:Is there a way to tell? by Riddler+Sensei · · Score: 4, Informative

    Qualys SSL Test is including a flag for Heartbleed vulnerability and auto-fails any domain tested that is affected.

  16. Re:What version does OpenBSD use? by Anonymous Coward · · Score: 5, Interesting

    That's good post. I'm going to blatantly copypaste it because Theo gets to the crux of why Openssl is terrible:

    From: Theo de Raadt cvs.openbsd.org>
    Subject: Re: FYA: http://heartbleed.com/
    Newsgroups: gmane.os.openbsd.misc
    Date: 2014-04-08 19:40:56 GMT (1 day, 6 hours and 15 minutes ago)

    > On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
    > > nobody gmail.com> writes:
    > >
    > >> "read overrun, so ASLR won't save you"
    > >
    > > What if malloc's "G" option were turned on? You know, assuming the
    > > subset of the worlds' programs you use is good enough to run with that.
    >
    > No. OpenSSL has exploit mitigation countermeasures to make sure it's
    > exploitable.

    What Ted is saying may sound like a joke...

    So years ago we added exploit mitigations counter measures to libc
    malloc and mmap, so that a variety of bugs can be exposed. Such
    memory accesses will cause an immediate crash, or even a core dump,
    then the bug can be analyed, and fixed forever.

    Some other debugging toolkits get them too. To a large extent these
    come with almost no performance cost.

    But around that time OpenSSL adds a wrapper around malloc & free so
    that the library will cache memory on it's own, and not free it to the
    protective malloc.

    You can find the comment in their sources ...

    #ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just

    OH, because SOME platforms have slow performance, it means even if you
    build protective technology into malloc() and free(), it will be
    ineffective. On ALL PLATFORMS, because that option is the default,
    and Ted's tests show you can't turn it off because they haven't tested
    without it in ages.

    So then a bug shows up which leaks the content of memory mishandled by
    that layer. If the memoory had been properly returned via free, it
    would likely have been handed to munmap, and triggered a daemon crash
    instead of leaking your keys.

    OpenSSL is not developed by a responsible team.

  17. Re:Is there a way to tell? by Anonymous Coward · · Score: 2, Informative

    http://filippo.io/Heartbleed/

  18. Several! by cbhacking · · Score: 4, Informative

    There have been a number of sites.
    SSLLabs scanner has been updated to check for Heartbleed, and also will report when the cert validity starts (handy if you want to see whether they're using a new cert). https://www.ssllabs.com/ssltes...
    LastPass has a pretty decent scanner that just focuses on Heartbleed (without all the other info that you get from SSLLabs): https://lastpass.com/heartblee...
    There are some others out there as well, of course.

    There's even one for client-side testing (almost as critical):
    Pacemaker is an awesome little POC script (python 2.x) for testing whether a *client* is vulnerable (many that use OpenSSL are...). https://github.com/Lekensteyn/...

    --
    There's no place I could be, since I've found Serenity...
  19. Re:Is there a way to tell? by vic-traill · · Score: 2

    The only client side tool I've encountered is at http://filippo.io/Heartbleed/ Can't speak to the implementation or even if it actually checks. But it purports to check in real time and if you trust it you can check sites prior to changing passwords.

    --
    [17] Leary, T., White, C., Wood, P. R., Bhabha, W. D., and Wirth, N. Lambda calculus considered harmful. In Proceedings
  20. Not exactly a molehill. by kiite · · Score: 2

    There are many organizations that not only can't patch, do not know how to patch, or simply haven't completed patching, but also don't _have_ an IPS or IDS in place. In fact, even if a company is in a position (and has the know-how) to install one, using either one of these options may come with what is perceived as an unacceptable performance impact.

    I managed to write an exploit for this issue within about 30 minutes. The bug is almost trivial to exploit. In my meager tests, i gathered usernames, passwords, session cookies, and oauth2 client tokens from an unrelated location on the internet. So, yes, i'd say the issue leans a bit closer to mountain than molehill.

    That said, the fix is also trivial, and the fact that several distributions still don't have updated packages is downright embarrassing.

  21. Re:Mountain out of a molehill by kiite · · Score: 5, Interesting

    It's worse than that. Most browsers don't check certificate revocation lists, and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.

    Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.

    Web-SSL was already a broken system. Now that it's been cracked open even wider, maybe we can throw it out and implement something better.

    Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.

  22. Reality Check. The sky is not falling. by thesandbender · · Score: 4, Informative

    One of my current roles is to provide technical support/advice for a group of project managers and business analysts. This morning a few of them had watched the Crash News Network over breakfast and came in convinced that privacy, as we know it, had come to an end. My job is to talk them off the ledge (and I actually enjoy it, they're smart people and as long as I explain it correctly, they get it... I've found that's pretty rare).

    1. The issue only exposes 64k at a time. Let's assume that the average enterprise application has at least a 1G footprint (and that's actually on the low end of most applications I work with). That's 1,048,576K. At best, this means that this exploit can access 0.006% of memory of an applications memory at one time.

    Ahh you say, I will simple make 16,667 requests and I will retrieve all the memory used by the application.

    2. The entire basis of this issue is that programs reuse memory blocks. The function loadAllSecrects may allocate a 64k block, free it and then that same block is used by the heartbeat code in question. However, this code will also release this same block which means that the block is free for use again. Chances are very good (with well optimized code), that the heartbeat will be issued the same 64k block of memory on the next call. Multi-threaded/multi-client apps perturb this but the upshot is that it's NOT possible to directly walk all of the memory used by an application with this exploit. You can make a bazillion calls and you will never get the entire memory space back. (You're thinking of arguments to contrary, your wrong... you wont.)

    Congratulations, much success... you have 64k internet.

    3. Can you please tell me where the passwords are in this memory dump:

    k/IsZAEZFgZueWNuZXQxFzAVBgNVBAMTDk5ZQ05FVC1ST09ULUNBMB4XDTEwMDMw
    MzIyNTUyOFoXDTIwMDMwMzIyMTAwNVowMDEWMBQGCgmSJomT8ixkARkWBm55Y25l

    There will be contextual clues (obvious email addresses, usernames, etc) but unless you know the structure of the data, a lot of time will be spent with brute force deciphering. Even if you knew for a fact that they were using Java 7 build 51 and Bouncy Castle 1.50, you still don't know if the data you pulled down is using a BC data structure or a custom defined one and you aren't sure where the boundaries start and end. The fact that data structures may or may not be contiguous complicates matters. A Java List does not have to store all members consecutively or on set boundaries (by design, this is what distinguishes it from a Vector).

    Long story short. Yes, there is a weakness here. However, it's very hard to _practically_ exploit... especially on a large scale (no one is going to use this to walk away with the passwords for every gmail account... they'd be very, very lucky to pull a few dozen).

    This doesn't excuse developers from proper programming practices. It's just putting "Heartbleed" in perspective.

  23. Re:Mountain out of a molehill by Anonymous Coward · · Score: 5, Informative

    I work for a large financial organization. While fixing the hole itself was easy- having to tell a bunch (I can't even legally give you a ballpark, but its a lot) of customers to change their passwords (or forcing them to change) is very bad PR. Plus we don't know if any financial data was accessed. The data could literally bankrupt very large companies or my own company. This is no small problem!

  24. Re:it's all over by VortexCortex · · Score: 2

    Back in my day this wouldn't have been an issue since we ran a host of different custom interfaces and clients. We had to organize our own cross country backhaul via overlapping local calling networks, and orchestrated email routing networks using outdials. Probably only hackers used clients with encrypted links for their BBSs.

    I don't know what you're talking about with that fed-speak. I never heard of any crazy lossy crap like duct-taping payphones together neither, but there may have been a few railroad tracks used as a transmission lines, or party-numbers as hubs to spook the ghost-busters at their own game, but those were just urban legends, of course.

  25. IDS signatures might not work in all cases by mysidia · · Score: 2

    While the proof of concept exploit used an unencrypted attack, the vulnerability can still be exploited AFTER the session is encrypted.

    Since the IDS probably cannot decrypt the SSL connection... it is unlikely to detect an attack that occured after encryption was negotiated, and the extension message is invisible to the IDS

  26. Re:Reality Check. The sky is not falling. by viperidaenz · · Score: 2

    But you know the vulnerable host is running OpenSSL 1.0.1 -> 1.0.1f, so you can look at the source code to figure out what the memory around the private key is supposed to look like.

  27. Re:Reality Check. The sky is not falling. by pop+ebp · · Score: 5, Informative
    I am tired of people downplaying the severity of this bug.

    Can you please tell me where the passwords are in this memory dump ...

    Have you ever seen a real exploited piece of data?
    These are taken from Yahoo production servers, a day or two ago:

    http://cdn.arstechnica.net/wp-...
    http://cdn.arstechnica.net/wp-...

    Can you guess where the password is, now? (And those didn't even take that many tries)

    I have not seen actual SSL private keys floating around just yet, but given that the original researchers said they managed to get private keys from their own servers, I think it is reasonable to assume that some production servers must have already leaked them.

  28. Re:it's all over by oreaq · · Score: 2

    It will be indistinguishable from today's cable TV.

  29. Re:Mountain out of a molehill by Dagger2 · · Score: 2

    You can't unsend that data, but perfect forward secrecy means that old data can't be decrypted even if the SSL key leaks, and new data can only be decrypted with an active MITM.

    ...if only people would actually turn it on.

    Of course, this particular vulnerability is even worse than just exposure of on-wire traffic. It also exposed potentially anything in memory for the past two years, including the things you didn't even want to send to other people -- and it exposed them to anybody on the internet, not just people in a position to capture all your traffic. Patching your copy of OpenSSL is certainly trivial, but dealing with all the rest of the fallout from this is most definitely not.