5 ms·

While this particular vulnerability in OpenSSL isn't nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer derefere

While this particular vulnerability in OpenSSL isn't nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer dereferences in something this critical. The worst part of this library is that the way it is organized makes it difficult to find these problems, or to use tools such as static analyzers to help. There are some amazing static analysis tools out there for C, but they are rendered useless by some of the hackery used in this library, such as their custom allocators. I don't mean to sound negative -- the OpenSSL team has done a great job making this library available in the first place -- but given how heavily this library is relied upon, better discipline is needed in this code base. LibreSSL is a step in the right direction, and I commend the OpenBSD team for taking on this alternative. However, it's only a starting point. The entire approach of OpenSSL is dated, and it has not done a good job keeping up with our modern understanding of solid security engineering. The code base needs to be overhauled from the ground up with modern security and software development practices in mind. If ever there were a library that should be designed using formal proofs in software, it's this one. Even basic TDD with good code coverage would catch the majority of the bugs that have been discovered in OpenSSL over the past ten years. </rant>

Kalium 12y ago
Good thoughts! I trust you have money to put behind them?
- nanolith 12y ago
  I did not realize that one must have money to voice an opinion. Yes, I have money. No, it wouldn't be a wise investment to throw it at OpenSSL. Some problems are subtle enough that merely throwing money at them won't make them go away. I also have the requisite talent and experience to make a sizable dent in rectifying the problems I have expressed in this library. However, that is also useless unless attitudes around the project are shifted so that such efforts would be maintained. Fixing the project requires changes at the very top of their organization all the way down. At this point, nothing short of a fork -- which OpenBSD has done with LibreSSL -- may be enough to drive this sort of change. Which is, not coincidentally, why I donate money to the OpenBSD project. LibreSSL, once it is mature, may be a good launching point for some of the ideas I have expressed here. However, I would have to see how that code base matures before making such a determination. It's a largely meaningless exercise unless people start moving to that library and away from OpenSSL.
  - Kalium 12y ago
    My point is that it's trivially easy to call for something to be done. It's easy to ask other people to do things, especially when it requires nothing whatsoever of you. This approach is notorious for not producing good software.
    - deleted 12y ago
      [deleted]
