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.
This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
trust-dns-proto(11 total, 8 outdated, 1 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| data-encoding | ^2.1.0 | 2.9.0 | up to date |
| error-chain | ^0.1.12 | 0.12.4 | out of date |
| futures | ^0.1.17 | 0.3.31 | out of date |
| log | ^0.3.5 | 0.4.28 | out of date |
| openssl ⚠️ | ^0.9.8 | 0.10.74 | out of date |
| rand | ^0.3 | 0.9.2 | out of date |
| ring | ^0.12 | 0.17.14 | out of date |
| tokio-core | ^0.1 | 0.1.18 | up to date |
| tokio-io | ^0.1 | 0.1.13 | up to date |
| untrusted | ^0.5 | 0.9.0 | out of date |
| url | ^1.6.0 | 2.5.7 | out of date |
openssl: `openssl` `X509NameBuilder::build` returned object is not thread safeOpenSSL 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.
openssl: `openssl` `SubjectAlternativeName` and `ExtendedKeyUsage::other` allow arbitrary file readSubjectAlternativeName 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: `openssl` `X509Extension::new` and `X509Extension::new_nid` null pointer dereferenceThese functions would crash when the context argument was None with certain extension types.
Thanks to David Benjamin (Google) for reporting this issue.
openssl: `openssl` `X509VerifyParamRef::set_host` buffer over-readWhen 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: `MemBio::get_buf` has undefined behavior with empty buffersPreviously, 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.
openssl: ssl::select_next_proto use after freeIn 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:
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:
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:
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)
});