[cryptography] Just how bad is OpenSSL ?
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
> and found the hackernews discussion:
> (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":
> 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):
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)
* -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