Vulnerabilities

RUSTSEC-2023-0034

Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)

Details
Package	h2
Version	0.2.7
URL	hyperium/hyper#2877
Date	2023-04-14
Patched versions	>=0.3.17

If an attacker is able to flood the network with pairs of HEADERS/RST_STREAM frames, such that the h2 application is not able to accept them faster than the bytes are received, the pending accept queue can grow in memory usage. Being able to do this consistently can result in excessive memory use, and eventually trigger Out Of Memory.

This flaw is corrected in hyperium/h2#668, which restricts remote reset stream count by default.

RUSTSEC-2024-0332

Degradation of service in h2 servers with CONTINUATION Flood

Details
Package	h2
Version	0.2.7
Date	2024-04-03
Patched versions	^0.3.26,>=0.4.4

An attacker can send a flood of CONTINUATION frames, causing h2 to process them indefinitely.
This results in an increase in CPU usage.

Tokio task budget helps prevent this from a complete denial-of-service, as the server can still
respond to legitimate requests, albeit with increased latency.

More details at "https://seanmonstar.com/blog/hyper-http2-continuation-flood/.

Patches available for 0.4.x and 0.3.x versions.

RUSTSEC-2024-0003

Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)

Details
Package	h2
Version	0.2.7
Date	2024-01-17
Patched versions	^0.3.24,>=0.4.2

An attacker with an HTTP/2 connection to an affected endpoint can send a steady stream of invalid frames to force the
generation of reset frames on the victim endpoint.
By closing their recv window, the attacker could then force these resets to be queued in an unbounded fashion,
resulting in Out Of Memory (OOM) and high CPU usage.

This fix is corrected in hyperium/h2#737, which limits the total number of
internal error resets emitted by default before the connection is closed.

RUSTSEC-2024-0402

Borsh serialization of HashMap is non-canonical

Details
Package	hashbrown
Version	0.15.0
URL	rust-lang/hashbrown#576
Date	2024-10-11
Patched versions	>=0.15.1
Unaffected versions	<0.15.0

The borsh serialization of the HashMap did not follow the borsh specification.
It potentially produced non-canonical encodings dependent on insertion order.
It also did not perform canonicty checks on decoding.

This can result in consensus splits and cause equivalent objects to be
considered distinct.

This was patched in 0.15.1.

RUSTSEC-2021-0078

Lenient hyper header parsing of Content-Length could allow request smuggling

Details
Package	hyper
Version	0.13.10
URL	GHSA-f3pg-qwvg-p99c
Date	2021-07-07
Patched versions	>=0.14.10

hyper's HTTP header parser accepted, according to RFC 7230, illegal contents inside Content-Length headers.
Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.

To be vulnerable, hyper must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.

RUSTSEC-2021-0079

Integer overflow in hyper's parsing of the Transfer-Encoding header leads to data loss

Details
Package	hyper
Version	0.13.10
URL	GHSA-5h46-h7hh-c6x9
Date	2021-07-07
Patched versions	>=0.14.10

When decoding chunk sizes that are too large, hyper's code would encounter an integer overflow. Depending on the situation,
this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.

To be vulnerable, you must be using hyper for any HTTP/1 purpose, including as a client or server, and consumers must send
requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
any upstream proxies must accept a chunk size greater than 64 bits.

RUSTSEC-2024-0421

idna accepts Punycode labels that do not produce any non-ASCII when decoded

Details
Package	idna
Version	0.4.0
URL	https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
Date	2024-12-09
Patched versions	>=1.0.0

idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.

Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.

In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.

Remedy

Upgrade to idna 1.0.3 or later, if depending on idna directly, or to url 2.5.4 or later, if depending on idna via url. (This issue was fixed in idna 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)

When upgrading, please take a moment to read about alternative Unicode back ends for idna.

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an issue about combining them with url 2.5.4 and idna 1.0.3.

Additional information

This issue resulted from idna 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in revision 33 of UTS 46.

Acknowledgements

Thanks to kageshiron for recognizing the security implications of this behavior.

RUSTSEC-2024-0421

idna accepts Punycode labels that do not produce any non-ASCII when decoded

Details
Package	idna
Version	0.5.0
URL	https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
Date	2024-12-09
Patched versions	>=1.0.0

idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.

Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.

In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.

Remedy

Upgrade to idna 1.0.3 or later, if depending on idna directly, or to url 2.5.4 or later, if depending on idna via url. (This issue was fixed in idna 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)

When upgrading, please take a moment to read about alternative Unicode back ends for idna.

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an issue about combining them with url 2.5.4 and idna 1.0.3.

Additional information

This issue resulted from idna 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in revision 33 of UTS 46.

Acknowledgements

Thanks to kageshiron for recognizing the security implications of this behavior.

RUSTSEC-2023-0071

Marvin Attack: potential key recovery through timing sidechannels

Details
Package	rsa
Version	0.9.6
URL	RustCrypto/RSA#19 (comment)
Date	2023-11-22

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

RUSTSEC-2024-0399

rustls network-reachable panic in Acceptor::accept

Details
Package	rustls
Version	0.23.15
URL	rustls/rustls#2227
Date	2024-11-22
Patched versions	>=0.23.18
Unaffected versions	>=0.23, <0.23.13,<0.23

