4 ms·

To this day I think it was a deliberately placed vulnerability. I don't have any data to back it up, of course.

hn_throwaway_99 7y ago
I sincerely, sincerely doubt it. Just look at the history of the actual bug (not hard at all to believe it could have happened by accident), and the fact of how undermanned OpenSSL was, and I'm just surprised it didn't happen sooner.
robocat 7y ago
Your problem is that absolutely anything can be explained by a conspiracy. This case was a few guys writing software in their free time - 100% likely it was an honest mistake. See https://www.buzzfeed.com/chrisstokelwalker/the-internet-is-being-protected-by-two-guys-named-st https://www.buzzfeed.com/chrisstokelwalker/the-internet-is-b...
- nickpsecurity 7y ago
  What's funny about what you linked is a government demand led to the vulnerability at a point when owners or main people were thinking of walking away. A conspiracy around that would be more believable than most. Let's ignore that, though. The thing is, they add vulnerabilities in a number of ways. They can do it directly with code. They can do it indirectly with standards hard to code correctly w/out vulnerabilities or side channels. There's lots of options. Whatever they do will usually look like a helpful contribution or useful requirement that went wrong in a way that leads to an attack. The better ones are those that look like common or inevitable errors. That's because obvious backdoors make folks run away from a project or supplier maybe forever on top of question who put it there. So, it's usually these flaws that look like obvious errors that still get the job done with everyone around defending the person that put them there. And I'm not saying it was an NSA job. I have no idea. They've been doing too good of a job on most things for me to know. Could've been an accident. Even probability supports it's an accident just like it did all the times it was a subversion. At $200+ mil a year budget for backdoors/hacking, you bet there were a lot of accidents that, in non-TS version, had nothing to do with the NSA. ;) Edit: There's lots of questionable things in this article. My favorite is this: "And this group are the best of the best of the best." The OpenBSD team doing LibreSSL had all kinds of summaries, live updates, and even presentations of what they found. It was about as far from that quote as you could imagine. Although my memory sucks, I think at one point they said there was even code that checked to see if endianness changed while it was operating. They at least had that covered. There were so many oddities about that codebase.
  - java-man 7y ago
    Exactly. I don't have any evidence to back up my suspicion. If the evidence exists, it exists in a locked safe somewhere at Ft Meade (or other place) and in the brains of a very few people. I can feel what is known as code smell. So, let's develop a new feature in the most widely used security library. The very first thing that must be done is to sanitize network input. This is the first thing I would expect to be done by a seasoned developer. The lack of this check is suspicious. It could be an honest mistake, of course - we all make mistakes, and I am sure I've made my share of idiotic changes. But this isn't something I would expect about OpenSSL. I agree with @nickpsecurity, "many oddities". Commit that introduced the vulnerability: https://git.openssl.org/gitweb/?a=commit&h=4817504d069b4c5082161b02a22116ad75f822b1&p=openssl.git https://git.openssl.org/gitweb/?a=commit&h=4817504d069b4c508... Fix: https://github.com/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3 https://github.com/openssl/openssl/commit/96db9023b881d7cd9f...
  - peter_d_sherman 7y ago
    LibreSSL: More Than 30 Days Later https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html Not pretty to read from a security perspective... But, on the other hand, quite eye opening, if you want to have your eyes opened...
    - nickpsecurity 7y ago
      Thanks! I'll add it to book.arks for next time this comes up.
- OrgNet 7y ago
  And your problem is that absolutely anything can be explained by malicious intent.
