3 ms·

Heartbleed was caused by a class of code error prevalent in the toolchain used to write that code. It was not caused by the specification itself. Here is the e

Heartbleed was caused by a class of code error prevalent in the toolchain used to write that code. It was not caused by the specification itself. Here is the exact change if you're able to read the code: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h... -- if that is not within your skillset to read that change, the patch is essentially doing a bounds check on a set area of memory. The language being used is notorious for allowing this type of code error and is the source of many exploits and bugs. It has nothing to do with the specification. For some reading material see this wikipedia article on the subject: https://en.wikipedia.org/wiki/Buffer_over-read https://en.wikipedia.org/wiki/Buffer_over-read >Programming languages commonly associated with buffer over-reads include C and C++, which provide no built-in protection against using pointers to access data in any part of virtual memory, and which do not automatically check that reading data from a block of memory is safe; respective examples are attempting to read more elements than contained in an array, or failing to append a trailing terminator to a null-terminated string. Bounds checking can prevent buffer over-reads We mitigate against attack vectors before there are known instances of software using those attack vectors. I'm not sure why you want to argue against that, or even how because we do it all the time. Take Spectre/Meltdown as another example. Preemptive measures were taken before any known usage of that attack vector had been discovered.

jcranmer 8y ago
You're missing the point. The TLS heatbeat feature is a feature that is wanted by essentially nobody. Adding support for it means you're adding code--which naturally has the potential for bugs--to a server install, which increases the scope for vectors. Furthermore, as an underused feature, it's not going to get the same amount of code review as more heavily trafficked portions of the codebase. Sure, the actual bug is a coding 101 bug, but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important. One of the lessons is that you need more reason to implement a feature than "it's a feature that can be implemented."
- kadendogthing 8y ago
  > You're missing the point. I don't think I am. You're focusing on one particular thing and invoking platitudes that are completely irrelevant. You're actively attempting to change the conversation topic to fit your viewpoint. That's not okay. No one is talking about the philosophy of feature development and adoption. I gave another example of where we preemptively mitigate issues that has nothing to do with philosophical waxing on "did we really need to do this" or "nobody really wanted that feature": Specter/Meltdown. So two things, to get this conversation back on track: 1) The idea that DNNSEC is worthless/useless/bad is not "famous" by any reasonable use of that term. I explicitly stated it was only something you see in particular circles. The fact that the actual most popular piece of software used to manage DNS enables DNNSEC by default, and one of the biggest 3rd party public providers for DNS has it opt-out only is a testament to this fact. It's myopic to think that other people are aware of these things when the entire ecosystem is signaling quite the opposite. 2) DNSSEC might be useless, but in abstract terms arguing against systems designed to mitigate attacks simply because those attacks haven't been seen in the wild is a bankrupt idea in the world of security. So if you want to say DNSSEC is a bad idea then stick with that, but don't say it's a bad idea because we haven't seen an actual attack with what DNSSEC is trying to prevent. The claim again, is bankrupt when you're talking about securing systems. >but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important. I actually want to speak to this, because it's kind of a popular thing to say in the world of software development, but it fundamentally misunderstands what's actually happening. You're right that a social process allowed the coding 101 bug to happen and exist for so long, but you're wrong about which social process. People's motivations for a feature have no bearing on how exploitable code gets written. Because features that people do want are victim to the same kind of errors in code. If you immediately falsify your perspective about which social process is in play you see it becomes irrelevant. You can completely take people's motivations out of the equation and the same process and class of error exists that allows the exploits and bugs to happen. I am not saying that increases in LOC does not correlate with an increase in bugs. That's a fairly standard fact. I am saying that people's motivations for features have no bearing on how open source projects fall victim to shoddy code. The social process that IS to blame is the fact that people don't invest in open source software, yet depend on it for their entire ecosystem. A student wrote some code, submitted it, and it was reviewed by one person. That code was never really looked at again, not really tested, but allowed to exist in the software for years. If the social ecosystem around open source software was one where more eyes had been laid on the code created it might not have happened all together, and relying on a student to write the code is a travesty in its own right all together. But people's motivations for writing code? Not really relevant in terms of LOC, exploits, and code quality.

jcranmer 8y ago

You're missing the point. The TLS heatbeat feature is a feature that is wanted by essentially nobody. Adding support for it means you're adding code--which naturally has the potential for bugs--to a server install, which increases the scope for vectors. Furthermore, as an underused feature, it's not going to get the same amount of code review as more heavily trafficked portions of the codebase. Sure, the actual bug is a coding 101 bug, but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important. One of the lessons is that you need more reason to implement a feature than "it's a feature that can be implemented."

kadendogthing 8y ago
> You're missing the point. I don't think I am. You're focusing on one particular thing and invoking platitudes that are completely irrelevant. You're actively attempting to change the conversation topic to fit your viewpoint. That's not okay. No one is talking about the philosophy of feature development and adoption. I gave another example of where we preemptively mitigate issues that has nothing to do with philosophical waxing on "did we really need to do this" or "nobody really wanted that feature": Specter/Meltdown. So two things, to get this conversation back on track: 1) The idea that DNNSEC is worthless/useless/bad is not "famous" by any reasonable use of that term. I explicitly stated it was only something you see in particular circles. The fact that the actual most popular piece of software used to manage DNS enables DNNSEC by default, and one of the biggest 3rd party public providers for DNS has it opt-out only is a testament to this fact. It's myopic to think that other people are aware of these things when the entire ecosystem is signaling quite the opposite. 2) DNSSEC might be useless, but in abstract terms arguing against systems designed to mitigate attacks simply because those attacks haven't been seen in the wild is a bankrupt idea in the world of security. So if you want to say DNSSEC is a bad idea then stick with that, but don't say it's a bad idea because we haven't seen an actual attack with what DNSSEC is trying to prevent. The claim again, is bankrupt when you're talking about securing systems. >but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important. I actually want to speak to this, because it's kind of a popular thing to say in the world of software development, but it fundamentally misunderstands what's actually happening. You're right that a social process allowed the coding 101 bug to happen and exist for so long, but you're wrong about which social process. People's motivations for a feature have no bearing on how exploitable code gets written. Because features that people do want are victim to the same kind of errors in code. If you immediately falsify your perspective about which social process is in play you see it becomes irrelevant. You can completely take people's motivations out of the equation and the same process and class of error exists that allows the exploits and bugs to happen. I am not saying that increases in LOC does not correlate with an increase in bugs. That's a fairly standard fact. I am saying that people's motivations for features have no bearing on how open source projects fall victim to shoddy code. The social process that IS to blame is the fact that people don't invest in open source software, yet depend on it for their entire ecosystem. A student wrote some code, submitted it, and it was reviewed by one person. That code was never really looked at again, not really tested, but allowed to exist in the software for years. If the social ecosystem around open source software was one where more eyes had been laid on the code created it might not have happened all together, and relying on a student to write the code is a travesty in its own right all together. But people's motivations for writing code? Not really relevant in terms of LOC, exploits, and code quality.