Skip to content

Commit 842ee5d

Browse files
tarcieritarcieri
committed
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.
1 parent 706203c commit 842ee5d

File tree

4 files changed

+313
-0
lines changed

4 files changed

+313
-0
lines changed

‎rust/rustdoc/CVE-2018-1000622.toml

Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
[advisory]
2+
id = "CVE-2018-1000622"
3+
package = "rustdoc"
4+
date = "2018-07-05"
5+
title = "Uncontrolled search path element vulnerability in rustdoc plugins"
6+
description = """
7+
Rustdoc, if not passed the `--plugin-path` argument, defaults to
8+
`/tmp/rustdoc/plugins`. `/tmp` is world-writable on many systems, and so an
9+
attacker could craft a malicious plugin, place it in that directory, and the
10+
victim would end up executing their code. This only occurs when the
11+
`--plugin` argument is also passed. If you're not using that argument, then
12+
the loading, and therefore the bug, will not happen.
13+
14+
Because this feature is very difficult to use, and has been deprecated for
15+
almost a year[2] with no comments on its usage, we don't expect this to
16+
affect many users. For more details, read on.
17+
18+
## Background
19+
20+
Rustdoc has a "plugins" feature that lets you extend rustdoc. To write a
21+
plugin, you create a library with a specific exposed symbol. You instruct
22+
rustdoc to use this plugin, and it will load it, and execute the function as
23+
a callback to modify rustdoc's AST.
24+
25+
This feature is quite hard to use, because the function needs to take as
26+
input and return as output Rustdoc's AST type. The Rust project does not ship
27+
a copy of `librustdoc` to end users, and so they would have to synthesize
28+
this type on their own. Furthermore, Rust's ABI is unstable, and so
29+
dynamically loading a plugin is only guaranteed to work if the plugin is
30+
compiled with the same compiler revision as the rustdoc that you're using.
31+
Beyond that, the feature and how to use it are completely undocumented.
32+
33+
Given all of this, we're not aware of any usage of plugins in the wild,
34+
though the functionality still exists in the codebase.
35+
36+
## Description of the attack
37+
38+
If you pass the `--plugins` parameter, let's say with "foo", and *do not*
39+
pass the `--plugin-path` parameter, rustdoc will look for the "foo" plugin
40+
in /tmp/rustdoc/plugins. Given that /tmp is world-writable on many systems,
41+
an attacker with access to your machine could place a maliciously crafted
42+
plugin into /tmp/rustdoc/plugins, and rustdoc would then load the plugin,
43+
and execute the attacker's callback, running arbitrary Rust code as your
44+
user instead of theirs.
45+
46+
## Affected Versions
47+
48+
This functionality was introduced into rustdoc on December 31, 2013, in commit
49+
14f59e890207f3b7a70bcfffaea7ad8865604111 [3]. That change was to rename
50+
/tmp/rustdoc_ng/plugins to /tmp/rustdoc/plugins; The addition of this
51+
search path generally came with the first commit to this iteration of rustdoc,
52+
on September 22, 2013, in commit 7b24efd6f333620ed2559d70b32da8f6f9957385 [4].
53+
54+
## Mitigations
55+
56+
To prevent this bug from happening on any version of Rust, you can always
57+
pass the `--plugin-path` flag to control the path. This only applies if
58+
you use the `--plugin` flag in the first place.
59+
60+
For Rust 1.27, we'll be releasing a 1.27.1 on Tuesday with the fix, which
61+
consists of requiring `--plugin-path` to be passed whenever `--plugin`
62+
is passed.
63+
64+
We will not be releasing our own fixes for previous versions of Rust, given
65+
the low severity and impact of this bug. The patch to fix 1.27 should be
66+
trivially applicable to previous versions, as this code has not changed in
67+
a very long time. The patch is included at the end of this email. If you
68+
need assistance patching an older version of Rust on your own, please reach
69+
out to Steve Klabnik, st...@steveklabnik.com, and he'll be happy to help.
70+
71+
On beta and nightly we will be removing plugins entirely.
72+
73+
## Timeline of events
74+
75+
* Tue, Jul 3, 2018 at 11:57 PM UTC - Bug reported to security@rust-lang.org
76+
* Tue, Jul 3, 2018 at 12:13 PM UTC - Steve responds, confirming the bug
77+
* Weds, Jul 4, 2018 - Steve works up an initial patch
78+
* Thu, Jul 5, 2018 at 6:00 PM UTC - Rust team decides to not embargo this bug
79+
* Fri, Jul 6, 2018 at 12:38 AM - Final patch created after feedback from Red Hat
80+
81+
## Acknowledgements
82+
83+
Thanks to Red Hat Product Security, which found this bug. And specifically to
84+
Josh Stone, who took their findings and reported it to us in accordance with
85+
our security policy https://www.rust-lang.org/security.html, as well as providing
86+
feedback on the patch itself. You can find their bug at [5].
87+
88+
[1]: https://cwe.mitre.org/data/definitions/427.html
89+
[2]: https://github.com/rust-lang/rust/issues/44136
90+
[3]: https://github.com/rust-lang/rust/commit/14f59e890207f3b7a70bcfffaea7ad8865604111
91+
[4]: https://github.com/rust-lang/rust/commit/7b24efd6f333620ed2559d70b32da8f6f9957385
92+
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1597063
93+
"""
94+
patched_versions = ["> 1.27.0"]
95+
url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/4ybxYLTtXuM"
96+
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

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
[advisory]
2+
id = "CVE-2018-1000657"
3+
package = "std"
4+
date = "2018-09-21"
5+
title = "Buffer overflow vulnenrability in VecDeque::reserve()"
6+
description = """
7+
The `std::collections::vec_deque::VecDeque::reserve()` function contains a
8+
buffer overflow vulnerability that can potentially result in arbitrary code
9+
execution.
10+
"""
11+
patched_versions = [">= 1.22.0"]
12+
unaffected_versions = ["< 1.3.0"]
13+
categories = ["dos"]
14+
url = "https://github.com/rust-lang/rust/issues/44800"
15+
affected_functions = ["std::collections::vec_deque::VecDeque::reserve"]

