[cryptography] Just how bad is OpenSSL ?

Jeffrey Walton noloader at gmail.com
Mon Oct 29 18:34:49 EDT 2012

On Fri, Oct 26, 2012 at 2:29 PM, John Case <case at sdf.org> wrote:
> I was recently reading "the most dangerous code in the world" article at
> stanford:
> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
> and found the hackernews discussion:
> http://news.ycombinator.com/item?id=4695350
> (interesting discussion and argument about curl library and how often it is
> badly deployed)
> And the hackernews discussion led me to "OpenSSL is written by monkeys":
> http://www.peereboom.us/assl/assl/html/openssl.html
> So, given what is in the stanford report and then reading this rant about
> openssl, I am wondering just how bad openssl is ?  I've never had to
> implement it or code with it, so I really have no idea.
> How long has it been "understood" that it's a mess (if it is indeed a mess)
> ?  How dangerous is it ?
If your engineering process includes an SDLC, then OpenSSL has at
least two other issues:

    1) It can't clean compile with nominal warnings
    2) It lacks platform security integration

For (1), a clean compile is often a security gate, and I don't like
the choice of the Ostrich Algorithm. I wrote to NIST a while back and
asked that a clean compile be added as a CMVP requirement, but nothing
every came from it. The problem is that I cannot change the source
files, so I can't fix the problems flagged by the compiler warning
system, dynamic analysis, or static analysis.

For example, I know that OpenSSL uses uninitialized data (and *not* in
the PRNG path). A bug report was filed and closed "won't fix" because
the members of interest were initialized. I also know the library
suffers conversion problems and truncation problems.

For completeness, here are the GCC switches of interest:

  * C Code:
    -Wall -Wextra -Wconversion -Wstrict–overflow -Wformat=2 -Wformat-security

  * C++ Code (includes C Code warnings):
    -Woverloaded-virtual -Wreorder -Wsign-promo -Wnon-virtual-dtor

  * Objective C Code (includes C Code warnings):
    -Wstrict-selector-match -Wundeclared-selector

For item (2), we have some good defenses provided by the platform but
they are not used - ASLR, DEP, Stack Canaries, Safe Memory functions
etc. Considering how often the library handles untrusted input (the
remote host's data should always be considered untrusted) and how
often there are parser problems, I would expect these to be mandatory
for high integrity software.

For completeness, here are the switches for GCC/LD (use as available):

  * -fPIE/-pie (or –fPIC/-shared)
  * -fstack-protector-all
  * -z,relro, -z,now

Again, I wrote to NIST and asked that the CMVP program include
platform security integration since I cannot change it after

For what its worth, its not just OpenSSL that has these problems.


More information about the cryptography mailing list