[openssl-users] Old "RSA_NET" key format

[Karl Vogel]

>> On 08/07/2015 20:23, Salz, Rich wrote:
  > 1. Is there any good reason to remove this code?

R> Yes.  If it's not tested, reviewed, or in general use, then it's
R> more likely to be harmful (source of bugs) than useful.

>> On Wed, 08 Jul 2015 20:47:43 +0200, Jakob Bohm replied:

J> That's an overly general criteria...

   Nope, Rich is right on the money.

J> To objectively consider the potential harm of rarely used code,
J> one must clearly determine if there is any way this code could be
J> invoked inadvertently or remotely.

   How do stack-smashers work?  Don't they trick a system into running
   part of a program inadvertently, often with elevated privileges?

   How many of us build and run OpenSSL using compiler optimization?
   Have a look at http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
   From the blurb:

     What if you put security into your code but your compiler took it
     out without you realizing it?  That's exactly what's happening when
     you use most compilers on the market, according to researchers at
     MIT as disclosed in a 2013 paper.

   The authors describe some security operations (null pointer checks,
   buffer overflow safeguards, etc) seen by the compiler as being
   unnecessary, and hence removed.  I don't know that this is actually
   happening anywhere in the codebase, but it's a *big* codebase, and
   that's the problem.

   How about the NTP reflection attacks we saw recently?  From
   http://www.mail-archive.com/tech@openbsd.org/msg21729.html

     [...] openntpd is a modern piece of code <5000 lines long written
     using best known practices of the time, whereas ntp.org's codebase
     is reportedly 100,000 lines of unknown or *largely unused code*,
     poorly smithed in the past when these kinds of programming mistakes
     were not a significant consideration.

J> For example the heartbeat code was obviously callable from network
J> packets (even if it had no bugs), so needed this kind of cleanup,

   Was this only obvious after the fact?

J> while the original eay DES API is only invokable from code that
J> knows about it, and would thus not need to be removed for lack of
J> use/testing.

   What about Apple's SSL/TLS bug (AKA CVE-2014-1266, or the "goto fail
   bug") in February 2014?  That was caused by unreachable code that
   needed to be reached in order to work properly.  The point is, more
   code == more eyes and mind-share that have to be devoted to finding
   unintended consequences.

   Have a look here for more reasons to trim out old code:
   http://www.techrepublic.com/blog/software-engineer/why-you-need-to-clean-out-dead-code-paths/

   Cliff-notes version:

  * Code changes gets ugly because you are trying to keep orphaned code in
    line with the rest of the system, but there is often no real regression
    testing or anything else.

  * Maintaining code after a long period away from it (or by someone else)
    is very difficult, because no one really knows why a piece of code
    is there, they just know that it is there.

  * The code is no longer a faithful representation of the business logic,
    because it contains logic that the specifications and business logic
    are not aware of.

  * It presents potential security risks, as unmaintained code can be
    reached (especially in Web applications, where tweaking parameters
    may trigger something you never intended).

  OpenSSL is a critical part of security in too many places for us to
  take on any unnecessary technical debt.

--
Karl Vogel                      I don't speak for the USAF or my company

Sign on a long-established New Mexico dry cleaners:
   "38 years on the same spot"