A bug introduced in rustls 0.23.13 leads to a panic if the received
TLS ClientHello is fragmented. Only servers that use
rustls::server::Acceptor::accept() are affected.

Servers that use tokio-rustls's LazyConfigAcceptor API are affected.

Servers that use tokio-rustls's TlsAcceptor API are not affected.

Servers that use rustls-ffi's rustls_acceptor_accept API are affected.

RUSTSEC-2021-0124

Data race when sending and receiving after closing a oneshot channel

Details
Package	tokio
Version	0.2.25
URL	tokio-rs/tokio#4225
Date	2021-11-16
Patched versions	>=1.8.4, <1.9.0,>=1.13.1
Unaffected versions	<0.1.14

If a tokio::sync::oneshot channel is closed (via the
oneshot::Receiver::close method), a data race may occur if the
oneshot::Sender::send method is called while the corresponding
oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used
after the Receiver half has called close. Code where close is not used, or where the
Receiver is not awaited and try_recv is not called after calling close,
is not affected.

See tokio#4225 for more details.

Warnings

RUSTSEC-2024-0388

derivative is unmaintained; consider using an alternative

Details
Status	unmaintained
Package	derivative
Version	2.2.0
URL	mcarton/rust-derivative#117
Date	2024-06-26

The derivative crate is no longer maintained.
Consider using any alternative, for instance:

• derive_more
• derive-where
• educe

RUSTSEC-2024-0384

instant is unmaintained

Details
Status	unmaintained
Package	instant
Version	0.1.13
Date	2024-09-01

This crate is no longer maintained, and the author recommends using the maintained web-time crate instead.

RUSTSEC-2020-0016

net2 crate has been deprecated; use socket2 instead

Details
Status	unmaintained
Package	net2
Version	0.2.39
URL	deprecrated/net2-rs@3350e38
Date	2020-05-01

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

RUSTSEC-2024-0370

proc-macro-error is unmaintained

Details
Status	unmaintained
Package	proc-macro-error
Version	1.0.4
URL	https://gitlab.com/CreepySkeleton/proc-macro-error/-/issues/20
Date	2024-09-01

proc-macro-error's maintainer seems to be unreachable, with no commits for 2 years, no releases pushed for 4 years, and no activity on the GitLab repo or response to email.

proc-macro-error also depends on syn 1.x, which may be bringing duplicate dependencies into dependant build trees.

Possible Alternative(s)

• manyhow
• proc-macro-error2
• proc-macro2-diagnostics

RUSTSEC-2022-0041

Unsoundness of AtomicCell<64> arithmetics on 32-bit targets that support Atomic64

Details
Status	unsound
Package	crossbeam-utils
Version	0.7.2
URL	crossbeam-rs/crossbeam#781
Date	2022-02-05

Impact

Affected versions of this crate incorrectly assumed that the alignment of {i,u}64 was always the same as Atomic{I,U}64.

However, the alignment of {i,u}64 on a 32-bit target can be smaller than Atomic{I,U}64.

This can cause the following problems:

• Unaligned memory accesses
• Data race

Crates using fetch_* methods with AtomicCell<{i,u}64> are affected by this issue.

32-bit targets without Atomic{I,U}64 and 64-bit targets are not affected by this issue.

32-bit targets with Atomic{I,U}64 and {i,u}64 have the same alignment are also not affected by this issue.

The following is a complete list of the builtin targets that may be affected. (last update: nightly-2022-02-11)

• armv7-apple-ios (tier 3)
• armv7s-apple-ios (tier 3)
• i386-apple-ios (tier 3)
• i586-unknown-linux-gnu
• i586-unknown-linux-musl
• i686-apple-darwin (tier 3)
• i686-linux-android
• i686-unknown-freebsd
• i686-unknown-haiku (tier 3)
• i686-unknown-linux-gnu
• i686-unknown-linux-musl
• i686-unknown-netbsd (tier 3)
• i686-unknown-openbsd (tier 3)
• i686-wrs-vxworks (tier 3)

(script to get list)

Patches

This has been fixed in crossbeam-utils 0.8.7.

Affected 0.8.x releases have been yanked.

Thanks to @taiki-e

RUSTSEC-2022-0022

Parser creates invalid uninitialized value

Details
Status	unsound
Package	hyper
Version	0.13.10
URL	hyperium/hyper#2545
Date	2022-05-10

Affected versions of this crate called mem::uninitialized() in the HTTP1 parser to create values of type httparse::Header (from the httparse crate).
This is unsound, since Header contains references and thus must be non-null.

The flaw was corrected by avoiding the use of mem::uninitialized(), using MaybeUninit instead.

RUSTSEC-2023-0005

tokio::io::ReadHalf<T>::unsplit is Unsound

Details
Status	unsound
Package	tokio
Version	0.2.25
URL	tokio-rs/tokio#5372
Date	2023-01-11

tokio::io::ReadHalf<T>::unsplit can violate the Pin contract

The soundness issue is described in the tokio/issues#5372

Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.

The tokio feature io-util is also required to be enabled to trigger this
soundness issue.

Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.

Tokio before 0.2.0 used futures 0.1 that did not have Pin, so it is not
affected by this issue.