jMyles 7y ago
That's a serious and damning accusation to level against a volunteer contributor to an open source project, and in very bad taste if indeed you have no evidence (or even a reasoned narrative of the hows and whys).
- java-man 7y ago
  in a sibling comment. tl,dr: the first thing one does in this field is to sanitize the input.
  - thephyber 7y ago
    I would also argue that processes and tools should supplement developer mistakes, negligence, or maliciousness. Unit tests, static analysis, fuzzing, integration tests, security audits, code reviews, principle of least privilege, etc. all have a part to play and yet this lapse in validation still managed to make it into production and infect all of the downstream libraries and applications. I would argue that even if you could pin an accusation of negligence on the developer (I've not seen any evidence that could substantiate this accusation), it doesn't rest only with that one developer. The project itself lacked redundant checks. The downstream applications that import OpenSSL similarly failed to audit it. I think in the whole scheme of things, the Open Source movement had a lot of momentum by the time that code was written, but the corporations that relied on the benefits of open source largely didn't contribute to paying to maintain highly secure coding practices. HeartBleed was one of the incidents that made the internet infrastructure/platform companies (among others) start paying for humans, tools, and reviews to help make these common libraries more secure. Google's Project Zero was started in July 2014, soon after HeartBleed was announced.
    - java-man 7y ago
      thank you.
cjbprime 7y ago
It sounds like you probably haven't worked on a lot of C code. OpenSSL is a giant security vulnerability pile. It is not at all hard to believe that someone has added a vulnerability by mistake: it would be more surprising to me if they hadn't.

I sincerely, sincerely doubt it. Just look at the history of the actual bug (not hard at all to believe it could have happened by accident), and the fact of how undermanned OpenSSL was, and I'm just surprised it didn't happen sooner.

robocat 7y ago

Your problem is that absolutely anything can be explained by a conspiracy. This case was a few guys writing software in their free time - 100% likely it was an honest mistake. See https://www.buzzfeed.com/chrisstokelwalker/the-internet-is-being-protected-by-two-guys-named-st https://www.buzzfeed.com/chrisstokelwalker/the-internet-is-b...

nickpsecurity 7y ago
What's funny about what you linked is a government demand led to the vulnerability at a point when owners or main people were thinking of walking away. A conspiracy around that would be more believable than most. Let's ignore that, though. The thing is, they add vulnerabilities in a number of ways. They can do it directly with code. They can do it indirectly with standards hard to code correctly w/out vulnerabilities or side channels. There's lots of options. Whatever they do will usually look like a helpful contribution or useful requirement that went wrong in a way that leads to an attack. The better ones are those that look like common or inevitable errors. That's because obvious backdoors make folks run away from a project or supplier maybe forever on top of question who put it there. So, it's usually these flaws that look like obvious errors that still get the job done with everyone around defending the person that put them there. And I'm not saying it was an NSA job. I have no idea. They've been doing too good of a job on most things for me to know. Could've been an accident. Even probability supports it's an accident just like it did all the times it was a subversion. At $200+ mil a year budget for backdoors/hacking, you bet there were a lot of accidents that, in non-TS version, had nothing to do with the NSA. ;) Edit: There's lots of questionable things in this article. My favorite is this: "And this group are the best of the best of the best." The OpenBSD team doing LibreSSL had all kinds of summaries, live updates, and even presentations of what they found. It was about as far from that quote as you could imagine. Although my memory sucks, I think at one point they said there was even code that checked to see if endianness changed while it was operating. They at least had that covered. There were so many oddities about that codebase.
- java-man 7y ago
  Exactly. I don't have any evidence to back up my suspicion. If the evidence exists, it exists in a locked safe somewhere at Ft Meade (or other place) and in the brains of a very few people. I can feel what is known as code smell. So, let's develop a new feature in the most widely used security library. The very first thing that must be done is to sanitize network input. This is the first thing I would expect to be done by a seasoned developer. The lack of this check is suspicious. It could be an honest mistake, of course - we all make mistakes, and I am sure I've made my share of idiotic changes. But this isn't something I would expect about OpenSSL. I agree with @nickpsecurity, "many oddities". Commit that introduced the vulnerability: https://git.openssl.org/gitweb/?a=commit&h=4817504d069b4c5082161b02a22116ad75f822b1&p=openssl.git https://git.openssl.org/gitweb/?a=commit&h=4817504d069b4c508... Fix: https://github.com/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3 https://github.com/openssl/openssl/commit/96db9023b881d7cd9f...
- peter_d_sherman 7y ago
  LibreSSL: More Than 30 Days Later https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html Not pretty to read from a security perspective... But, on the other hand, quite eye opening, if you want to have your eyes opened...
  - nickpsecurity 7y ago
    Thanks! I'll add it to book.arks for next time this comes up.
OrgNet 7y ago
And your problem is that absolutely anything can be explained by malicious intent.

jMyles 7y ago

That's a serious and damning accusation to level against a volunteer contributor to an open source project, and in very bad taste if indeed you have no evidence (or even a reasoned narrative of the hows and whys).

java-man 7y ago
in a sibling comment. tl,dr: the first thing one does in this field is to sanitize the input.
- thephyber 7y ago
  I would also argue that processes and tools should supplement developer mistakes, negligence, or maliciousness. Unit tests, static analysis, fuzzing, integration tests, security audits, code reviews, principle of least privilege, etc. all have a part to play and yet this lapse in validation still managed to make it into production and infect all of the downstream libraries and applications. I would argue that even if you could pin an accusation of negligence on the developer (I've not seen any evidence that could substantiate this accusation), it doesn't rest only with that one developer. The project itself lacked redundant checks. The downstream applications that import OpenSSL similarly failed to audit it. I think in the whole scheme of things, the Open Source movement had a lot of momentum by the time that code was written, but the corporations that relied on the benefits of open source largely didn't contribute to paying to maintain highly secure coding practices. HeartBleed was one of the incidents that made the internet infrastructure/platform companies (among others) start paying for humans, tools, and reviews to help make these common libraries more secure. Google's Project Zero was started in July 2014, soon after HeartBleed was announced.
  - java-man 7y ago
    thank you.

cjbprime 7y ago

It sounds like you probably haven't worked on a lot of C code. OpenSSL is a giant security vulnerability pile. It is not at all hard to believe that someone has added a vulnerability by mistake: it would be more surprising to me if they hadn't.