[cryptography] Just how bad is OpenSSL ?

Ben Laurie 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
>> 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.

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.

Pointer?

> 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
> validation.
>
> 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
might care.



More information about the cryptography mailing list