openssl known bugs

`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.

These functions would crash when the context argument was None with certain extension types. Thanks to David Benjamin (Google) for reporting this issue.

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 features (as opposed to the lower-level SslContext type).

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](https://github.com/quitbug/) for reporting this vulnerability to us.

In `openssl` versions before `0.10.70`, `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. `openssl` 0.10.70 fixes the signature of `ssl::select_next_proto` to properly constrain the output buffer's lifetime to that of both input buffers. In standard usage of `ssl::select_next_proto` in the callback passed to `SslContextBuilder::set_alpn_select_callback`, code is only affected if the `server` buffer is constructed *within* the callback. For example: Not vulnerable - the server buffer has a `'static` lifetime: ```rust builder.set_alpn_select_callback(|_, client_protos| { ssl::select_next_proto(b"\x02h2", client_protos).ok_or_else(AlpnError::NOACK) }); ``` Not vulnerable - the server buffer outlives the handshake: ```rust let server_protos = b"\x02h2".to_vec(); builder.set_alpn_select_callback(|_, client_protos| { ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK) }); ``` Vulnerable - the server buffer is freed when the callback returns: ```rust builder.set_alpn_select_callback(|_, client_protos| { let server_protos = b"\x02h2".to_vec(); ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK) }); ```

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 shared reference into an OpenSSL datastructure but did not account for interior mutability. OpenSSL may modify the data behind this reference, meaning accesses can race and the reference is unsound. 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.

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.

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.

Affected versions of the OpenSSL crate used structures after they'd been freed.

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 features (as opposed to the lower-level `SslContext` type).

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.

### Impact `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. ### Patches `openssl` 0.10.70 fixes the signature of `ssl::select_next_proto` to properly constrain the output buffer's lifetime to that of both input buffers. ### Workarounds In standard usage of `ssl::select_next_proto` in the callback passed to `SslContextBuilder::set_alpn_select_callback`, code is only affected if the `server` buffer is constructed *within* the callback. For example: Not vulnerable - the server buffer has a `'static` lifetime: ```rust builder.set_alpn_select_callback(|_, client_protos| { ssl::select_next_proto(b"\x02h2", client_protos).ok_or_else(AlpnError::NOACK) }); ``` Not vulnerable - the server buffer outlives the handshake: ```rust let server_protos = b"\x02h2".to_vec(); builder.set_alpn_select_callback(|_, client_protos| { ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK) }); ``` Vulnerable - the server buffer is freed when the callback returns: ```rust builder.set_alpn_select_callback(|_, client_protos| { let server_protos = b"\x02h2".to_vec(); ssl::select_next_proto(&server_protos, client_protos).ok_or_else(AlpnError::NOACK) }); ``` ### References https://github.com/sfackler/rust-openssl/pull/2360

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.

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](https://github.com/quitbug/) for reporting this vulnerability to us.

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.

An issue was discovered in the openssl crate before 0.10.9 for Rust. A use-after-free occurs in CMS Signing.