Vulnerabilities

RUSTSEC-2022-0093

Double Public Key Signing Function Oracle Attack on ed25519-dalek

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

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

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

Rusoto is unmaintained

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

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