Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Bug

Heartbleed OpenSSL Vulnerability: A Technical Remediation 239

Posted by samzenpus 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."
This discussion has been archived. No new comments can be posted.

Heartbleed OpenSSL Vulnerability: A Technical Remediation More

Heartbleed OpenSSL Vulnerability: A Technical Remediation

Comments Filter:

  • what? (Score:5, Insightful)

    by Anonymous Coward on Wednesday April 09, 2014 @07:51PM (#46709993)

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

    • Re:what? (Score:5, Informative)

      by VortexCortex ( 1117377 ) <VortexCortex@[ ] ... m ['pro' in gap]> on Wednesday April 09, 2014 @10:27PM (#46710869)

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

    • Re: (Score:3)

      by gweihir ( 88907 )

      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

  • Thank you for the mess (Score:5, Insightful)

    by manu0601 ( 2221348 ) on Wednesday April 09, 2014 @07:58PM (#46710037)

    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!

    • Re:Thank you for the mess (Score:5, Insightful)

      by Anonymous Coward on Wednesday April 09, 2014 @08:00PM (#46710047)

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

    • Re:Thank you for the mess (Score:4, Insightful)

      by phantomfive ( 622387 ) on Wednesday April 09, 2014 @09:24PM (#46710575) Journal
      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.
      • 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.

        • Re: (Score:3, Informative)

          by phantomfive ( 622387 )
          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).

          • Re:Thank you for the mess (Score:5, Interesting)

            by Christian Smith ( 3497 ) on Thursday April 10, 2014 @05:31AM (#46712177) Homepage

            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... [marc.info]

            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.

      • Re: (Score:3)

        by Pieroxy ( 222434 )

        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.

    • Who was it who said "bad news travels 'round the world while the truth is still putting on it's laces"?

      Churchill, I suspect ...
  • Someone knows if OpenVPN is affected? The tests do not work on it since it uses TLS in an unusual way.
  • An IDS provides the means to detect malicious patterns in traffic. It is by no mean a remedy.

  • If it's using one of the affected versions, how did it get past the famed OpenBSD audits?

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

  • NSA, heartbleed, whatever. you'll tell your grandchildren about "back in the day" internet.

    • 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 railroa

    • Re: (Score:2)

      by Jeremi ( 14640 )

      NSA, heartbleed, whatever. you'll tell your grandchildren about "back in the day" internet

      What in particular do you think will be different about my grandchildrens' Internet?

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

    • Coding Style versus Language (Score:5, Insightful)

      by nanolith ( 58246 ) * on Wednesday April 09, 2014 @08:21PM (#46710175)

      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.

      • 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 t

        • Re:Coding Style versus Language (Score:5, Insightful)

          by nanolith ( 58246 ) * on Wednesday April 09, 2014 @11:11PM (#46710977)

          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.

      • Re: (Score:2)

        by Raenex ( 947668 )

        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.

        It's better to remove a very large class of bugs by the language making them impossible rather than insisting that a certain coding style will save you, "This time for sure!"

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

      It has nothing to do with mmap or C pointers per se. The issue is simply bad programming. Someone wrote code that trusted unvalidated user input and they got bit in the ass. Whomever performed the code review should have known better, even if the developer didn't..

    • I'm running Petra (16) and patch was out yesterday morning. sucks to be you.

    • Re:Situation is a Shambles (Score:5, Interesting)

      by kiite ( 1700846 ) on Wednesday April 09, 2014 @09:06PM (#46710479)

      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.

      • Re: (Score:3, Interesting)

        by Raenex ( 947668 )

        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 sent

        • Re: (Score:3, Informative)

          by swillden ( 191260 )

          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

    • Re: (Score:2)

      by CODiNE ( 27417 )

      So "shambles" means user supplied data...
      eating it without question means not validating it before use...

      1 Cor. 10:25 "Whatsoever is sold in the shambles, that eat, asking no question for conscience sake"

      then.. uhhh...
      Wait.. is this a GOOD thing??

    • 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

      • Re: (Score:2)

        by swilly ( 24960 )

        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.

        Most managed runtimes perform bounds checks, C does not. As a result, the same bug couldn't happen in Java or C#. Of course, bounds checks come with a cost, and one that most people wouldn't want from low level code, which means that C/C++ developers must be extra vigilant.

    • Re:Situation is a Shambles (Score:4, Informative)

      by iroll ( 717924 ) on Thursday April 10, 2014 @01:04AM (#46711373) Homepage

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

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

  • Like some site that is (like "what that site is running?" (Apache, IIS etc)) where we can see who gets what fixed when. No point in changing my passwords on a still-affected site.

  • Is bypassing/wrapping/whateverthey'redoing OS calls changing how memory is managed not a big enough change to warrant an entry in the 1.0.0h -> 1.0.1 log?

  • Reality Check. The sky is not falling. (Score:4, Informative)

    by thesandbender ( 911391 ) on Wednesday April 09, 2014 @10:24PM (#46710853)
    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.

  • IDS signatures might not work in all cases (Score:3)

    by mysidia ( 191772 ) on Wednesday April 09, 2014 @10:45PM (#46710913)

    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

  • What is the point of IDS? If you detect an attack, your private keys are compromised and the game is over.

    And then you try to recover, you make new keys, renew certificates, revoke the old one... but since certificate revocation is quite broken, you never recover. An attacker that stole your old private key will still be able to masquerade as the legitimate server.

  • Follow the proposed specification at http://heartbleedheader.com [heartbleedheader.com] to tell your users when you've patched your servers. This eliminates the guessing: "is it OK to update my password now? Do I even need to? Can I trust that I'm not being MITMed with their old SSL key that an attacker stole?" It's bad enough using the tools at hand to detect that information from a single site, let alone the hundreds you might have in your password manager.

  • If OpenSSL is (as quite a few people who know what they are talking about have claimed) poorly written and hard to maintain, why no-one has tried to come up with a simple, easy to evaluate solution.

    Or is SSL/TLS really that hard to properly implement?

Slashdot Top Deals

Your own mileage may vary.

Close