OMGeeky/advisory-db
1
0
Fork 0
mirror of https://github.com/OMGeeky/advisory-db.git synced 2025-12-30 16:24:05 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into add-renderdoc-ub-vuln

Browse Source
This commit is contained in:
Eyal Kalderon
2019-09-03 01:14:08 +08:00
committed by GitHub
parent 64a69616a4 6e03d3c0b7
commit 6de62b1002
4 changed files with 307 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

97
rust/rustdoc/CVE-2018-1000622.toml Normal file
View File

@@ -0,0 +1,97 @@
[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"]
categories = ["code-execution"]
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"

15
rust/std/CVE-2018-1000657.toml Normal file
View File

@@ -0,0 +1,15 @@
[advisory]
id = "CVE-2018-1000657"
package = "std"
date = "2018-08-20"
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 = ["code-execution", "denial-of-service"]
url = "https://github.com/rust-lang/rust/issues/44800"
affected_functions = ["std::collections::vec_deque::VecDeque::reserve"]

99
rust/std/CVE-2018-1000810.toml Normal file
View File

@@ -0,0 +1,99 @@
[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.
## 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, security@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 security@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 = ["denial-of-service", "memory-corruption"]
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"]

96
rust/std/CVE-2019-12083.toml Normal file
View File

@@ -0,0 +1,96 @@
[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.
## 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 security@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"]
categories = ["memory-corruption"]
url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70"