On Wed, October 10, 2012 10:34 am, travis+ml-rbcryptogra...@subspacefield.org wrote: > I want to find common improper usages of OpenSSL library for SSL/TLS. > > Can be reverse-engineered from a "how to properly use OpenSSL" FAQ, > probably, but would prefer information to the first point rather than > its complement. > --
Depends on what you mean by improper - improper in that it introduces security-relevant issues, or just general improper cargo-cult usage of OpenSSL that leads to buggy behaviour. Here's a quick list off the top of my head from having poked around various languages' bindings (Python, Perl, PHP, etc), from having seen various "rebranded" OpenSSL-using products, and from various "I just want to do HTTPS" 1) Assuming that an ASN1_STRING contains a null-terminated string - eg: using ASN1_STRING_data directly, without checking ASN1_STRING_length as well. Moxie's embedded NULL in the CN (BlackHat 09) trick was enough to get most popular language bindings to check the length, but a depressing number of samples and third-party libraries continue to assume ASN1_STRING_data == C string. 2) Assume that OpenSSL performs RFC 2818/6125 name validation, and thus fail to implement it themselves. As a result of no name checking, www.paypal.com can be trivially redirected to www.evil.com as long as it chains to a configured trust anchor. OpenSSL 1.1.0 (not yet released) finally adds some helpers for this, but otherwise everyone has been left implementing their own - if at all (generally, not at all). 3) Using the Mozilla Root Certificate data ( http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1 ) and directly exporting all the certificates, without considering the trust bits. You know, the bits in NSS that says "In no circumstances should you ever, ever trust this certificate?", which authors and libraries happily interpret as "I can totally trust this certificate!" Be smart, use something like https://github.com/agl/extract-nss-root-certs 4) Back on the topic of validation, assume that OpenSSL "out of the box" is performing RFC 3280/5280 validation, or, in a similar token, that the results are equivalent to what a browser would give when using HTTPS. This ranges from online revocation checking to trust anchor equivalence to assuming that OpenSSL supports multiple certification paths. You could argue that this is not an improper usage in itself, just a misunderstanding, but I'd argue that using OpenSSL with the assumption it's going to do all the 'magic' for you is still a bug. 5) Failure to properly handle results from functions. eg: EVP_VerifyFinal returns 1 on success, 0 on failure, -1 on fatal error. However, code may check "if (EVP_VerifyFinal(...))" / "if (!EVP_VerifyFinal(...))" . Even OpenSSL itself was guilty of this. 6) While not quite a security failure, many distros still ship OpenSSL with defaults to PrintableString-or-BMPString (or worse, TeletexString) for string encodings for certificates, requests, etc, rather than using UTF8String. This, despite the recommendations from RFC 3280 to use UTF8String for the past decade. 7) When using the SSL/TLS layer, failing to handle empty fragments or split records (eg: as done by BEAST). Generally, this can be summed as the assumption that SSL_read will return "all" of the data in a single call. 8) Assuming that an ASN1_TIME can always be represented by a time_t - or converting to a time_t to perform comparisons. This really comes up on 32-bit systems that suffer from the Y2038 bug. OpenSSL 1.0.0 added a set of useful helper functions, but still a number of codebasis exist that presume somebody out there wants to compile with OpenSSL 0.9.6/0.9.7, and so they have all sorts of crazy bugs. 9) SSL_OP_ALL 10) SSL_OP_NO_SSLv2 (or more specifically, the lack of it) 11) Generating new DH parameters every time tmp_dh_callback is called (And then complaining that "SSL is slow") _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
