Heartbleed OpenSSL Vulnerability: A Technical Remediation

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

Comments

what?

[Anonymous Coward]

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

Thank you for the mess

[manu0601]

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

[Anonymous Coward]

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

[ChrisKnight]

Midnight_Falcon, you are indeed a rare bird. :)

Situation is a Shambles

[ObsessiveMathsFreak]

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.

Re:Situation is a Shambles

[Jeremi]

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.

Re:Mountain out of a molehill

[NiteMair]

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.

Coding Style versus Language

[nanolith]

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.

Re:Coding Style versus Language

[nanolith]

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:Mountain out of a molehill

[dreamchaser]

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.