Vulnerabilities

RUSTSEC-2024-0344

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

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

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-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-2021-0139

ansi_term is Unmaintained

The maintainer has advised that this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

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;

• ansiterm
• anstyle
• console
• nu-ansi-term
• owo-colors
• stylish
• yansi

Dependency Specific Migration(s)

• structopt, clap2