File standard libary/core vulns (closes rustsec/rustsec#46)

Files vulnerabilities in the standard library originally reported at:

https://groups.google.com/forum/#!forum/rustlang-security-announcements

Or otherwise collected at:

rustsec/rustsec#46

The `rustsec` crate doesn't presently consume these, but I'd like to add
support ASAP.

rust/rustdoc/CVE-2018-1000622.toml

@@ -0,0 +1,96 @@
+[advisory]
+id = "CVE-2018-1000622"
+package = "rustdoc"
+date = "2018-07-05"
+title = "Uncontrolled search path element vulnerability in rustdoc plugins"
+description = """
+Rustdoc, if not passed the `--plugin-path` argument, defaults to
+`/tmp/rustdoc/plugins`. `/tmp` is world-writable on many systems, and so an
+attacker could craft a malicious plugin, place it in that directory, and the
+victim would end up executing their code. This only occurs when the
+`--plugin` argument is also passed. If you're not using that argument, then
+the loading, and therefore the bug, will not happen.
+
+Because this feature is very difficult to use, and has been deprecated for
+almost a year[2] with no comments on its usage, we don't expect this to
+affect many users. For more details, read on.
+
+## Background
+
+Rustdoc has a "plugins" feature that lets you extend rustdoc. To write a
+plugin, you create a library with a specific exposed symbol. You instruct
+rustdoc to use this plugin, and it will load it, and execute the function as
+a callback to modify rustdoc's AST.
+
+This feature is quite hard to use, because the function needs to take as
+input and return as output Rustdoc's AST type. The Rust project does not ship
+a copy of `librustdoc` to end users, and so they would have to synthesize
+this type on their own. Furthermore, Rust's ABI is unstable, and so
+dynamically loading a plugin is only guaranteed to work if the plugin is
+compiled with the same compiler revision as the rustdoc that you're using.
+Beyond that, the feature and how to use it are completely undocumented.
+
+Given all of this, we're not aware of any usage of plugins in the wild,
+though the functionality still exists in the codebase.
+
+## Description of the attack
+
+If you pass the `--plugins` parameter, let's say with "foo", and *do not*
+pass the `--plugin-path` parameter, rustdoc will look for the "foo" plugin
+in /tmp/rustdoc/plugins. Given that /tmp is world-writable on many systems,
+an attacker with access to your machine could place a maliciously crafted
+plugin into /tmp/rustdoc/plugins, and rustdoc would then load the plugin,
+and execute the attacker's callback, running arbitrary Rust code as your
+user instead of theirs.
+
+## Affected Versions
+
+This functionality was introduced into rustdoc on December 31, 2013, in commit
+14f59e890207f3b7a70bcfffaea7ad8865604111 [3]. That change was to rename
+/tmp/rustdoc_ng/plugins to /tmp/rustdoc/plugins; The addition of this
+search path generally came with the first commit to this iteration of rustdoc,
+on September 22, 2013, in commit 7b24efd6f333620ed2559d70b32da8f6f9957385 [4].
+
+## Mitigations
+
+To prevent this bug from happening on any version of Rust, you can always
+pass the `--plugin-path` flag to control the path. This only applies if
+you use the `--plugin` flag in the first place.
+
+For Rust 1.27, we'll be releasing a 1.27.1 on Tuesday with the fix, which
+consists of requiring `--plugin-path` to be passed whenever `--plugin`
+is passed.
+
+We will not be releasing our own fixes for previous versions of Rust, given
+the low severity and impact of this bug. The patch to fix 1.27 should be
+trivially applicable to previous versions, as this code has not changed in
+a very long time. The patch is included at the end of this email. If you
+need assistance patching an older version of Rust on your own, please reach
+out to Steve Klabnik, st...@steveklabnik.com, and he'll be happy to help.
+
+On beta and nightly we will be removing plugins entirely.
+
+## Timeline of events
+
+* Tue, Jul 3, 2018 at 11:57 PM UTC - Bug reported to security@rust-lang.org
+* Tue, Jul 3, 2018 at 12:13 PM UTC - Steve responds, confirming the bug
+* Weds, Jul 4, 2018 - Steve works up an initial patch
+* Thu, Jul 5, 2018 at 6:00 PM UTC - Rust team decides to not embargo this bug
+* Fri, Jul 6, 2018 at 12:38 AM - Final patch created after feedback from Red Hat
+
+## Acknowledgements
+
+Thanks to Red Hat Product Security, which found this bug. And specifically to
+Josh Stone, who took their findings and reported it to us in accordance with
+our security policy https://www.rust-lang.org/security.html, as well as providing
+feedback on the patch itself. You can find their bug at [5].
+
+[1]: https://cwe.mitre.org/data/definitions/427.html
+[2]: https://github.com/rust-lang/rust/issues/44136
+[3]: https://github.com/rust-lang/rust/commit/14f59e890207f3b7a70bcfffaea7ad8865604111
+[4]: https://github.com/rust-lang/rust/commit/7b24efd6f333620ed2559d70b32da8f6f9957385
+[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1597063
+"""
+patched_versions = ["> 1.27.0"]
+url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/4ybxYLTtXuM"
+cvss = "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"

rust/std/CVE-2018-1000657.toml

@@ -0,0 +1,15 @@
+[advisory]
+id = "CVE-2018-1000657"
+package = "std"
+date = "2018-09-21"
+title = "Buffer overflow vulnenrability in VecDeque::reserve()"
+description = """
+The `std::collections::vec_deque::VecDeque::reserve()` function contains a
+buffer overflow vulnerability that can potentially result in arbitrary code
+execution.
+"""
+patched_versions = [">= 1.22.0"]
+unaffected_versions = ["< 1.3.0"]
+categories = ["dos"]
+url = "https://github.com/rust-lang/rust/issues/44800"
+affected_functions = ["std::collections::vec_deque::VecDeque::reserve"]

rust/std/CVE-2018-1000810.toml

@@ -0,0 +1,103 @@
+[advisory]
+id = "CVE-2018-1000810"
+package = "std"
+date = "2018-09-21"
+title = "Buffer overflow vulnenrability in str::repeat()"
+description = """
+The Rust team was recently notified of a security vulnerability affecting
+the `str::repeat` function in the standard library. If your code does not
+use this function, it is not affected.
+
+We are applying for a CVE for this vulnerability, but since there is no
+embargo, we have not filed for one yet. Once a CVE is assigned, we'll make a
+second post to make mention of the CVE number.
+
+## Overview
+
+This vulnerability is an instance of CWE-680: Integer Overflow to Buffer
+Overflow[1].
+
+The `str::repeat` function in the standard library allows repeating a
+string a fixed number of times, returning an owned version of the final
+string. The capacity of the final string is calculated by multiplying
+the length of the string being repeated by the number of copies. This
+calculation can overflow, and this case was not properly checked for.
+
+The rest of the implementation of `str::repeat` contains unsafe code
+that relies on a preallocated vector having the capacity calculated
+earlier. On integer overflow the capacity will be less than required,
+and which then writes outside of the allocated buffer, leading to
+buffer overflow.
+
+## Affected Versions
+
+While the `str::repeat` function has been in Rust since 1.16.0, this
+vulnerability was introduced into the standard library in pull
+request #48657 [2]. The pull request was merged on March 6, 2018 and
+was first part of the 1.26.0 stable released on May 10, 2018.
+
+As such, this vulnerability affects:
+
+* Every nightly we've produced since March 6, 2018
+* Every beta produced since March 6, 2018
+* These specific Rust releases:
+  * 1.29.0
+  * 1.28.0
+  * 1.27.2
+  * 1.27.1
+  * 1.27.0
+  * 1.26.2
+  * 1.26.1
+  * 1.26.0
+
+## Mitigations
+
+This bug can be mitigated manually by auditing for calls to `str::repeat`
+and testing if the resulting vector's capacity will overflow. If it does,
+then the program should panic.
+
+For Rust 1.29, we'll be releasing a 1.29.1 on 2018-09-25 with the fix,
+which consists of checking for overflow and deterministically panicking
+if it happens. Nightlies and betas produced after 2019-09-21 will also
+contain a fix for this issue.
+
+We will not be releasing our own fixes for previous versions of Rust.
+The patch to fix 1.29 should roughly applicable to older versions, although
+the implementation has seen a few refactorings since it was introduced.
+The patch for 1.29 is included at the end of this email. If you
+need assistance patching an older version of Rust on your own, please reach
+out to our security mailing list, secu...@rust-lang.org, and we'll be happy
+to help.
+
+The current beta and nightly channels will be updated with a fix for this
+issue as well.
+
+## Timeline of events
+
+* Sun, Sep 16, 2018 at 20:24 PM - Bug reported to secu...@rust-lang.org
+* Mon, Sep 17, 2018 at 14:19 PM - Steve responds, confirming the bug
+* Tue, Sep 18, 2018 - Steve works up an initial patch
+* Wed, Sep 19, 2018 - Core team confirms 1.29.1 release date
+* Thu, Sep 20, 2018 - PRs posted to GitHub for
+stable[3]/beta[4]/master[5] branches
+* Fri, Sep 21, 2018 - Security list informed of this issue
+* (planned) Tue, Sep 25, 2018 - Rust 1.29.1 is released with a fix for
+this issue
+
+## Acknowledgements
+
+Thanks to Scott McMurray, who found this bug and reported it to us in
+accordance with our security policy https://www.rust-lang.org/security.html.
+
+[1]: https://cwe.mitre.org/data/definitions/680.html
+[2]: https://github.com/rust-lang/rust/pull/48657
+[3]: https://github.com/rust-lang/rust/pull/54397
+[4]: https://github.com/rust-lang/rust/pull/54398
+[5]: https://github.com/rust-lang/rust/pull/54399
+"""
+patched_versions = [">= 1.29.1"]
+unaffected_versions = ["< 1.26.0"]
+url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0"
+categories = ["dos"]
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
+affected_functions = ["std::str::repeat"]

rust/std/CVE-2019-12083.toml

@@ -0,0 +1,99 @@
+[advisory]
+id = "CVE-2019-12083"
+package = "std"
+date = "2019-05-13"
+title = "Memory safety vulnerabilities arising from `Error::type_id`"
+description = """
+The Rust team was recently notified of a security vulnerability affecting
+manual implementations of `Error::type_id` and their interaction with the
+`Error::downcast` family of functions in the standard library. If your code
+does not manually implement `Error::type_id` your code is not affected.
+
+We are applying for a CVE for this vulnerability, but since there is no
+embargo, we have not filed for one yet. Once a CVE is assigned, we'll make a
+second post to make mention of the CVE number.
+
+## Overview
+
+The `Error::type_id` function in the standard library was stabilized in the
+1.34.0 release on 2019-04-11. This function allows acquiring the concrete
+`TypeId` for the underlying error type to downcast back to the original type.
+This function has a default implementation in the standard library, but it can
+also be overridden by downstream crates. For example, the following is
+currently allowed on Rust 1.34.0 and Rust 1.34.1:
+
+```
+struct MyType;
+
+impl Error for MyType {
+    fn type_id(&self) -> TypeId {
+        // Enable safe casting to `String` by accident.
+        TypeId::of::<String>()
+    }
+}
+```
+
+When combined with the `Error::downcast*` family of methods this can enable
+safe casting of a type to the wrong type, causing security issues such as out
+of bounds reads/writes/etc.
+
+Prior to the 1.34.0 release this function was not stable and could not be
+either implemented or called in stable Rust.
+
+## Affected Versions
+
+The `Error::type_id` function was first stabilized in Rust 1.34.0, released on
+2019-04-11. The Rust 1.34.1 release, published 2019-04-25, is also affected.
+The `Error::type_id` function has been present, unstable, for all releases of
+Rust since 1.0.0 meaning code compiled with nightly may have been affected at
+any time.
+
+## Mitigations
+
+Immediate mitigation of this bug requires removing manual implementations of
+`Error::type_id`, instead inheriting the default implementation which is
+correct from a safety perspective. It is not the intention to have
+`Error::type_id` return `TypeId` instances for other types.
+
+For long term mitigation we are going to destabilize this function. This is
+unfortunately a breaking change for users calling `Error::type_id` and for
+users overriding `Error::type_id`. For users overriding it's likely memory
+unsafe, but users calling `Error::type_id` have only been able to do so on
+stable for a few weeks since the last 1.34.0 release, so it's thought that the
+impact will not be too great to overcome.
+
+We will be releasing a 1.34.2 point release on 2019-05-14 (tomorrow) which
+reverts [#58048][1] and destabilizes the `Error::type_id` function. The
+upcoming 1.35.0 release along with the beta/nightly channels will also all be
+updated with a destabilization.
+
+The final fate of the `Error::type_id` API isn't decided upon just yet and is
+the subject of [#60784][2]. No action beyond destabilization is currently
+planned so nightly code may continue to exhibit this issue. We hope to fully
+resolve this in the standard library soon.
+
+## Timeline of events
+
+* Thu, May  9, 2019 at 14:07 PM - Bug reported to secu...@rust-lang.org
+* Thu, May  9, 2019 at 15:10 PM - Alex reponds, confirming the bug
+* Fri, May 10, 2019 - Plan for mitigation developed and implemented
+* Mon, May 13, 2019 - PRs posted to GitHub for
+  [stable][3]/[beta][4]/[master][5] branches
+* Mon, May 13, 2019 - Security list informed of this issue
+* (planned) Tue, May 14, 2019 - Rust 1.34.2 is released with a fix for
+this issue
+
+## Acknowledgements
+
+Thanks to Sean McArthur, who found this bug and reported it to us in accordance
+with our security policy https://www.rust-lang.org/policies/security.
+
+[1]: https://github.com/rust-lang/rust/pull/58048
+[2]: https://github.com/rust-lang/rust/issues/60784
+[3]: https://github.com/rust-lang/rust/pull/60785
+[4]: https://github.com/rust-lang/rust/pull/60786
+[5]: https://github.com/rust-lang/rust/pull/60787
+"""
+patched_versions = ["> 1.34.1"]
+unaffected_versions = ["< 1.34.0"]
+url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70"