When a Some(…) value was passed to the properties argument of either of these functions, a use-after-free would result. In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to CString::drop's behavior). The maintainers thank quitbug for reporting this vulnerability to us.
ssl::select_next_proto can return a slice pointing into the server argument's buffer but with a lifetime bound to the client argument. In situations where the server buffer's lifetime is shorter than the client buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client.
Previously, MemBio::get_buf called slice::from_raw_parts with a null-pointer, which violates the functions invariants, leading to undefined behavior. In debug builds this would produce an assertion failure. This is now fixed.
This function returned a reference into an OpenSSL datastructure, but there was no way to ensure OpenSSL would not mutate the datastructure behind one's back. Use of this function should be replaced with X509StoreRef::all_certificates.
When this function was passed an empty string, openssl would attempt to call strlen on it, reading arbitrary memory until it reached a NUL byte.
OpenSSL has a modified bit that it can set on on X509_NAME objects. If this bit is set then the object is not thread-safe even when it appears the code is not modifying the value. Thanks to David Benjamin (Google) for reporting this issue.
These functions would crash when the context argument was None with certain extension types. Thanks to David Benjamin (Google) for reporting this issue.
SubjectAlternativeName and ExtendedKeyUsage arguments were parsed using the OpenSSL function X509V3_EXT_nconf. This function parses all input using an OpenSSL mini-language which can perform arbitrary file reads. Thanks to David Benjamin (Google) for reporting this issue.
An issue was discovered in the openssl crate before 0.10.9 for Rust. A use-after-free occurs in CMS Signing.
All versions of rust-openssl prior to 0.9.0 contained numerous insecure defaults including off-by-default certificate verification and no API to perform hostname verification. Unless configured correctly by a developer, these defaults could allow an attacker to perform man-in-the-middle attacks. The problem was addressed in newer versions by enabling certificate verification by default and exposing APIs to perform hostname verification. Use the SslConnector and SslAcceptor types to take advantage of these new …