[cryptography] anyone got a "how not to use OpenSSL" list?
ryan+cryptography at sleevi.com
Thu Oct 11 06:02:50 EDT 2012
On Wed, October 10, 2012 10:34 am,
travis+ml-rbcryptography at 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 (
) 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.
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")
More information about the cryptography