Vulnerabilities

RUSTSEC-2024-0344

Timing variability in curve25519-dalek's Scalar29::sub/Scalar52::sub

Details
Package	curve25519-dalek
Version	3.2.0
URL	dalek-cryptography/curve25519-dalek#659
Date	2024-06-18
Patched versions	>=4.1.3

Timing variability of any kind is problematic when working with potentially secret values such as
elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a
problem was recently discovered in curve25519-dalek.

The Scalar29::sub (32-bit) and Scalar52::sub (64-bit) functions contained usage of a mask value
inside a loop where LLVM saw an opportunity to insert a branch instruction (jns on x86) to
conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:

• 32-bit (see L106): <https://godbolt.org/z/zvaWxzvqv>
• 64-bit (see L48): <https://godbolt.org/z/PczYj7Pda>

A similar problem was recently discovered in the Kyber reference implementation:

<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ>

As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a
volatile read as an optimization barrier, which prevents the compiler from optimizing it away.

The fix can be validated in godbolt here:

• 32-bit: <https://godbolt.org/z/jc9j7eb8E>
• 64-bit: <https://godbolt.org/z/x8d46Yfah>

The problem was discovered and the solution independently verified by
Alexander Wagner <[email protected]> and Lea Themint <[email protected]> using
their DATA tool:

<https://github.com/Fraunhofer-AISEC/DATA>

RUSTSEC-2022-0093

Double Public Key Signing Function Oracle Attack on ed25519-dalek

Details
Package	ed25519-dalek
Version	1.0.1
URL	https://github.com/MystenLabs/ed25519-unsafe-libs
Date	2022-06-11
Patched versions	>=2

Versions of ed25519-dalek prior to v2.0 model private and public keys as
separate types which can be assembled into a Keypair, and also provide APIs
for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of
the inputs used in the deterministic computation of the S part of the signature,
but not in the R value. An adversary could somehow use the signing function as
an oracle that allows arbitrary public keys as input can obtain two signatures
for the same message sharing the same R and only differ on the S part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled
private/public keypair as signing input, except as part of specially labeled
"hazmat" APIs which are clearly labeled as being dangerous if misused.

RUSTSEC-2024-0336

rustls::ConnectionCommon::complete_io could fall into an infinite loop based on network input

Details
Package	rustls
Version	0.20.9
URL	GHSA-6g7w-8wpp-frhj
Date	2024-04-19
Patched versions	>=0.23.5,>=0.22.4, <0.23.0,>=0.21.11, <0.22.0

If a close_notify alert is received during a handshake, complete_io
does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io
and are not affected.

rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.

RUSTSEC-2023-0065

Tungstenite allows remote attackers to cause a denial of service

Details
Package	tungstenite
Version	0.17.3
URL	snapview/tungstenite-rs#376
Date	2023-09-25
Patched versions	>=0.20.1

The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause
a denial of service (minutes of CPU consumption) via an excessive length of an
HTTP header in a client handshake. The length affects both how many times a parse
is attempted (e.g., thousands of times) and the average amount of data for each
parse attempt (e.g., millions of bytes).

Warnings

RUSTSEC-2024-0375

atty is unmaintained

Details
Status	unmaintained
Package	atty
Version	0.2.14
URL	softprops/atty#57
Date	2024-09-25

The maintainer of atty has published an official notice that the crate is no longer
under development, and that users should instead rely on the functionality in the standard library's IsTerminal trait.

Alternative(s)

• std::io::IsTerminal - Stable since Rust 1.70.0 and the recommended replacement per the atty maintainer.
• is-terminal - Standalone crate supporting Rust older than 1.70.0

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-0071

Rusoto is unmaintained

Details
Status	unmaintained
Package	rusoto_credential
Version	0.48.0
URL	rusoto/rusoto#1651
Date	2022-04-24

The maintainers of Rusoto advise that all its crates are deprecated. This includes the common crates rusoto_core, rusoto_signature, rusoto_credential, and service crates such as rusoto_s3 and rusoto_ec2.

Users should migrate to the AWS SDK for Rust, which is maintained by AWS.

RUSTSEC-2022-0054

wee_alloc is Unmaintained

Details
Status	unmaintained
Package	wee_alloc
Version	0.4.5
URL	rustwasm/wee_alloc#107
Date	2022-05-11

Two of the maintainers have indicated that the crate may not be maintained.

The crate has open issues including memory leaks and may not be suitable for production use.

It may be best to switch to the default Rust standard allocator on wasm32 targets.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• Rust standard default allocator on wasm32-target

Honorable Mention(s)

The below may serve to educate on potential future alternatives:

• lol_alloc