MichaelGG 12y ago
Rust would also eliminate these bugs, as a class. And Rust has inline asm, for those cases where you need platform specific. Finally, Rust van export a C ABI library, so you could make a drop-in replacement.
- nullc 12y ago
  "these bugs, as a class" It absolutely would not eliminate CVE-2014-3570 or many other of the cryptographic bugs that show up in OpenSSL and other TLS implementations. This kind of axiomatic thinking that memory safety equals all safety almost resulted in Rust being less safe (IMO) than C in these other respects: the normal types in rust are all defined to overflow even though overflow is almost always a bug, and so you couldn't use static analysis on arbitrary rust codebases to warn you about these issues (where you can in C because signed overflow is undefined, so an analysis tool can always flag that as an error without it being a false positive). Fortunately, it sounds like Rust is moving to fix this ( http://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062 http://discuss.rust-lang.org/t/a-tale-of-twos-complement/106... ), which is a big improvement. But it's important to not be fuzzy about the risks. There is a well established link between safety equipment and risky behavior in driving and bicycling; (http://en.wikipedia.org/wiki/Risk_compensation http://en.wikipedia.org/wiki/Risk_compensation). I don't mean to suggest that better isn't better and we shouldn't use safer tools, but if our response to safer tools is to lower our vigilance, even the slightest, we may get worse results.
  - MichaelGG 12y ago
    I was referring to the null deref.
  - nanolith 12y ago
    I agree with this assessment. There is nothing inherently wrong with C. While alternative languages have certain advantages, there are clear reasons why core foundational libraries like OpenSSL are written in C: portability, age of the code base, knowledge of the contributors, etc. While I would personally like to see a pragmatic move towards C++ in many of these low level libraries for some of the additional type safety and mechanics the language provides, this is a normative idea only, and I am under no delusion that it would necessarily result in better code. Good software transcends language. I would, however, like to see enhancements to the style of code being written in this library so that tools like static analyzers and contract verifiers can provide meaningful results. A craftsman is only as good as how well he/she can make use of the available tools. Much of OpenSSL defies analysis, which is why the more bone-headed of these vulnerabilities, such as Heartbleed, are so hard to find. It's impossible to eliminate all bugs. But, it is possible to build code in such a way that when there is the suspicion of a bug, one has a fairly good idea of how and why it is occurring. It is also possible to structure code -- even C and assembler -- so that it's easier to read and analyze, be this by eye or using tools. Finally, it's possible to structure code so that automated unit testing provides meaningful results regarding boundary conditions and contracts between functions. This latter point isn't meant to find bugs on its own, but rather to codify the more subtle bits of contracts between functions and data structures in a defensive way to ensure that future patches -- like the one that caused Heartbleed -- don't stomp on assumptions made in software.

Kalium 12y ago

Good thoughts! I trust you have money to put behind them?

nanolith 12y ago
I did not realize that one must have money to voice an opinion. Yes, I have money. No, it wouldn't be a wise investment to throw it at OpenSSL. Some problems are subtle enough that merely throwing money at them won't make them go away. I also have the requisite talent and experience to make a sizable dent in rectifying the problems I have expressed in this library. However, that is also useless unless attitudes around the project are shifted so that such efforts would be maintained. Fixing the project requires changes at the very top of their organization all the way down. At this point, nothing short of a fork -- which OpenBSD has done with LibreSSL -- may be enough to drive this sort of change. Which is, not coincidentally, why I donate money to the OpenBSD project. LibreSSL, once it is mature, may be a good launching point for some of the ideas I have expressed here. However, I would have to see how that code base matures before making such a determination. It's a largely meaningless exercise unless people start moving to that library and away from OpenSSL.
- Kalium 12y ago
  My point is that it's trivially easy to call for something to be done. It's easy to ask other people to do things, especially when it requires nothing whatsoever of you. This approach is notorious for not producing good software.
  - deleted 12y ago
    [deleted]

MichaelGG 12y ago

Rust would also eliminate these bugs, as a class. And Rust has inline asm, for those cases where you need platform specific. Finally, Rust van export a C ABI library, so you could make a drop-in replacement.

nullc 12y ago
"these bugs, as a class" It absolutely would not eliminate CVE-2014-3570 or many other of the cryptographic bugs that show up in OpenSSL and other TLS implementations. This kind of axiomatic thinking that memory safety equals all safety almost resulted in Rust being less safe (IMO) than C in these other respects: the normal types in rust are all defined to overflow even though overflow is almost always a bug, and so you couldn't use static analysis on arbitrary rust codebases to warn you about these issues (where you can in C because signed overflow is undefined, so an analysis tool can always flag that as an error without it being a false positive). Fortunately, it sounds like Rust is moving to fix this ( http://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062 http://discuss.rust-lang.org/t/a-tale-of-twos-complement/106... ), which is a big improvement. But it's important to not be fuzzy about the risks. There is a well established link between safety equipment and risky behavior in driving and bicycling; (http://en.wikipedia.org/wiki/Risk_compensation http://en.wikipedia.org/wiki/Risk_compensation). I don't mean to suggest that better isn't better and we shouldn't use safer tools, but if our response to safer tools is to lower our vigilance, even the slightest, we may get worse results.
- MichaelGG 12y ago
  I was referring to the null deref.
- nanolith 12y ago
  I agree with this assessment. There is nothing inherently wrong with C. While alternative languages have certain advantages, there are clear reasons why core foundational libraries like OpenSSL are written in C: portability, age of the code base, knowledge of the contributors, etc. While I would personally like to see a pragmatic move towards C++ in many of these low level libraries for some of the additional type safety and mechanics the language provides, this is a normative idea only, and I am under no delusion that it would necessarily result in better code. Good software transcends language. I would, however, like to see enhancements to the style of code being written in this library so that tools like static analyzers and contract verifiers can provide meaningful results. A craftsman is only as good as how well he/she can make use of the available tools. Much of OpenSSL defies analysis, which is why the more bone-headed of these vulnerabilities, such as Heartbleed, are so hard to find. It's impossible to eliminate all bugs. But, it is possible to build code in such a way that when there is the suspicion of a bug, one has a fairly good idea of how and why it is occurring. It is also possible to structure code -- even C and assembler -- so that it's easier to read and analyze, be this by eye or using tools. Finally, it's possible to structure code so that automated unit testing provides meaningful results regarding boundary conditions and contracts between functions. This latter point isn't meant to find bugs on its own, but rather to codify the more subtle bits of contracts between functions and data structures in a defensive way to ensure that future patches -- like the one that caused Heartbleed -- don't stomp on assumptions made in software.