[cryptography] Just how bad is OpenSSL ?
ben at links.org
Tue Oct 30 05:03:46 EDT 2012
On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> 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.
OpenSSL compiles clean with the following set of flags (under gcc):
-Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare
-Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL
-DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED
you can find this in Configure, in the variable $gcc_devteam_warn. If
you can make a case for more/less/different flags it should compile
clean under, I'd be happy to fix it (at least in non-frozen branches).
I have no idea what you mean by "nominal warnings".
> 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
Ah, OK, you supply them. I don't have any argument with these, I
suspect, but observe that all of them are newer than OpenSSL is. If
people want issues like this fixed, they need to raise them :-)
> * 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
> * FORTIFY_SOURCES=2
> * -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.
Apparently you think the best way to get a secure platform is to apply
pressure through pointless security standards. I'd suggest your
efforts might be better spent supplying patches instead. Or, y'know,
talking to the authors of the s/w in question. You never know, they
More information about the cryptography