On Fri, Oct 26, 2012 at 2:29 PM, John Case <[email protected]> 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
* 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.
Jeff
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
