With versions of the whoami crate >= 0.5.3 and < 1.5.0, calling any of these functions leads to an
immediate stack buffer overflow on illumos and Solaris:

• whoami::username
• whoami::realname
• whoami::username_os
• whoami::realname_os

With versions of the whoami crate >= 0.5.3 and < 1.0.1, calling any of the above functions also
leads to a stack buffer overflow on these platforms:

• Bitrig
• DragonFlyBSD
• FreeBSD
• NetBSD
• OpenBSD

This occurs because of an incorrect definition of the passwd struct on those platforms.

As a result of this issue, denial of service and data corruption have both been observed in the
wild. The issue is possibly exploitable as well.

This vulnerability also affects other Unix platforms that aren't Linux or macOS.

This issue has been addressed in whoami 1.5.0.

For more information, see this GitHub issue.

Impact

When using named pipes on Windows, mio will under some circumstances return invalid tokens that correspond to named pipes that have already been deregistered from the mio registry. The impact of this vulnerability depends on how mio is used. For some applications, invalid tokens may be ignored or cause a warning or a crash. On the other hand, for applications that store pointers in the tokens, this vulnerability may result in a use-after-free.

For users of Tokio, this vulnerability is serious and can result in a use-after-free in Tokio.

The vulnerability is Windows-specific, and can only happen if you are using named pipes. Other IO resources are not affected.

Affected versions

This vulnerability has been fixed in mio v0.8.11.

All versions of mio between v0.7.2 and v0.8.10 are vulnerable.

Tokio is vulnerable when you are using a vulnerable version of mio AND you are using at least Tokio v1.30.0. Versions of Tokio prior to v1.30.0 will ignore invalid tokens, so they are not vulnerable.

Workarounds

Vulnerable libraries that use mio can work around this issue by detecting and ignoring invalid tokens.

Technical details

When an IO resource registered with mio has a readiness event, mio delivers that readiness event to the user using a user-specified token. Mio guarantees that when an IO resource is deregistered, then it will never return the token for that IO resource again. However, for named pipes on windows, mio may sometimes deliver the token for a named pipe even though the named pipe has been previously deregistered.

This vulnerability was originally reported in the Tokio issue tracker: tokio-rs/tokio#6369
This vulnerability was fixed in: tokio-rs/mio#1760

Thank you to @rofoun and @radekvit for discovering and reporting this issue.

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.

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.

The Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound
and may allow safe code to exhibit undefined behavior when used with Ref<B, T> where B
is cell::Ref or
cell::RefMut. Note that these
methods remain sound when used with B types other than cell::Ref or cell::RefMut.

See google/zerocopy#716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See
google/zerocopy#679 for more detail.

Switch to a different version of zerocopy to resolve this issue.

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.

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.

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.

Affected versions allocate memory using the alignment of usize and write data
to it of type u64, without using core::ptr::write_unaligned. In platforms
with sub-64bit alignment for usize (including wasm32 and x86) these writes
are insufficiently aligned some of the time.

If using an ordinary optimized standard library, the bug exhibits Undefined
Behavior so may or may not behave in any sensible way, depending on
optimization settings and hardware and other things. If using a Rust standard
library built with debug assertions enabled, the bug manifests deterministically
in a crash (non-unwinding panic) saying "ptr::write requires that the pointer
argument is aligned and non-null".

No 64-bit platform is impacted by the bug.

The flaw was corrected by allocating with adequately high alignment on all
platforms.