One I've seen in deployed code with Java crypto but might also happen with openssl is use of PBKDF when the secret is only used locally (e.g. to MAC/encrypt a cookie) and doesn't even need to be a user memorable string. That's a great way to consume CPU uselessly and was probably caused because the developer saw there was an API that took a string as input for a secret.
S On 10/11/2012 11:02 AM, Ryan Sleevi wrote: > On Wed, October 10, 2012 10:34 am, > [email protected] 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 > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography > > _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
