On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Fri, Oct 26, 2012 at 2:29 PM, John Case <c...@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. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