‎rust/std/CVE-2018-1000810.toml

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
[advisory]
2+
id = "CVE-2018-1000810"
3+
package = "std"
4+
date = "2018-09-21"
5+
title = "Buffer overflow vulnenrability in str::repeat()"
6+
description = """
7+
The Rust team was recently notified of a security vulnerability affecting
8+
the `str::repeat` function in the standard library. If your code does not
9+
use this function, it is not affected.
10+
11+
We are applying for a CVE for this vulnerability, but since there is no
12+
embargo, we have not filed for one yet. Once a CVE is assigned, we'll make a
13+
second post to make mention of the CVE number.
14+
15+
## Overview
16+
17+
This vulnerability is an instance of CWE-680: Integer Overflow to Buffer
18+
Overflow[1].
19+
20+
The `str::repeat` function in the standard library allows repeating a
21+
string a fixed number of times, returning an owned version of the final
22+
string. The capacity of the final string is calculated by multiplying
23+
the length of the string being repeated by the number of copies. This
24+
calculation can overflow, and this case was not properly checked for.
25+
26+
The rest of the implementation of `str::repeat` contains unsafe code
27+
that relies on a preallocated vector having the capacity calculated
28+
earlier. On integer overflow the capacity will be less than required,
29+
and which then writes outside of the allocated buffer, leading to
30+
buffer overflow.
31+
32+
## Affected Versions
33+
34+
While the `str::repeat` function has been in Rust since 1.16.0, this
35+
vulnerability was introduced into the standard library in pull
36+
request #48657 [2]. The pull request was merged on March 6, 2018 and
37+
was first part of the 1.26.0 stable released on May 10, 2018.
38+
39+
As such, this vulnerability affects:
40+
41+
* Every nightly we've produced since March 6, 2018
42+
* Every beta produced since March 6, 2018
43+
* These specific Rust releases:
44+
* 1.29.0
45+
* 1.28.0
46+
* 1.27.2
47+
* 1.27.1
48+
* 1.27.0
49+
* 1.26.2
50+
* 1.26.1
51+
* 1.26.0
52+
53+
## Mitigations
54+
55+
This bug can be mitigated manually by auditing for calls to `str::repeat`
56+
and testing if the resulting vector's capacity will overflow. If it does,
57+
then the program should panic.
58+
59+
For Rust 1.29, we'll be releasing a 1.29.1 on 2018-09-25 with the fix,
60+
which consists of checking for overflow and deterministically panicking
61+
if it happens. Nightlies and betas produced after 2019-09-21 will also
62+
contain a fix for this issue.
63+
64+
We will not be releasing our own fixes for previous versions of Rust.
65+
The patch to fix 1.29 should roughly applicable to older versions, although
66+
the implementation has seen a few refactorings since it was introduced.
67+
The patch for 1.29 is included at the end of this email. If you
68+
need assistance patching an older version of Rust on your own, please reach
69+
out to our security mailing list, secu...@rust-lang.org, and we'll be happy
70+
to help.
71+
72+
The current beta and nightly channels will be updated with a fix for this
73+
issue as well.
74+
75+
## Timeline of events
76+
77+
* Sun, Sep 16, 2018 at 20:24 PM - Bug reported to secu...@rust-lang.org
78+
* Mon, Sep 17, 2018 at 14:19 PM - Steve responds, confirming the bug
79+
* Tue, Sep 18, 2018 - Steve works up an initial patch
80+
* Wed, Sep 19, 2018 - Core team confirms 1.29.1 release date
81+
* Thu, Sep 20, 2018 - PRs posted to GitHub for
82+
stable[3]/beta[4]/master[5] branches
83+
* Fri, Sep 21, 2018 - Security list informed of this issue
84+
* (planned) Tue, Sep 25, 2018 - Rust 1.29.1 is released with a fix for
85+
this issue
86+
87+
## Acknowledgements
88+
89+
Thanks to Scott McMurray, who found this bug and reported it to us in
90+
accordance with our security policy https://www.rust-lang.org/security.html.
91+
92+
[1]: https://cwe.mitre.org/data/definitions/680.html
93+
[2]: https://github.com/rust-lang/rust/pull/48657
94+
[3]: https://github.com/rust-lang/rust/pull/54397
95+
[4]: https://github.com/rust-lang/rust/pull/54398
96+
[5]: https://github.com/rust-lang/rust/pull/54399
97+
"""
98+
patched_versions = [">= 1.29.1"]
99+
unaffected_versions = ["< 1.26.0"]
100+
url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/CmSuTm-SaU0"
101+
categories = ["dos"]
102+
cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
103+
affected_functions = ["std::str::repeat"]

