Advisories.toml

[[advisory]]
id = "RUSTSEC-2016-0001"
package = "openssl"
patched_versions = [">= 0.9.0"]
date = "2016-11-05"
keywords = ["ssl", "mitm"]
url = "https://github.com/sfackler/rust-openssl/releases/tag/v0.9.0"
title = "SSL/TLS MitM vulnerability due to insecure defaults"
description = """
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).
"""

[[advisory]]
id = "RUSTSEC-2016-0002"
package = "hyper"
date = "2016-05-09"
url = "https://github.com/hyperium/hyper/blob/master/CHANGELOG.md#v094-2016-05-09"
title = "HTTPS MitM vulnerability due to lack of hostname verification"
keywords = ["ssl", "mitm"]
affected_platforms = ["*windows*"]
patched_versions = [">= 0.9.4"]
references = ["RUSTSEC-2016-0001"]
description = """
When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not
perform hostname verification when making HTTPS requests.

This allows an attacker to perform MitM attacks by preventing any valid
CA-issued certificate, even if there's a hostname mismatch.

The problem was addressed by leveraging rust-openssl's built-in support for
hostname verification.
"""

[[advisory]]
id = "RUSTSEC-2017-0001"
package = "sodiumoxide"
patched_versions = [">= 0.0.14"]
date = "2017-01-26"
url = "https://github.com/dnaq/sodiumoxide/issues/154"
title = "scalarmult() vulnerable to degenerate public keys"
description = """
The `scalarmult()` function included in previous versions of this crate
accepted all-zero public keys, for which the resulting Diffie-Hellman shared
secret will always be zero regardless of the private key used.

This issue was fixed by checking for this class of keys and rejecting them
if they are used.
"""

[[advisory]]
id = "RUSTSEC-2017-0002"
package = "hyper"
patched_versions = [">= 0.10.2", "< 0.10.0, >= 0.9.18"]
date = "2017-01-23"
url = "https://github.com/hyperium/hyper/wiki/Security-001"
title = "headers containing newline characters can split messages"
description = """
Serializing of headers to the socket did not filter the values for newline bytes (\r or \n),
which allowed for header values to split a request or response. People would not likely include
newlines in the headers in their own applications, so the way for most people to exploit this
is if an application constructs headers based on unsanitized user input.

This issue was fixed by replacing all newline characters with a space during serialization of
a header value.
"""

[[advisory]]
id = "RUSTSEC-2017-0003"
package = "security-framework"
patched_versions = [">= 0.1.12"]
date = "2017-03-15"
url = "https://github.com/sfackler/rust-security-framework/pull/27"
title = "Hostname verification skipped when custom root certs used"
description = """
If custom root certificates were registered with a `ClientBuilder`, the
hostname of the target server would not be validated against its presented leaf
certificate.

This issue was fixed by properly configuring the trust evaluation logic to
perform that check.
"""

[[advisory]]
id = "RUSTSEC-2017-0004"
package = "base64"
patched_versions = [">= 0.5.2"]
url = "https://github.com/alicemaz/rust-base64/commit/24ead980daf11ba563e4fb2516187a56a71ad319"
title = "Integer overflow leads to heap-based buffer overflow in encode_config_buf"
date = "2017-05-03"
description = """
Affected versions of this crate suffered from an integer overflow bug when
calculating the size of a buffer to use when encoding base64 using the
`encode_config_buf` and `encode_config` functions.  If the input string
was large, this would cause a buffer to be allocated that was too small.
Since this function writes to the buffer using unsafe code, it would
allow an attacker to write beyond the buffer, causing memory corruption
and possibly the execution of arbitrary code.

This flaw was corrected by using checked arithmetic to calculate
the size of the buffer.
"""

[[advisory]]
id = "RUSTSEC-2017-0005"
package = "cookie"
patched_versions = ["< 0.6.0", "^0.6.2", ">= 0.7.6"]
url = "https://github.com/alexcrichton/cookie-rs/pull/86"
title = "Large cookie Max-Age values can cause a denial of service"
date = "2017-05-06"
description = """
Affected versions of this crate use the `time` crate and the method
`Duration::seconds` to parse the `Max-Age` duration cookie setting. This method
will panic if the value is greater than 2^64/1000 and less than or equal to
2^64, which can result in denial of service for a client or server.

This flaw was corrected by explicitly checking for the `Max-Age` being in this
integer range and clamping the value to the maximum duration value.
"""

[[advisory]]
id = "RUSTSEC-2018-0001"
package = "untrusted"
unaffected_versions = []
patched_versions = [">= 0.6.2"]
url = "https://github.com/briansmith/untrusted/pull/20"
title = "An integer underflow could lead to panic"
date = "2018-06-21"
description = """
A mistake in error handling in untrusted before 0.6.2 could lead to an integer
underflow and panic if a user of the crate didn't properly check for errors
returned by untrusted.

Combination of these two programming errors (one in untrusted and another by
user of this crate) could lead to a panic and maybe a denial of service of
affected software.

The error in untrusted is fixed in release 0.6.2 released 2018-06-21. It's also
advisable that users of untrusted check for their sources for cases where errors
returned by untrusted are not handled correctly.
"""

[[advisory]]
id = "RUSTSEC-2018-0002"
package = "tar"
unaffected_versions = []
patched_versions = [">= 0.4.16"]
url = "https://github.com/alexcrichton/tar-rs/pull/156"
title = "Links in archives can overwrite any existing file"
date = "2018-06-29"
description = """
When unpacking a tarball with the `unpack_in`-family of functions it's intended
that only files within the specified directory are able to be written. Tarballs
with hard links or symlinks, however, can be used to overwrite any file on the
filesystem.

Tarballs can contain multiple entries for the same file. A tarball which first
contains an entry for a hard link or symlink pointing to any file on the
filesystem will have the link created, and then afterwards if the same file is
listed in the tarball the hard link will be rewritten and any file can be
rewritten on the filesystem.

This has been fixed in https://github.com/alexcrichton/tar-rs/pull/156 and is
published as `tar` 0.4.16. Thanks to Max Justicz for discovering this and
emailing about the issue!
"""

[[advisory]]
id = "RUSTSEC-2018-0003"
package = "smallvec"
unaffected_versions = ["< 0.3.2"]
patched_versions = [">= 0.6.3", "^0.3.4", "^0.4.5", "^0.5.1"]
url = "https://github.com/servo/rust-smallvec/issues/96"
title = "Possible double free during unwinding in SmallVec::insert_many"
date = "2018-07-19"
description = """
If an iterator passed to `SmallVec::insert_many` panicked in `Iterator::next`,
destructors were run during unwinding while the vector was in an inconsistent
state, possibly causing a double free (a destructor running on two copies of
the same value).

This is fixed in smallvec 0.6.3 by ensuring that the vector's length is not
updated to include moved items until they have been removed from their
original positions.  Items may now be leaked if `Iterator::next` panics, but
they will not be dropped more than once.

Thank you to @Vurich for reporting this bug.
"""