‎rust/std/CVE-2019-12083.toml

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
[advisory]
2+
id = "CVE-2019-12083"
3+
package = "std"
4+
date = "2019-05-13"
5+
title = "Memory safety vulnerabilities arising from `Error::type_id`"
6+
description = """
7+
The Rust team was recently notified of a security vulnerability affecting
8+
manual implementations of `Error::type_id` and their interaction with the
9+
`Error::downcast` family of functions in the standard library. If your code
10+
does not manually implement `Error::type_id` your code is not affected.
11+
12+
We are applying for a CVE for this vulnerability, but since there is no
13+
embargo, we have not filed for one yet. Once a CVE is assigned, we'll make a
14+
second post to make mention of the CVE number.
15+
16+
## Overview
17+
18+
The `Error::type_id` function in the standard library was stabilized in the
19+
1.34.0 release on 2019-04-11. This function allows acquiring the concrete
20+
`TypeId` for the underlying error type to downcast back to the original type.
21+
This function has a default implementation in the standard library, but it can
22+
also be overridden by downstream crates. For example, the following is
23+
currently allowed on Rust 1.34.0 and Rust 1.34.1:
24+
25+
```
26+
struct MyType;
27+
28+
impl Error for MyType {
29+
fn type_id(&self) -> TypeId {
30+
// Enable safe casting to `String` by accident.
31+
TypeId::of::<String>()
32+
}
33+
}
34+
```
35+
36+
When combined with the `Error::downcast*` family of methods this can enable
37+
safe casting of a type to the wrong type, causing security issues such as out
38+
of bounds reads/writes/etc.
39+
40+
Prior to the 1.34.0 release this function was not stable and could not be
41+
either implemented or called in stable Rust.
42+
43+
## Affected Versions
44+
45+
The `Error::type_id` function was first stabilized in Rust 1.34.0, released on
46+
2019-04-11. The Rust 1.34.1 release, published 2019-04-25, is also affected.
47+
The `Error::type_id` function has been present, unstable, for all releases of
48+
Rust since 1.0.0 meaning code compiled with nightly may have been affected at
49+
any time.
50+
51+
## Mitigations
52+
53+
Immediate mitigation of this bug requires removing manual implementations of
54+
`Error::type_id`, instead inheriting the default implementation which is
55+
correct from a safety perspective. It is not the intention to have
56+
`Error::type_id` return `TypeId` instances for other types.
57+
58+
For long term mitigation we are going to destabilize this function. This is
59+
unfortunately a breaking change for users calling `Error::type_id` and for
60+
users overriding `Error::type_id`. For users overriding it's likely memory
61+
unsafe, but users calling `Error::type_id` have only been able to do so on
62+
stable for a few weeks since the last 1.34.0 release, so it's thought that the
63+
impact will not be too great to overcome.
64+
65+
We will be releasing a 1.34.2 point release on 2019-05-14 (tomorrow) which
66+
reverts [#58048][1] and destabilizes the `Error::type_id` function. The
67+
upcoming 1.35.0 release along with the beta/nightly channels will also all be
68+
updated with a destabilization.
69+
70+
The final fate of the `Error::type_id` API isn't decided upon just yet and is
71+
the subject of [#60784][2]. No action beyond destabilization is currently
72+
planned so nightly code may continue to exhibit this issue. We hope to fully
73+
resolve this in the standard library soon.
74+
75+
## Timeline of events
76+
77+
* Thu, May 9, 2019 at 14:07 PM - Bug reported to secu...@rust-lang.org
78+
* Thu, May 9, 2019 at 15:10 PM - Alex reponds, confirming the bug
79+
* Fri, May 10, 2019 - Plan for mitigation developed and implemented
80+
* Mon, May 13, 2019 - PRs posted to GitHub for
81+
[stable][3]/[beta][4]/[master][5] branches
82+
* Mon, May 13, 2019 - Security list informed of this issue
83+
* (planned) Tue, May 14, 2019 - Rust 1.34.2 is released with a fix for
84+
this issue
85+
86+
## Acknowledgements
87+
88+
Thanks to Sean McArthur, who found this bug and reported it to us in accordance
89+
with our security policy https://www.rust-lang.org/policies/security.
90+
91+
[1]: https://github.com/rust-lang/rust/pull/58048
92+
[2]: https://github.com/rust-lang/rust/issues/60784
93+
[3]: https://github.com/rust-lang/rust/pull/60785
94+
[4]: https://github.com/rust-lang/rust/pull/60786
95+
[5]: https://github.com/rust-lang/rust/pull/60787
96+
"""
97+
patched_versions = ["> 1.34.1"]
98+
unaffected_versions = ["< 1.34.0"]
99+
url = "https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70"

0 commit comments

Comments
 (0)