Summary: Traversal outside working tree enables arbitrary code execution

### Summary

During checkout, gitoxide does not verify that paths point to locations in the working tree. A specially crafted repository can, when cloned, place new files anywhere writable by the application.

### Details

Although `gix-worktree-state` checks for collisions with existing files, it does not itself check if a path is really in the working tree when performing a checkout, nor do the path checks in `gix-fs` and `gix-worktree` prevent this. Cloning an untrusted repository containing specially crafted tree or blob names will create new files outside the repository, or inside the repository or a submodule's `.git` directory. The simplest cases are:

- A tree named `..` to traverse upward. This facilitates arbitrary code execution because files can be placed in one or more locations where they are likely to be executed soon.
- A tree named `.git` to enter a `.git` directory. This facilitates arbitrary code execution because hooks can be installed.

A number of alternatives that achieve the same effect are also possible, some of which correspond to specific vulnerabilities that have affected Git in the past:

- A tree or blob whose name contains one or more `/`, to traverse upward or downward. For example, even without containing any tree named `..` or `.git`, a repository can represent a file named `../outside` or `.git/hooks/pre-commit`. This is distinct from the more intuitive case a repository containing trees that represent those paths.
- In Windows, a tree or blob whose name contains one or more `\`, to traverse upward or downward. (Unlike `/`, these are valid on other systems.) See [GHSA-xjx4-8694-q2fq](https://github.com/git/git/security/advisories/GHSA-xjx4-8694-q2fq).
- On a case-insensitive filesystem (such as NTFS, APFS, or HFS+), a tree named as a case variant of `.git`.
- On HFS+, a tree named like `.git` or a case variant, with characters added that HFS+ ignores [in collation](https://developer.apple.com/library/archive/technotes/tn/tn1150.html#StringComparisonAlgorithm). See https://github.com/git/git/commit/6162a1d323d24fd8cbbb1a6145a91fb849b2568f.
- On NTFS, a tree equivalent to `.git` (or a case variant) by the use of [NTFS stream](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3) notation, such as `.git::$INDEX_ALLOCATION`. See [GHSA-5wph-8frv-58vj](https://github.com/git/git/security/advisories/GHSA-5wph-8frv-58vj).
- On an NTFS volume with [8.3 aliasing](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#short-vs-long-names) enabled, a tree named as `git~1` (or a case variant). See [GHSA-589j-mmg9-733v](https://github.com/git/git/security/advisories/GHSA-589j-mmg9-733v).

When a checkout creates some files outside the repository directory but fails to complete, the repository directory is usually removed, but the outside files remain.

### PoC

For simplicity, these examples stage a stand-in file with a valid name, modify the index, and commit. The instructions assume `sed` supports `-i`, which is the case on most systems. If using Windows, a Git Bash shell should be used.

#### Example: Downward traversal to install hooks

1. Create a new repository with `git init dangerous-repo-installs-hook` and `cd` into the directory.
2. Create the stand-in called `.git@hooks@pre-commit`, with the *contents*:
   ```sh
   #!/bin/sh
   printf 'Vulnerable!\n'
   date >vulnerable
   ```
3. Stage the stand-in: `git add --chmod=+x .git@hooks@pre-commit`
4. Edit the index: `env LC_ALL=C sed -i.orig 's|\.git@hooks@pre-commit|.git/hooks/pre-commit|' .git/index`
5. Commit: `git commit -m 'Initial commit'`
6. *Optionally*, push to a private remote.

Then, on another or the same machine:

1. Clone the repository with a `gix clone …` command.
2. Enter the newly created directory.
3. *Optionally* run `ls -l .git/hooks` to observe that the `pre-commit` hook is already present.
4. Make a new file and commit it with `git`. This causes the payload surreptitiously installed as a `pre-commit` hook to run, printing the message `Vulnerable!` and creating a file in the current directory containing the current date and time.

Note that the effect is not limited to modifying the current directory. The payload could be written to perform any action that the user who runs `git commit` is capable of.

#### Example: Upward traversal to create a file above the working tree

1. Create a new repository with `git init dangerous-repo-reaches-up`, and `cd` into the directory.
2. Create the stand-in: `echo 'A file outside the working tree, somehow.' >..@outside`
3. Stage the stand-in: `git add ..@outside`
4. Edit the index: `env LC_ALL=C sed -i.orig 's|\.\.@outside|../outside|' .git/index`
5. Commit: `git commit -m 'Initial commit'`
6. *Optionally*, push to a private remote.

Then, as above, on the same or another machine, clone the repository with a `gix clone …` command. Observe that a file named `outside` is present alongside (not inside) the cloned directory.

### Impact

Any use of `gix` or another application that makes use of `gix-worktree-state`, or otherwise relies on `gix-fs` and `gix-worktree` for validation, is affected, if used to clone untrusted repositories. The above description focuses on code execution, as that leads to a complete loss of confidentiality, integrity, and availability, but creating files outside a working tree without attempting to execute code can directly impact integrity as well.

In use cases where no untrusted repository is ever cloned, this vulnerability has no impact. Furthermore, the impact of this vulnerability *may* be lower when `gix` is used to clone a repository for CI/CD purposes, even if untrusted, since in such uses the environment is usually isolated and arbitrary code is usually run deliberately from the repository with necessary safeguards in place.


Summary: Refs and paths with reserved Windows device names access the devices

### Summary

On Windows, fetching refs that clash with legacy device names reads from the devices, and checking out paths that clash with such names writes arbitrary data to the devices. This allows a repository, when cloned, to cause indefinite blocking or the production of arbitrary message that appear to have come from the application, and potentially other harmful effects under limited circumstances.

### Details

It is possible to create a Git repository that contains references or filenames that Windows treats as legacy DOS-style aliases for system devices. When such a repository is cloned:

- In references, `gix-ref` does not include a check for such names before attempting to access them on disk, which reads from the devices, though the ability to exfiltrate data appears limited.
- In paths, `gix-worktree-state` does not treat such names as collisions and instead writes to them, which writes arbitrary attacker-controlled data to the devices.

Some such device names refer to devices that are often absent or inaccessible. But a few are guaranteed to be available, allowing some attacks to be carried out with low complexity. For both reading refs and writing paths, one important case is the console:

- Reading a ref whose last component (e.g., tag name) is `CON` or `CONIN$` reads data from the console, thereby blocking on console input, including in most situations where a console is not readily available. This may facilitate denial of service attacks.
- Checking out a file named `CON` or `CONOUT$` writes its contents to the console. This allows an untrusted repository to produce arbitrary text that appears to be a message from the application. Such text may facilitate social engineering if it is selected to instruct the user to perform a particular action.

Another potentially important case is serial ports. For example, `COM1` refers to the first serial port, if present. A malicious repository may be able to disrupt intended use of serial ports or attempt to interact with a device. In some configurations, it may be possible to interfere with the operation of a physical or virtual serial console. On Windows, local access to serial ports is often permitted even for limited user accounts without elevation.

[Naming Files, Paths, and Namespaces](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions) covers most reserved names. `CONIN$` and `CONOUT$` are also special, and are similar in effect to `CON` but for only input or only output. These names are case-insensitive and can also be accessed with file extensions (e.g, `CON.txt` is equivalent to `CON`) and with some variations involving added spaces or colons.

### PoC

#### Ref example

Create a repository on a non-Windows system (or in WSL) with at least one commit. Use `git tag CON` to create a lightweight tag named `CON`. Place the repository somewhere it can be cloned on Windows. A `file://` URL is sufficient for testing if a private remote is unavailable. If using `git push`, pass `--tags` so the remote has the tag.

On a Windows system, clone the repository with `gix clone`. This command will block immediately, reading input from the console. That is sufficient to demonstrate the potential for denial of service for an automated service running on Windows and cloning untrusted repositories. The experiment can be stopped with Ctrl+C.

However, if desired, input can be provided. Ending input with Ctrl+Z followed by Enter will cause it to be passed to the application. This will lead to an error message, the specific details of which vary by whether the input is empty or nonempty, and whether it matches or does not match the hexadecimal hash of the tagged commit.

#### Path example

Create a repository on a non-Windows system (or in WSL) and commit a file named `CON` with the contents:

```text
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
```

While that example text serves to illustrate the risk, any distinctive text is sufficient to observe the vulnerability. Place the repository somewhere it can be cloned on Windows. As above, a `file://` URL is sufficient.

On a Windows system, clone the repository with `gix clone`. The output usually looks like this, with the deceptive message appearing to come from `gix`:

```text
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
 04:45:15 indexing done 3.0 objects in 0.00s (12.1K objects/s)
 04:45:15 decompressing done 309B in 0.00s (1.2MB/s)
 04:45:15     Resolving done 3.0 objects in 0.05s (58.0 objects/s)
 04:45:15      Decoding done 309B in 0.05s (6.0KB/s)
 04:45:15 writing index file done 1.2KB in 0.00s (7.0MB/s)
 04:45:15  create index file done 3.0 objects in 0.05s (55.0 objects/s)
 04:45:15          read pack done 294B in 0.05s (5.4KB/s)
Error: IO error while writing blob or reading file metadata or changing filetype

Caused by:
    Incorrect function. (os error 1)
```

The exact placement of the message is nondeterministic. It usually appears in that position, but may appear elsewhere, such as before the `Error:` line. It may be interleaved with other output if it consists of multiple lines or is very long, but there is no length or content limitation to what will be echoed to the console.

### Impact

If Windows is not used, or untrusted repositories are not cloned or otherwise used, then there is no impact.

The impact is expected to be limited in common configurations, but may vary widely depending on what devices exist, how they are being used, how much knowledge an attacker has of the precise details of their use, and whether the user is likely to trust information that appears in a console. Accessing devices through refs is expected to be less dangerous than accessing them through filenames, since it is trivial to attempt to write arbitrary data using filenames.

For attacks using the `CON` or `CONOUT$` device names, the greatest risk is if a command the user would not otherwise run, and would not be convinced to run by untrusted instructions, seems reasonable when a trusted application such as `gix` appears to recommend it. The user may then be misled into running an attacker's command.

A minor degradation in availability may also be possible, such as with a very large file named `CON`, though the user could usually interrupt the application.


Summary: Usage of non-constant time base64 decoder could lead to leakage of secret key material

Versions before 0.7.0 of vodozemac use a non-constant time base64 implementation
for importing key material for Megolm group sessions and `PkDecryption` Ed25519
secret keys. This flaw might allow an attacker to infer some information about
the secret key material through a side-channel attack.

## Impact

The use of a non-constant time base64 implementation might allow an attacker to
observe timing variations in the encoding and decoding operations of the secret
key material. This could potentially provide insights into the underlying secret
key material.

The impact of this vulnerability is considered low because exploiting the
attacker is required to have access to high precision timing measurements, as
well as repeated access to the base64 encoding or decoding processes.
Additionally, the estimated leakage amount is bounded and low according to the
referenced paper[[1]].

[1]: https://arxiv.org/abs/2108.04600


Summary: gix-path can use a fake program files location

### Summary

When looking for Git for Windows so it can run it to report its paths, `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account.

### Details

Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking [two hard-coded paths](https://github.com/Byron/gitoxide/blob/6cd8b4665bb7582f744c3244abaef812be39ec35/gix-path/src/env/git.rs#L9-L14) intended to be the 64-bit and 32-bit Program Files directories:

```rust
/// Other places to find Git in.
#[cfg(windows)]
pub(super) static ALTERNATIVE_LOCATIONS: &[&str] = &[
    "C:/Program Files/Git/mingw64/bin",
    "C:/Program Files (x86)/Git/mingw32/bin",
];
```

Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it.

Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\Program Files (x86)` directory.

A limited user on a 32-bit Windows system can therefore create the `C:\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other user accounts including administrators will execute it if they run an application that uses `gix-path` and do not have `git` in a `PATH` directory.

(While having `git` found in a `PATH` search prevents exploitation, merely having it installed in the default location under the real `C:\Program Files` directory does not. This is because the first hard-coded path's `mingw64` component assumes a 64-bit installation.)

### PoC

On a 32-bit (x86) Windows 10 system, with or without Git for Windows installed:

1. Create a limited user account in `lusrmgr.msc` or the Settings application.
2. Log in with that account and, using Windows Explorer or the `mkdir` command in PowerShell, create the directories `C:\Program Files (x86)\Git\mingw32\bin`. Although a limited user account cannot create regular files directly in `C:\`, it can create directories including one called `Program Files (x86)`.
3. Place a copy of `C:\Windows\system32\calc.exe` in `C:\Program Files (x86)\Git\mingw32\bin` and rename it from `calc.exe` to `git.exe`. A different test payload may be used if preferred, and the executable need not already be signed or trusted.
4. Log out, and log in as a different user. This user may be an administrator.
5. If `gitoxide` is not installed, install it. If `cargo install gitoxide` is used for the installation, then the version of `gix-path` used in the installation can be observed.
6. The vulnerability is only exploitable if `git` cannot be found in a `PATH` search. So, in PowerShell, run `gcm git` to check if `git` is present in the `PATH`. If so, temporarily remove it. One way to do this is for the current shell only, by running `$env:PATH` to inspect it and by assigning `$env:PATH = '...'` where `...` omits directories that contain `git`.
7. Some commands that can be run outside a repository, and most commands that can be run inside a repository, will run the Calculator or other payload at least once per invocation. Try `gix clone foo` or, inside of a repository, `gix status`, `gix config`, `gix is-changed`, `gix fetch`, `ein t hours`, or `ein t query`. This is not exhaustive; most other `gix` and `ein` commands that access existing repository state or a network resource likewise run the payload.

### Impact

Only Windows is affected. Exploitation is unlikely except on a 32-bit system. In particular, running a 32-bit build on a 64-bit system is not a risk factor. Furthermore, the attacker must have a user account on the system, though it may be a relatively unprivileged account. Such a user can perform privilege escalation and execute code as another user, though it may be difficult to do so reliably because the targeted user account must run an application or service that uses `gix-path` and must not have `git` in its `PATH`.

The main exploitable configuration is one where Git for Windows has been installed but not added to `PATH`. This is one of the options in its installer, though not the default option. Alternatively, an affected program that sanitizes its `PATH` to remove seemingly nonessential directories could allow exploitation. But for the most part, if the target user has configured a `PATH` in which the real `git.exe` can be found, then this cannot be exploited.

This vulnerability is comparable to [CVE-2022-24765](https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2), in which an uncontrolled path like `C:\.git\config`, which a limited user can create, could supply configuration used by other users. However, in this case, exploitation is slightly simpler because, rather than using configuration, an executable is directly run.


Summary: `UserIdentity::is_verified` not checking verification status of own user identity while performing the check

The `UserIdentity::is_verified()` method in the matrix-sdk-crypto crate before
version 0.7.2 doesn't take into account the verification status of the user's
own identity while performing the check and may as a result return a value
contrary to what is implied by its name and documentation.

## Impact

If the method is used to decide whether to perform sensitive operations towards
a user identity, a malicious homeserver could manipulate the outcome in order to
make the identity appear trusted. This is not a typical usage of the method,
which lowers the impact. The method itself is not used inside the
matrix-sdk-crypto crate.


Summary: `MemBio::get_buf` has undefined behavior with empty buffers

Previously, `MemBio::get_buf` called `slice::from_raw_parts` with a null-pointer, which violates the functions invariants, leading to undefined behavior. In debug builds this would produce an assertion failure. This is now fixed.


Summary: Apache Arrow Rust Object Store: AWS WebIdentityToken exposure in log files

Exposure of temporary credentials in logs in Apache Arrow Rust Object Store,
version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens.

On certain error conditions, the logs may contain the OIDC token passed to
[AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html).
This allows someone with access to the logs to impersonate that identity,
including performing their own calls to AssumeRoleWithWebIdentity, until the
OIDC token expires. Typically OIDC tokens are valid for up to an hour, although
this will vary depending on the issuer.

Users are recommended to use a different AWS authentication mechanism, disable
logging or upgrade to version 0.10.2, which fixes this issue.

## Details

When using AWS WebIdentityTokens with the `object_store` crate, in the event of
a failure and automatic retry, the underlying `reqwest` error, including the
full URL with the credentials, potentially in the parameters, is written to the
logs.

Thanks to Paul Hatcherian for reporting this vulnerability


Summary: The kstring integration in gix-attributes is unsound

`gix-attributes` (in [`state::ValueRef`](https://github.com/Byron/gitoxide/blob/gix-attributes-v0.22.2/gix-attributes/src/state.rs#L19-L27)) unsafely creates a `&str` from a `&[u8]` containing non-UTF8 data, with the justification that so long as nothing reads the `&str` and relies on it being UTF-8 in the `&str`, there is no UB:

```rust
// SAFETY: our API makes accessing that value as `str` impossible, so illformed UTF8 is never exposed as such.
```

The problem is that the non-UTF8 `str` **is** exposed to outside code: first to the `kstring` crate itself, which requires UTF-8 in its documentation and may have UB as a consequence of this, but also to `serde`, where it propagates to e.g. `serde_json`, `serde_yaml`, etc., where the same problems occur.

This is not sound, and it could cause further UB down the line in these places that can view the `&str`.

*Thanks to [Devin Jeanpierre](https://github.com/ssbr) for discovering and reporting this issue.*


Summary: `XmpFile::close` can trigger UB

Affected versions of the crate failed to catch C++ exceptions raised within the `XmpFile::close` function. If such an exception occured, it would trigger undefined behavior, typically a process abort.

This is best demonstrated in [issue #230](https://github.com/adobe/xmp-toolkit-rs/issues/230), where a race condition causes the `close` call to fail due to file I/O errors.

This was fixed in [PR #232](https://github.com/adobe/xmp-toolkit-rs/pull/232) (released as crate version 1.9.0), which now safely handles the exception.

For backward compatibility, the existing API ignores the error. A new API `XmpFile::try_close` was added to allow callers to receive and process the error result.

Users of all prior versions of `xmp_toolkit` are encouraged to update to version 1.9.0 to avoid undefined behavior.


Summary: CWA-2024-004: Gas mispricing in cosmwasm-vm

Some Wasm operations take significantly more gas than our benchmarks indicated. This can lead to missing the gas target we defined by a factor of ~10x. This means a malicious contract could take 10 times as much time to execute as expected, which can be used to temporarily DoS a chain.

For more information, see [CWA-2024-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2024-004.md).


Summary: Stack overflow when parsing specially crafted JSON ABI strings

Affected versions of the `alloy-json-abi` crate did not properly handle parsing of malformatted JSON ABI strings. The `JsonAbi::parse` method can be tricked into a stack overflow when processing specially crafted input.

This stack overflow can lead to a crash of the application using this crate, potentially causing a denial of service.

The flaw was corrected in commit 4790c47.


Summary: Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts

The following presentation at this year's DEF CON was brought to our attention on the SQLx Discord:

> SQL Injection isn't Dead: Smuggling Queries at the Protocol Level
> <http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf>
> (Archive link for posterity.)

Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow,
causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears SQLx _does_ perform truncating casts in a way that could be problematic,
for example: <https://github.com/launchbadge/sqlx/blob/6f2905695b9606b5f51b40ce10af63ac9e696bb8/sqlx-postgres/src/arguments.rs#L163>

This code has existed essentially since the beginning,
so it is reasonable to assume that all published versions `<= 0.8.0` are affected.

## Mitigation

As always, you should make sure your application is validating untrustworthy user input.
Reject any input over 4 GiB, or any input that could _encode_ to a string longer than 4 GiB.
Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

[`Encode::size_hint()`](https://docs.rs/sqlx/latest/sqlx/trait.Encode.html#method.size_hint)
can be used for sanity checks, but do not assume that the size returned is accurate.
For example, the `Json<T>` and `Text<T>` adapters have no reasonable way to predict or estimate the final encoded size,
so they just return `size_of::<T>()` instead.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

## Resolution

`sqlx 0.8.1` has been released with the fix: <https://github.com/launchbadge/sqlx/blob/main/CHANGELOG.md#081---2024-08-23>

Postgres users are advised to upgrade ASAP as a possible exploit has been demonstrated:
<https://github.com/launchbadge/sqlx/issues/3440#issuecomment-2307956901>

MySQL and SQLite do not _appear_ to be exploitable, but upgrading is recommended nonetheless.


Summary: gitoxide-core does not neutralize special characters for terminals

### Summary

The `gix` and `ein` commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

### Details

`gitoxide-core`, which provides most underlying functionality of the `gix` and `ein` commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

### PoC

On a Unix-like system in a POSIX-compatible shell, run:

```sh
git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'
```

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

```sh
gix tree entries
```

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with `EVIL_COMMAND` in another color, and with no other text:

```text
Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.
```

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to `Boo!`, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, `gix tree entries` can be piped to a command that displays special characters symbolically, such as `less` or `cat -v` if available.

```text
BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m
```

That shows the effect on `gix tree entries`, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the `user.name` used to create a commit.

### Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact.

Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different `gix` and `ein` commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where `gix clone` fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems *other* than Windows, in the ability to produce misleading output this superficially resembles [CVE-2024-35197](https://github.com/advisories/GHSA-49jc-r788-3fc9). But this is much more limited, because:

- The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
- The misleading output can only be take place *when* the application is already producing output. This limitation complicates the production of believable messages.
- Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
- Reading and blocking cannot be performed.
- Applications other than the gitoxide `gix` and `ein` executables are unaffected. The exception is if another application uses `gitoxide-core`. But this is explicitly discouraged in the `gitoxide-core` documentation and is believed to be rare.


The following presentation at this year's DEF CON was brought to our attention on the Diesel Gitter Channel:

> SQL Injection isn't Dead: Smuggling Queries at the Protocol Level
> <http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf>
> (Archive link for posterity.)
Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow,
causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears Diesel _does_ perform truncating casts in a way that could be problematic,
for example: <https://github.com/diesel-rs/diesel/blob/ae82c4a5a133db65612b7436356f549bfecda1c7/diesel/src/pg/connection/stmt/mod.rs#L36>

This code has existed essentially since the beginning,
so it is reasonable to assume that all published versions `<= 2.2.2` are affected.

## Mitigation

The prefered migration to the outlined problem is to update to a Diesel version newer than 2.2.2, which includes
fixes for the problem.

As always, you should make sure your application is validating untrustworthy user input.
Reject any input over 4 GiB, or any input that could _encode_ to a string longer than 4 GiB.
Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

## Resolution

Diesel now uses `#[deny]` directives for the following Clippy lints:

* [`cast_possible_truncation`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_truncation)
* [`cast_possible_wrap`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_wrap)
* [`cast_sign_loss`](https://rust-lang.github.io/rust-clippy/master/#/cast_sign_loss)

to prevent casts that will lead to precision loss or other trunctations. Additionally we performed an
audit of the relevant code.

A fix is included in the `2.2.3` release.


Summary: CWA-2023-004: Excessive number of function parameters in compiled Wasm

A specifically crafted Wasm file can cause the VM to consume excessive amounts of memory when compiling a contract.
This can lead to high memory usage, slowdowns, potentially a crash and can poison a lock in the VM,
preventing any further interaction with contracts.

For more information, see [CWA-2023-004](https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2023-004.md).


Summary: gix-path uses local config across repos when it is the highest scope

### Summary

`gix-path` executes `git` to find the path of a configuration file that belongs to the `git` installation itself, but mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. In rare cases, this causes a less trusted repository to be treated as more trusted, or leaks sensitive information from one repository to another, such as sending credentials to another repository's remote.

### Details

In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` and parses the first line of the output to extract the path to the configuration file holding the configuration variable of highest [scope](https://git-scm.com/docs/git-config#SCOPES):

<https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L91>

<https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L112>

While the configuration variable of highest scope is not usually in the local scope, there are practical situations where this occurs:

- A configuration file truly associated with the installation is not present on all systems and can occasionally be empty. Likewise, there may be no variables in the global scope.
- Configuration files associated with those higher scopes may be deliberately skipped by setting the `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` environment variables to `/dev/null` (or to `NUL` on Windows). This prevents `gix-path` from finding the path of configuration files for those scopes, while not preventing downstream components such as the function in `gix-config` from reporting a local path as being associated with the installation.
- The `GIT_CONFIG_NOSYSTEM` environment variable can be used to disable configuration associated with the installation. (`GIT_CONFIG_NOSYSTEM=1` is more powerful than `GIT_CONFIG_SYSTEM=/dev/null` on systems where an additional "unknown" scope is associated with the installation, as occurs on macOS with Apple Git.) This will cause the local scope to be the highest nonempty scope under even more situations, though in practice it is less dangerous because most, though possibly not all, downstream components would disregard the value.

A user may use either or both of the latter two techniques to turn off an undesired configuration or to create a more replicable environment. Such a user would expect that this results in a more controlled configuration.

Often, when located inside one repository, a user performs operations on that repository or that are not specific to any repository. In such use, local configuration is typically desired or at least acceptable, and mistaking it as coming from another scope is not typically harmful.

However, sometimes a user is in one repository and operates on another repository. A major case where this occurs is cloning one repository while located in another. This can be done in an ad-hoc fashion, including when cloning the repository outside of the one we are inside. It may also potentially be automated by an application for purposes such as submodule handling. Two kinds of problems are anticipated:

- A less secure configuration may be set for a specific repository where it is judged acceptable, even though it would not be wanted for other repositories, such as to enable a protocol or set up debugging.
- More likely, a configuration that supplies secrets for use in one repository's remote can be used to send those secrets to another repository's remote.

### PoC

In this example, we send mock `Authorization: Basic ...` credentials meant for one repository's remote to another remote, by running `gix` while inside the first repository to clone the second repository.

These instructions are written for a Unix shell, but they will work in other shells, including in PowerShell on Windows if the method of setting environment variables is adapted and `/dev/null` is replaced with `NUL`. This procedure is likely to demonstrate the problem on all systems *except* macOS. This is due to the high-scoped "unknown" configuration that usually accompanies Apple Git, and reflects that gix-path is in practice much less vulnerable on macOS (though still potentially vulnerable).

1. Install [`dummyhttp`](https://crates.io/crates/dummyhttp) to serve as a local HTTP server for the demonstration.

2. Obtain a build of `gitoxide` with the `max` feature set enabled. While this vulnerability affects other builds, this example requires `max` for `http.extraHeader` support.

   Running `cargo install gitoxide` will install such a build though it may build against a patched version of `gix-path`. Cloning the repository ([`12251eb`](https://github.com/Byron/gitoxide/commit/12251eb052df30105538fa831e641eea557f13d8) and earlier are affected) and building with `cargo build` or `cargo install --path .` are also sufficient. In contrast, installing from published binaries with `binstall` or `quickinstall` does not provide the `max` feature, as of this writing.

3. Run: `dummyhttp -i 127.0.0.1 -c 403 -v`

4. In a separate terminal, create a new local repository and set up a mock remote and `http.extraHeader` configuration:

   ```sh
   git init myrepo
   cd myrepo
   git remote add origin http://127.0.0.1:8080/mygit.git
   git config --local http.extraHeader 'Authorization: Basic abcde'
   ```

5. Make sure the testing setup is working by running `gix fetch` in the repository and checking that it fails in the expected way. In the terminal where that is run, a message should be shown indicating an HTTP 403 error. The more interesting output is in the terminal where `dummyhttp` is running, which should look like this:

   ```text
   2024-30-30 03:30:16 127.0.0.1:55689 GET /myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
   ┌─Incoming request
   │ GET /myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
   │ Accept: */*
   │ Authorization: Basic abcde
   │ Git-Protocol: version=2
   │ Host: 127.0.0.1:8080
   │ User-Agent: git/oxide-0.42.2
   ┌─Outgoing response
   │ HTTP/1.1 403 Forbidden
   │ Content-Length: 9
   │ Content-Type: text/plain; charset=utf-8
   │ Date: Fri, 30 Aug 2024 03:30:16 -0400
   ```

   Some details may differ, especially dates and times. But `Authorization: Basic abcde` should be shown.

6. Now, in the terminal where you ran `gix fetch`, try cloning a separate repository:

   ```sh
   gix clone http://127.0.0.1:8080/other.git
   ```

   Check the output appended in the terminal where `dummyhttp` is running. This is to observe that `Authorization: Basic abcde` was rightly *not* sent.

   Alternatively, if it *does* appear, then your system may be in one of the uncommon configurations that is vulnerable without further action.

7. Now rerun that command, but with a modified environment, to cause `gix-path` to wrongly treat configuration from the local scope as being associated with the `git` installation:

   ```sh
   env GIT_CONFIG_SYSTEM=/dev/null GIT_CONFIG_GLOBAL=/dev/null gix clone http://127.0.0.1:8080/other.git
   ```

   Check the output appended in the terminal where `dummyhttp` is running. Observe that `Authorization: Basic abcde` was wrongly sent.

While this procedure uses the same remote host for both repositories, this is not a required element. If the second repository had a different, untrusted host, the extra header would still be sent.

### Impact

It is believed to be very difficult to exploit this vulnerability deliberately, due to the need either to anticipate a situation in which higher-scoped configuration variables would be absent, or to arrange for this to happen. Although any operating system may be affected, users running Apple Git on macOS are much less likely to be affected.

In the example shown above, more secure general practices would avoid it: using a credential manager, or even using `http.<url>.extraHeader` with as specific a `<url>` as possible, rather than the more general `http.extraHeader`. Many scenarios are analogous: if each repository's configuration is as secure as possible for how the repository is used, and secrets are stored securely and separately, then the circumstances under which an unacceptably unsecure configuration is used, or under which a leak of credentials would occur, become unlikely.


Summary: olm-sys: wrapped library unmaintained, potentially vulnerable

After several cryptographic vulnerabilities in `libolm` were disclosed publicly, the Matrix Foundation has [officially deprecated the library](https://matrix.org/blog/2024/08/libolm-deprecation/). `olm-sys` is a thin wrapper around `libolm` and is now deprecated and potentially vulnerable in kind.

Users of `olm-sys` and its higher-level abstraction, `olm-rs`, are highly encouraged to switch to [`vodozemac`](https://crates.io/crates/vodozemac) as soon as possible. It is the successor effort to `libolm` and is written in Rust.


Summary: phonenumber:  panic on parsing crafted phonenumber inputs

### Impact

The phonenumber parsing code may panic due to a reachable `assert!` guard on the phonenumber string.

In a typical deployment of rust-phonenumber, this may get triggered by feeding a maliciously crafted phonenumber, e.g. over the network, specifically strings of the form `+dwPAA;phone-context=AA`, where the "number" part potentially parses as a number larger than 2^56.

Since f69abee1/0.3.4/#52.

0.2.x series is not affected.

### Patches
Patches have been published as version `0.3.6+8.13.36`.


Summary: proc-macro-error is unmaintained

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](https://crates.io/crates/manyhow)
- [proc-macro-error2](https://crates.io/crates/proc-macro-error2)
- [proc-macro2-diagnostics](https://github.com/SergioBenitez/proc-macro2-diagnostics)


Summary: gix-path improperly resolves configuration path reported by Git

### Summary

`gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution.

### Details

In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation.

Affected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths ([`650a1b5`](https://github.com/Byron/gitoxide/commit/650a1b5cf25e086197cc55a68525a411e1c28031)). Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks:

<https://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142>

The problem is that, when a path is quoted, it may change in substantial ways beyond the concatenation of quotation marks. If not reversed, these changes can result in another valid path that is not equivalent to the original.

This is not limited to paths with unusual characters such as quotation marks or newlines. Unless `git` is explicitly configured with `core.quotePath` set to `false`, it also happens when the path contains most non-ASCII characters, including accented or non-English letters. For example, `é` is transformed to `\303\251`, with literal backslashes. (This is an octal representation of the bytes in its UTF-8 encoding. This behavior is not limited to systems that encode paths with UTF-8 on disk.)

Rarely, the configuration file `gix-path` wrongly attempts to open can be created by an attacker who has a limited user account on the system. The attacker would often need to request an account username tailored to carrying out the attack.

### PoC

#### Quick demonstration on Unix

On a Unix-like system in which Git supports no higher scope than `system` for configuration variables (i.e., not on macOS with Apple Git), in a locale that supports UTF-8, with `gitoxide` installed, run:

```sh
mkdir myrepo
cd myrepo
git init
printf '[real]\n\trealvar = realval\n' > 'é'
printf '[fake]\n\tfakevar = fakeval\n' > '\303\251'
GIT_CONFIG_SYSTEM='é' gix config
```

If the above conditions are satisfied and the `gix` command was built against an affected version of `gix-path`, then the last command's output looks something like this:

```text
# From '\303\251' (GitInstallation)
[fake]
        fakevar = fakeval

# From 'é' (System)
[real]
        realvar = realval

# From '/home/ubuntu/.gitconfig' (User)
[init]
        defaultBranch = main

# From './.git/config' (Local)
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
```

#### Demonstration across user accounts on Windows

On a test system running Windows on which Git for Windows is *not* installed system-wide—resembling a scenario in which users who wish to use Git are expected to install it themselves for their accounts—create two accounts, with these usernames:

- *Renée*, the target of the attack. This user may be a limited user or an administrator. Its user profile directory is assumed to be `C:\Users\Renée`.
- *Ren*, the user who carries out the attack. This user should be a limited user, since an administrator would not need to exploit this vulnerability to inject configuration. Its user profile directory is assumed to be `C:\Users\Ren`.

As *Ren*, run these commands in PowerShell:

```powershell
$d = "$HOME\303\251e\AppData\Local\Programs\Git\etc"
mkdir $d
git config --file $d\gitconfig core.sshCommand calc.exe
icacls $HOME\303 /grant 'Renée:(RX)' /T
```

(The `gitconfig` file can instead be written manually, in which case *Ren* need not have `git`.)

As *Renée*:

1. Install Git for Windows in the default location for non-systemwide installations, which for that user account is inside `C:\Users\Renée\AppData\Local\Programs`. For a non-administrative installation, Git for Windows will pick this location automatically. Allow the installer to place the directory containing `git` in the user's `PATH`, as it does by default.

   (The scenario can be modified for any location the attacker can predict. So, for example, *Renée* can install Git for Windows with [`scoop`](https://scoop.sh/), and *Ren* could carry out the attack with correspondingly modified path components in place of `AppData\Local\Programs\Git`.)

2. Install `gitoxide` using any common technique, such as by [installing Rust](https://www.rust-lang.org/tools/install) and then running `cargo install gitoxide`.

3. Open a PowerShell window and run a `gix` command that attempts to run the SSH client for transport. For example:

   ```pwsh
   gix clone ssh://localhost/myrepo.git
   ```

   At least one, and usually two, instances of the Windows calculator will pop up. This happens because `calc.exe` was configured in the fake configuration file the user *Ren* was able to cause to be used, by placing it at the location `gix-path` wrongly resolved the path of *Renée*'s own configuration file to.

The `gitconfig` file written by the attacker can be adjusted with an arbitrary choice of payload, or to set other configuration variables.

### Impact

On a single-user system, it is not possible to exploit this, unless `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` have been set to unusual values or Git has been installed in an unusual way. Such a scenario is not expected.

Exploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. It is especially unlikely with Apple Git on macOS, due to its very high scoped configuration in `/Library` or `/Applications` that would be detected instead, as in [CVE-2024-45305](https://github.com/advisories/GHSA-v26r-4c9c-h3j6).

The likelihood of exploitation may be higher on Windows, where attacks such as those shown in the Windows proof-of-concept above can be performed due to the status of `\` as a directory separator, and where there is no restriction on usernames containing accented or non-English letters (though the latter is also permitted on some other systems). Even then, complex user interaction is required. In most cases, a system administrator would have to approve an innocuous-seeming username, and then the targeted user (who could be the same or a different user) would have to use an application that uses `gix-path`.

In general, exploitation is more likely to succeed if at least one of the following applies:

- Users are expected to install `git` themselves, and are likely to do so in predictable locations.
- Locations where `git` is installed, whether due to usernames in their paths or otherwise, contain characters that `git` quotes by default in paths, such as non-English letters and accented letters.
- A custom `system`-scope configuration file is specified with the `GIT_CONFIG_SYSTEM` environment variable, and its path is in an unusual location or has strangely named components.
- A `system`-scope configuration file is absent, empty, or suppressed by means other than `GIT_CONFIG_NOSYSTEM`. Currently, `gix-path` can treat a `global`-scope configuration file as belonging to the installation if no higher scope configuration file is available. This increases the likelihood of exploitation even on a system where `git` is installed system-wide in an ordinary way.

However, exploitation is expected to be very difficult even under any combination of those factors.

Although the effect here is similar to [CVE-2022-24765](https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2) once exploited, a greater degree of user interaction would usually be required, and the attack complexity here is much higher because the necessary conditions are uncommon and challenging to predict.


Summary: Memory leak when calling a canister method via `ic_cdk::call`

When a canister method is called via `ic_cdk::call*`, a new Future `CallFuture` is created  and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called `CallFutureState`.  A bug in the polling implementation of the `CallFuture` allows multiple references to be held for this internal state and not all references were dropped before the `Future` is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister's heap and thus causing a memory leak.

### Impact
Canisters built in Rust with `ic_cdk` and `ic_cdk_timers` are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. **In the worst case, this could lead to heap memory exhaustion triggered by an attacker.**

Motoko based canisters are not affected by the bug.

### Patches
The patch has been backported to all minor versions between `>= 0.8.0, <= 0.15.0`. The patched versions available are `0.8.2, 0.9.3, 0.10.1, 0.11.6, 0.12.2, 0.13.5, 0.14.1, 0.15.1` and their previous versions have been yanked.

### Workarounds
There are no known workarounds at the moment. Developers are recommended to upgrade their canister as soon as possible to the latest available patched version of `ic_cdk` to avoid running out of Wasm heap memory.

> Upgrading the canisters (without updating `ic_cdk`) also frees the leaked memory but it's only a temporary solution.

### Referencesas
- [dfinity/cdk-rs/pull/509](https://github.com/dfinity/cdk-rs/pull/509)
- [ic_cdk docs](https://docs.rs/ic-cdk/latest/ic_cdk/)
- [Internet Computer Specification](https://internetcomputer.org/docs/current/references/ic-interface-spec)


Summary: `Endpoint::retry()` calls can lead to panicking

In 0.11.0, we overhauled the server-side `Endpoint` implementation to enable
more careful handling of incoming connection attempts. However, some of the
code paths that cleaned up state after connection attempts were processed
confused the initial destination connection ID with the destination connection
ID of a substantial package. This resulted in the internal `Endpoint` state
becoming inconsistent, which could then lead to a panic.

https://github.com/quinn-rs/quinn/commit/e01609ccd8738bd438d86fa7185a0f85598cb58f

Thanks to [@finbear](https://github.com/finnbear) for reporting and investingating,
and to [@BiagoFesta](https://github.com/BiagoFesta) for coordinating.


Summary: Segmentation fault due to use of uninitialized memory

When trying to decompress a file using "ouch", we can reach the function "ouch::archive::zip::convert_zip_date_time".
In the function, there is a unsafe function, "transmute". Once the "transmute" function is called to convert the type of "month" object,
the address of the object is changed to the uninitialized memory region.
After that, when other function tries to dereference "month", segmentation fault occurs.


Summary: `atty` is unmaintained

The maintainer of `atty` has [published](https://github.com/softprops/atty/commit/5bfdbe9e48c6ca6a4909e8d5b04f5e843a257e93) 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`](https://doc.rust-lang.org/std/io/trait.IsTerminal.html) trait.

## Alternative(s)

- [std::io::IsTerminal](https://doc.rust-lang.org/stable/std/io/trait.IsTerminal.html) - Stable since Rust 1.70.0 and the recommended replacement per the `atty` maintainer.
- [is-terminal](https://crates.io/crates/is-terminal) - Standalone crate supporting Rust older than 1.70.0


Summary: Remotely exploitable Denial of Service in Tonic

## Impact

When using `tonic::transport::Server` there is a remote DoS attack that can cause the server to exit cleanly on accepting a tcp/tls stream. This can be triggered via causing the accept call to error out with errors there were not covered correctly causing the accept loop to exit.

More information can be found [here](https://github.com/hyperium/tonic/issues/1897)

## Patches

Upgrading to tonic `0.12.3` and above contains the fix.

## Workarounds

A custom accept loop is a possible workaround.


Summary: Heap Buffer overflow using c_chars_to_str function

The `heap-buffer-overflow` is triggered in the `strlen()` function when handling the `c_chars_to_str` function in the dbn crate. This vulnerability occurs because the `CStr::from_ptr()` function in Rust assumes that the provided C string is null-terminated. However, there is no guarantee that the input chars array passed to the c_chars_to_str function is properly null-terminated.

If the chars array does not contain a null byte (\0), strlen() will continue to read beyond the bounds of the buffer in search of a null terminator. This results in an out-of-bounds memory read and can lead to a heap-buffer-overflow, potentially causing memory corruption or exposing sensitive information.


Summary: Risk of use-after-free in `borrowed` reads from Python weak references

The family of functions to read "borrowed" values from Python weak references
were fundamentally unsound, because the weak reference does itself not have
ownership of the value. At any point the last strong reference could
be cleared and the borrowed value would become dangling.

In PyO3 0.22.4 these functions have all been deprecated and patched to leak a
strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.


Summary: Multiple soundness issues

`fast-float` contains multiple soundness issues:

 1. [Undefined behavior when checking input length](https://github.com/aldanor/fast-float-rust/issues/28), which has been merged but no package [pubished](https://github.com/aldanor/fast-float-rust/issues/35).
 1. [Many functions marked as safe with non-local safety guarantees](https://github.com/aldanor/fast-float-rust/issues/37)

The library is also unmaintained.

## Alternatives

For quickly parsing floating-point numbers third-party crates are generally no longer needed. A fast float parsing algorithm by the author of `lexical` has been [merged](https://github.com/rust-lang/rust/pull/86761) into libcore. When requiring direct parsing from bytes and/or partial parsers, the [`fast-float2`](https://crates.io/crates/fast-float2) fork of `fast-float` containing these security patches and reduces overall usage of unsafe.


Summary: Replaced by `pqcrypto-mldsa`

This crate has been replaced by `pqcrypto-mldsa`, which provides a
FIPS204-compatible implementation of ML-DSA.


Summary: Replaced by `pqcrypto-mlkem`

This crate has been replaced by `pqcrypto-mlkem`, which provides a
FIPS203-compatible implementation of ML-KEM.


Summary: hwloc is unmaintained

hwloc will no longer be maintained as declared by the developer. The project has been archived without an issue.


Summary: bcc is unmaintained

bcc will no longer be maintained as declared by the developer. Users are recommended to use libbpf-rs instead. See [libbpf-rs](https://github.com/libbpf/libbpf-rs).


Summary: `instant` is unmaintained

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

[`web-time`]: https://crates.io/crates/web-time


Summary: `cw0` is unmaintained

The crate `cw0` was first [renamed to `utils`](https://github.com/CosmWasm/cw-plus/pull/508) in 2021 and [then to `cw-utils`](https://github.com/CosmWasm/cw-plus/pull/598) because `utils` was already claimed on crates.io.

The crate `cw0` is not maintained anymore since then and should be replaced with `cw-utils`.


Summary: strason is unmaintained

strason will no longer be maintained as declared by the developer. The project has been archived.


Summary: `opentelemetry_api` has been merged into the `opentelemetry` crate

Last release was on 2023-07-30.
`opentelemetry_api` has been moved into the [`opentelemetry` crate](https://crates.io/crates/opentelemetry).

Please use the `opentelemetry` crate going forward.


Summary: `derivative` is unmaintained; consider using an alternative

The [`derivative`](https://crates.io/crates/derivative) crate is no longer maintained.
Consider using any alternative, for instance:
- [derive_more](https://crates.io/crates/derive_more)
- [derive-where](https://crates.io/crates/derive-where)
- [educe](https://crates.io/crates/educe)


Summary: `openslide` is unmaintained

The [`openslide`](https://crates.io/crates/openslide) crate is no longer maintained.

Last release was on 2018-11-20.

## Possible alternatives

Consider using an alternative, for instance:

- [openslide-rs](https://crates.io/crates/openslide-rs)
- [pamly](https://crates.io/crates/pamly)


Summary: minitrace is Unmaintained

The minitrace maintainers have decided to continue the development of minitrace under a new organizational structure to improve community governance.

In the meantime, minitrace will no longer be maintained. For more details, refer to [tikv/minitrace-rust#229](https://github.com/tikv/minitrace-rust/issues/229).

## Possible Alternative(s)

[fastrace](https://github.com/fast/fastrace) is maintained by the same team responsible for minitrace, and users are encouraged to migrate to fastrace.


Summary: Ambiguous challenge derivation

Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead
to security vulnerability (however, it's unknown if it could be exploited).


Summary: Ambiguous challenge derivation


Summary: mmap unmaintained

The `mmap` crate is unmaintained as its [repository has been archived](https://github.com/rbranson/rust-mmap) on Feb 10, 2022.
The main alternative seems to be `memmap2` crate.


Summary: The maintainer of chrono-english is unresponsive

All versions will encounter compilation errors with a chrono version `>0.4.35`, due
to backward incompatible API changes.

User conradludgade reworked the original crate and created a fork with the same API
surface called [interim](https://github.com/conradludgate/interim).

The fork is better structured and passes the same test suite as chrono-english,
ensuring backward compatibility.


Summary: `conrod_core` is unmaintained

The `conrod_core` crate is no longer maintained.

The author suggests [`egui`](https://crates.io/crates/egui) as a potential alternative.


Summary: `conrod` is unmaintained

The crate `conrod` has been [deprecated] since version 0.62.0 released in December 2018. The functionality was split across multiple different crates, with the core functionality being transferred to `conrod_core`. An overview can be found in the [conrod repository].

If you have this crate in your dependency tree, this is very likely by mistake and should be corrected.

[deprecated]: https://crates.io/crates/conrod/
[conrod repository]: https://github.com/PistonDevelopers/conrod


Summary: Bias of Polynomial Coefficients in Secret Sharing

Affected versions of this crate allowed for a bias when generating random
polynomials for Shamir Secret Sharing, where instead of being within the range
`[0, 255]` they were instead in the range `[1, 255]`. A description from
Cure53, who originally found the issue, is available:

> The correct method to select a random polynomial would be to select
all coefficients (including the most significant coefficient) uniformly
in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient
in a polynomial cannot be 0 permits the exclusion of single byte values
for the shared secret given one share less than required. [...]
Exploiting this weakness necessitates sharing the same secret multiple
times. In this scenario, an attacker could exclude an exponential number
of values for each of the shared bytes until sufficiently few values
remain for brute forcing.  Cure53 estimates that under ideal
circumstances (e.g., a 2-out-of-N scheme) a shared secret can be
reconstructed if the same secret has been distributed 500-1500 times.

Secrets that have been shared a low amount of times (ideally, once) would not
be impacted. However, secrets that are repeatedly shared may be vulnerable,
especially if the shares are still available, and should be rotated.

The vulnerability does not impact reconstitution of secrets: secrets that have
already been split can be recombined without issue.

The flaw can be corrected by changing the lower bound of the polynomial
coefficient range in the `sharks::math::random_polynomial` function to `0`. The
`blahaj` crate has been made available with a fixed version of the code, after
attempts to reach the maintainer of the `sharks` crate were unsuccessful.


Summary: rustls network-reachable panic in `Acceptor::accept`

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.


Summary: `ruzstd` uninit and out-of-bounds memory reads

Affected versions of `ruzstd` miscalculate the length of the allocated
and init section of its internal `RingBuffer`, leading to uninitialized
or out-of-bounds reads in `copy_bytes_overshooting` of up to 15 bytes.

This may result in up to 15 bytes of memory contents being written
into the decoded data when decompressing a crafted archive.
This may occur multiple times per archive.


Summary: Denial of service because of stack overflow with malicious decompression input

A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.

### Impact

Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.

After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew

```asm
.LBB109_326:
    mov rdi, rbx
    call zlib_rs::inflate::State::type_do
    jmp .LBB109_311

.LBB109_311:
    lea rsp, [rbp - 40]
    pop rbx
    pop r12
    pop r13
    pop r14
    pop r15
    pop rbp
    .cfi_def_cfa rsp, 8
    ret
```

LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.

So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).

### Patches
Version 0.4.0 patches the problem and is no longer vulnerable.

### Workarounds
Users of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.


Summary: Borsh serialization of HashMap is non-canonical

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.


Summary: op_panic in the base runtime can force a panic in the runtime's containing thread

Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core

This function when called triggers a manual panic in the thread containing the runtime, breaking sandboxing

It can be fixed by stubbing out the exposed op:
```javascript
Deno.core.ops.op_panic = (msg) => { throw new Error(msg) };
```


Summary: Unsoundness in anstream

When given a valid UTF8 string "ö\x1b😀", the function in
crates/anstream/src/adapter/strip.rs will be confused. The UTF8
bytes are \xc3\xb6 then \x1b then \xf0\x9f\x98\x80.

When looping over "non-printable bytes" \x1b\xf0 will be
considered as some non-printable sequence.

This will produce a broken str from the incorrectly segmented
bytes via str::from_utf8_unchecked, and that should never happen.

Full credit goes to @Ralith who reviewed this code and
asked @burakemir to follow up.


Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core

This function when called triggers a manual panic in the thread containing the runtime.

It can be fixed by stubbing out the exposed op:
```javascript
Deno.core.ops.op_panic = (msg) => { throw new Error(msg) };
```


Summary: BTreeMap memory leak when deallocating nodes with overflows

When storing unbounded types in a `BTreeMap`, a node is represented as a linked list of "memory chunks". In some cases, when we deallocate a node only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak.

In the worst case, depending on how a canister uses the `BTreeMap`, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.

This issue has been fixed in [dfinity/stable-structures/pull/212](https://github.com/dfinity/stable-structures/pull/212) by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated. Tests have been added to prevent regressions of this nature moving forward.

**Note:** Users of stable-structure < 0.6.0 are not affected.

### Workarounds
Users who are not storing unbounded types in `BTreeMap` are not affected and do not need to upgrade. Otherwise, an upgrade to version `0.6.4` is necessary.

### References
-  [GitHub Security Advisory (GHSA-3rcq-39xp-7xjp)](https://github.com/dfinity/stable-structures/security/advisories/GHSA-3rcq-39xp-7xjp)
-  [dfinity/stable-structures/pull/212](https://github.com/dfinity/stable-structures/pull/212)
-  [Stable Structures Documentation](https://docs.rs/ic-stable-structures/0.6.4/ic_stable_structures/)
-  [Stable Memory on the Internet Computer](https://internetcomputer.org/docs/current/developer-docs/smart-contracts/maintain/storage#stable-memory)


Summary: Fails to ensure slice elements match the slice's declared type

Affected versions allow populating a DistributedSlice of T with elements of an
arbitrary other type that coerces to T. For example, elements of type `&&str`
could end up in a slice of type `[&str]`, since `&&str` coerces to `&str` via a
deref coercion.

The flaw was corrected by implementing typechecking for distributed slice
elements in such a way that coercion no longer occurs. The element's type must
be a subtype of the slice's declared element type.


Summary: Unsound usages of `std::slice::from_raw_parts`

The library breaks the safety assumptions when using unsafe API `std::slice::from_raw_parts`. First, when using the API in iterator implementation (`TempFdArrayIterator.next`), generic type could be any type, which would create and pass a misaligned pointer to the unsafe API. Second, when validating the address, the code passed the type `c_void`, which could also be any type, leading to potential uninitialized memory exposure.

Two unsound usages here highlight the necessity for developers to perform type checks before doing type conversion with unsafe API.

The panic caused by the misalignment causes several downstream applications (e.g., `greptimedb`) to crash when using `pprof::report::ReportBuilder::build`.

This was patched in 0.14.0.

The developer also suggested moving to [pprof2](https://crates.io/crates/pprof2).


Summary: Build corruption when using `PYO3_CONFIG_FILE` environment variable

In PyO3 0.23.0 the `PYO3_CONFIG_FILE` environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as `maturin` to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version.

All users who distribute artefacts for multiple Python versions are encouraged to update and rebuild with PyO3 0.23.3. Affected wheels produced from PyO3 0.23.0 through 0.23.2 are highly unstable and will crash the Python interpreter in unpredictable ways.


Summary: gtk-rs GTK3 bindings - no longer maintained

The gtk-rs GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-rs](https://github.com/gtk-rs/gtk4-rs) instead.
```


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

`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`](https://docs.rs/crate/idna_adapter/latest).

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) 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](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).

## Acknowledgements

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


Summary: gtk-layer-shell GTK3 bindings - no longer maintained

The gtk-layer-shell GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-layer-shell](https://github.com/pentamassiv/gtk4-layer-shell-gir) instead.
```


Summary: gtk-layer-shell-sys GTK3 bindings - no longer maintained

The gtk-layer-shell-sys GTK3 bindings are no longer maintained.

The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.

Please take a look at [gtk4-layer-shell](https://github.com/pentamassiv/gtk4-layer-shell-gir) instead.
```


Summary: Unsound usages of `core::slice::from_raw_parts_mut`

The library breaks the safety assumptions when using unsafe API `slice::from_raw_parts_mut`. The pointer passed to `from_raw_parts_mut` is misaligned by casting `u8` to `u16` raw pointer directly, which is unsound. The bug is patched by using `align_offset`, which could make sure the memory address is aligned to 2 bytes for `u16`.

This was patched in 0.11.2 in the [commit](https://github.com/AFLplusplus/LibAFL/pull/1530/commits/5a60cb31ef587d71d09d534bba39bd3973c4b35d).


Summary: get-size is unmaintained

get-size's maintainer seems to be unreachable, with no commits and releases pushed for 1 year and no activity on the GitHub repo.

get-size also depends on `get-size-derive 0.1.3`, which uses `attribute-derive ^0.6` a version of the crate which uses the yanked crate `proc-macro-error`.

## Possible Alternative(s)

- [get-size2](https://crates.io/crates/get-size2)
- [typesize](https://crates.io/crates/typesize)


Summary: Unsound usages of `u8` type casting

The library provides a safe public API `unpack` to cast `u8` array to arbitrary types, which can cause to undefined behaviors. The length check of array can only prevent out-of-bound access on the return type. However, it can't prevent misaligned pointer when casting `u8` pointer to a type aligned to larger bytes. For example, if we assign `u16` to `T`, **misaligned raw pointer dereference** could happen and cause to panic. Even if we pass the type aligned to same byte as `u8` (e.g., `bool`), it could construct a illegal type since `bool` can only have 0 or 1 as bit patterns, which is also an undefined behavior. The further exploits of the bug here are still not clear, so we would report this issue as unsound.

The details of PoC to reproduce undefined behavior are provided in the [issue](https://github.com/solana-labs/solana-program-library/issues/5243).


Summary: get-size-derive is unmaintained

get-size-derive's maintainer seems to be unreachable, with no commits and releases pushed for 1 year and no activity on the GitHub repo.

get-size-derive also depends on `attribute-derive ^0.6` a version of the crate which uses the yanked crate `proc-macro-error`.

## Possible Alternative(s)

- [get-size-derive2](https://crates.io/crates/get-size-derive2)


Summary: Undefined behaviour in `kvm_ioctls::ioctls::vm::VmFd::create_device`

An issue was identified in the `VmFd::create_device function`, leading to undefined behavior and miscompilations on rustc 1.82.0 and newer due to the function's violation of Rust's pointer safety rules.

The function downcasted a mutable reference to its `struct kvm_create_device` argument to an immutable pointer, and then proceeded to pass this pointer to a mutating system call. Rustc 1.82.0 and newer elides subsequent reads of this structure's fields, meaning code will not see the value written by the kernel into the `fd` member. Instead, the code will observe the value that this field was initialized to prior to calling `VmFd::create_device` (usually, 0).

The issue started in kvm-ioctls 0.1.0 and was fixed in 0.19.1 by correctly using
a mutable pointer.


Summary: Unsoundness in `Iterator` and `DoubleEndedIterator` impls for `glib::VariantStrIter`

The `VariantStrIter::impl_get` function (called internally by implementations of the `Iterator` and `DoubleEndedIterator` traits for this type) was unsound, resulting in undefined behaviour.

An immutable reference `&p` to a `*mut libc::c_char` pointer initialized to `NULL` was passed as an argument to a C function that that mutates the pointer behind `&p` in-place (i.e. as an out-argument), which was unsound. After changes in recent versions of the Rust compiler, these unsound writes through `&p` now seem to be completely disregarded when building the `glib` crate with optimizations.

This subsequently caused all calls of `VariantStrIter::impl_get` to violate the safety requirements of the `std::ffi::CStr::from_ptr` function - which requires its argument to be a valid pointer to a C-style string - resulting in crashes due to `NULL` pointer dereferences.

This was fixed by passing the out-argument pointer explitly as `&mut p` instead of `&p`.

This issue has been present since this code was initially added in `glib` v0.15.0. The mismatch in mutability was likely missed (and not raised as an error by the compiler) because the C function wrapped by `VariantStrIter::impl_get` is variadic (`glib_sys::g_variant_get_child`), and the pointer in question is one of the variadic arguments.


Summary: Use of insecure cryptographic algorithms

This crate uses a number of cryptographic algorithms that are no longer
considered secure and it uses them in ways that do not guarantee the integrity
of the encrypted data.

`MagicCrypt64` uses the insecure DES block cipher in CBC mode without
authentication. This allows for practical brute force and padding oracle
attacks and does not protect the integrity of the encrypted data. Key and IV
are generated from user input using CRC64, which is not at all a key derivation
function.

`MagicCrypt64`, `MagicCrypt128`, `MagicCrypt192`, and `MagicCrypt256` are all
vulnerable to padding-oracle attacks. None of them protect the integrity of the
ciphertext. Furthermore, none use password-based key derivation functions, even
though the key is intended to be generated from a password.

Each of the implementations are unsound in that they use uninitialized memory
without `MaybeUninit` or equivalent structures.

For more information, visit the [issue](https://github.com/magiclen/rust-magiccrypt/issues/17).


Summary: Unsound usages of `core::slice::from_raw_parts`

We consider `as_slice` and `as_slice_mut` unsound because: the pointer with any bit patterns could be cast to the slice of arbitrary types. The pointer could be created by unsafe new and deprecated `from_parts`. We consider that `from_parts` should be removed in latest version because it will help trigger unsoundness in `as_slice`. With new declared as unsafe, `as_slice` should also declared as unsafe.

This was patched in by marking two functions as `unsafe`.


Summary: Malicious plugin names, recipients, or identities can cause arbitrary binary execution

A plugin name containing a path separator may allow an attacker to execute an arbitrary
binary.

Such a plugin name can be provided to the `rage` CLI through an attacker-controlled
recipient or identity string, or an attacker-controlled plugin name via the `-j` flag.

On UNIX systems, a directory matching `age-plugin-*` needs to exist in the working
directory for the attack to succeed.

The binary is executed with a single flag, either `--age-plugin=recipient-v1` or
`--age-plugin=identity-v1`. The standard input includes the recipient or identity string,
and the random file key (if encrypting) or the header of the file (if decrypting). The
format is constrained by the [age-plugin](https://c2sp.org/age-plugin) protocol.

An equivalent issue was fixed in [the reference Go implementation of age](https://github.com/FiloSottile/age),
see advisory [GHSA-32gq-x56h-299c](https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c).

Thanks to ⬡-49016 for reporting this issue.


A plugin name containing a path separator may allow an attacker to execute an arbitrary
binary.

Such a plugin name can be provided through an attacker-controlled input to the following
`age` APIs when the `plugin` feature flag is enabled:
- [`age::plugin::Identity::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#impl-FromStr-for-Identity)
  (or equivalently [`str::parse::<age::plugin::Identity>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::Identity::default_for_plugin`](https://docs.rs/age/0.11.0/age/plugin/struct.Identity.html#method.default_for_plugin)
- [`age::plugin::IdentityPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.IdentityPluginV1.html#method.new)
  (the `plugin_name` argument)
- [`age::plugin::Recipient::from_str`](https://docs.rs/age/0.11.0/age/plugin/struct.Recipient.html#impl-FromStr-for-Recipient)
  (or equivalently [`str::parse::<age::plugin::Recipient>()`](https://doc.rust-lang.org/stable/core/primitive.str.html#method.parse))
- [`age::plugin::RecipientPluginV1::new`](https://docs.rs/age/0.11.0/age/plugin/struct.RecipientPluginV1.html#method.new)
  (the `plugin_name` argument)

On UNIX systems, a directory matching `age-plugin-*` needs to exist in the working
directory for the attack to succeed.

The binary is executed with a single flag, either `--age-plugin=recipient-v1` or
`--age-plugin=identity-v1`. The standard input includes the recipient or identity string,
and the random file key (if encrypting) or the header of the file (if decrypting). The
format is constrained by the [age-plugin](https://c2sp.org/age-plugin) protocol.

An equivalent issue was fixed in [the reference Go implementation of age](https://github.com/FiloSottile/age),
see advisory [GHSA-32gq-x56h-299c](https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c).

Thanks to ⬡-49016 for reporting this issue.


Summary: Missing facility to signal rotation of a verified cryptographic identity

Versions of the matrix-sdk-crypto Rust crate before 0.8.0 lack a dedicated
mechanism to notify that a user's cryptographic identity has changed from a
verified to an unverified one, which could cause client applications relying on
the SDK to overlook such changes.

matrix-sdk-crypto 0.8.0 adds a new `VerificationLevel::VerificationViolation`
enum variant which indicates that a previously verified identity has been
changed.


Summary: Unsound usages of `Vec::from_raw_parts`

The library provides a public safe API `transmute_vec_as_bytes`, which incorrectly assumes that any generic type `T` could have stable layout, causing to uninitialized memory exposure if the users pass any types with padding bytes as `T` and cast it to `u8` pointer.

In the [issue](https://github.com/FyroxEngine/Fyrox/issues/630), we develop a PoC to show passing struct type to `transmute_vec_as_bytes` could lead to undefined behavior with `Vec::from_raw_parts`.

The developers provide a patch by changing trait of `Copy` to `Pod`, which can make sure `T` should be plain data. This was patched in the latest version of [master](https://github.com/FyroxEngine/Fyrox/blob/3f9ad6f9667047dac051b0e97d544e5b38e5ae72/fyrox-core/src/lib.rs#L351-L360) branch, but still not on the latest release (0.28.1).


Summary: paste - no longer maintained

The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md)
that this project is not longer maintained as well as archived the repository

## Possible Alternative(s)

- [`pastey`]: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
- [`with_builtin_macros`]: crate providing a [superset of `paste`'s functionality including general `macro_rules!` eager expansions](https://docs.rs/with_builtin_macros/0.1.0/with_builtin_macros/macro.with_eager_expansions.html)  and `concat!`/`concat_idents!` macros

[`pastey`]: https://crates.io/crates/pastey
[`with_builtin_macros`]: https://crates.io/crates/with_builtin_macros


Summary: Crash due to uncontrolled recursion in protobuf crate

Affected version of this crate did not properly parse unknown fields when parsing a user-supplied input.

This allows an attacker to cause a stack overflow when parsing the mssage on untrusted data.


Summary: Wasmtime doesn't fully sandbox all the Windows device filenames

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c2f5-jxjv-2hh8.
For more information see the GitHub-hosted security advisory.


Summary: Race condition could lead to WebAssembly control-flow integrity and type safety violations

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m.
For more information see the GitHub-hosted security advisory.


Summary: Runtime crash when combining tail calls with stack traces

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg.
For more information see the GitHub-hosted security advisory.


Summary: Panic when using a dropped extenref-typed element segment

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-75hq-h6g9-h4q5.
For more information see the GitHub-hosted security advisory.


Summary: Dump Undefined Memory by `JitDumpFile`

The unsound function `dump_code_load_record` uses `from_raw_parts` to directly convert
the pointer `addr` and `len` into a slice without any validation and that memory block
would be dumped.

Thus, the 'safe' function dump_code_load_record is actually 'unsafe' since it requires
the caller to guarantee that the addr is valid and len must not overflow.
Otherwise, the function could dump the memory into file illegally, causing memory leak.

> **Note**: this is an internal-only crate in the Wasmtime project not intended for
external use and is more strongly signaled nowadays as of
[bytecodealliance/wasmtime#10963](https://github.com/bytecodealliance/wasmtime/pull/10963).
Please open an issue in Wasmtime if you're using this crate directly.


Summary: webp crate may expose memory contents when encoding an image

Affected versions of this crate did not check that the input slice passed to `"webp::Encoder::encode()` is large enough for the specified image dimensions.

If the input slice is too short, the library will read out of bounds of the buffer and encode other memory contents as an image, resulting in memory exposure or a segmentation fault.

The flaw was corrected in [pull request #44](https://github.com/jaredforth/webp/pull/44) by always validating the input buffer size when constructing the encoder.


Summary: Uncaught exception when transitioning the state of `AsyncGenerator` objects from within a property getter of `then`

A wrong assumption made when handling ECMAScript's AsyncGenerator operations
can cause an uncaught exception on certain scripts.

## Details

Boa's implementation of AsyncGenerator makes the assumption that the state of
an AsyncGenerator object cannot change while resolving a promise created by
methods of AsyncGenerator such as %AsyncGeneratorPrototype%.next,
%AsyncGeneratorPrototype%.return, or %AsyncGeneratorPrototype%.throw.

However, a carefully constructed code could trigger a state transition from
a getter method for the promise's then property, which causes the engine to
fail an assertion of this assumption, causing an uncaught exception. This
could be used to create a Denial Of Service attack in applications that
run arbitrary ECMAScript code provided by an external user.

## Patches

Version 0.19.0 is patched to correctly handle this case.

## Workarounds

Users unable to upgrade to the patched version would want to use
std::panic::catch_unwind to ensure any exceptions caused by the
engine don't impact the availability of the main application.


Summary: cap-primitives doesn't fully sandbox all the Windows device filenames

## Impact

cap-primitives's filesystem sandbox implementation on Windows blocks
access to special device filenames such as "COM1", "COM2",
"LPT0", "LPT1", and so on, however it did not block access
to the special device filenames which use superscript digits,
such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted
filesystem paths could bypass the sandbox and access devices
through those special device filenames with superscript
digits, and through them provide access peripheral devices
connected to the computer, or network resources mapped to
those devices. This can include modems, printers, network
printers, and any other device connected to a serial or
parallel port, including emulated USB serial ports.

## Patches

The bug is fixed in #371, which is published in
cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1.

## Workarounds

There are no known workarounds for this issue.
Affected Windows users are recommended to upgrade.


Summary: Shell expansion in custom commands

## Summary

Undocumented and unpredictable shell expansion and/or quoting
rules make it easily to accidentally cause shell injection
when using custom commands with starship in bash.

## Details

I wanted to show the git commit name in my prompt (I use bash), so I added a command:

```
[custom.git_commit_name]
command = 'git show -s --format="%<(25,mtrunc)%s"'
style = "italic"
when = true
```

To my surprise, when I had a commit with backticks in it,
the backticks were expanded. e.g.:

```
touch foo
git add foo
git commit -m '`ls`'
```

Thankfully I noticed it on my own commit before checking out
someone's code whose commit message was

`rm -rf /important/stuff`

The documentation says:

Command output is printed unescaped to the prompt

```
    Whatever output the command generates is printed unmodified in the prompt.
    This means if the output contains special sequences that are interpreted
    by your shell they will be expanded when displayed. These special
    sequences are shell specific, e.g. you can write a command module that
    writes bash sequences, e.g. \h, but this module will not work in a fish
    or zsh shell.

    Format strings can also contain shell specific prompt sequences, e.g. Bash, Zsh.
```

However, it doesn't specifically mention shell injection with $()
and backticks; it just mentions the prompt escape sequences, and
the link doesn't suggest any shell injection possibilities either.

Furthermore, I can't even figure out how to properly escape things,
because simply changing the command to

```
command = 'printf %q "$(git show -s --format="%<(25,mtrunc)%s")"'
```

doesn't work, as it's also adding a backslash before spaces. I also
tried `use_stdin=false`

I'm not 100% sure this qualifies as a vulnerability, but I feel it is not
documented well enough to warn unsuspecting users, and it certainly is
not documented how to properly quote things, because after 15-30 minutes
of trying, I can't figure it out.

I see some past commits about fixing shell injection with $, and it does
seem like the problem doesn't exist in build-in modules like git branch.

## PoC

Have some custom command which prints out information from a potentially untrusted/unverified source.

```
[custom.git_commit_name]
command = 'git show -s --format="%<(25,mtrunc)%s"'
style = "italic"
when = true
```

## Impact

People with custom commands, so the scope is limited, and without knowledge
of people's commands, it could be hard to target people. The only one I saw
in the example custom commands that may be vulnerable is the playerctl one.


Summary: Panics on Malformed Untrusted Input

During a security audit, Radically Open Security discovered
several reachable edge cases which allow an attacker to
trigger rpgp crashes by providing crafted data.

## Impact

When processing malformed input, rpgp can run into Rust panics which halt
the program.

This can happen in the following scenarios:

 * Parsing OpenPGP messages from binary or armor format
 * Decrypting OpenPGP messages via decrypt_with_password()
 * Parsing or converting public keys
 * Parsing signed cleartext messages from armor format
 * Using malformed private keys to sign or encrypt

Given the affected components, we consider most attack vectors to be
reachable by remote attackers during typical use cases of the rpgp
library. The attack complexity is low since the malformed messages
are generic, short, and require no victim-specific knowledge.

The result is a denial-of-service impact via program termination.
There is no impact to confidentiality or integrity security properties.

## Versions and Patches

All recent versions are affected by at least some of the above mentioned
issues.

The vulnerabilities have been fixed with version 0.14.1. We recommend
all users to upgrade to this version.

## References

The security audit was made possible by the NLnet Foundation
NGI Zero Core grant program for rpgp.


Summary: matrix-sdk-base: Panic in the `RoomMember::normalized_power_level()` method

In matrix-sdk-base before 0.14.1, calling the
`RoomMember::normalized_power_level()` method can cause a panic if a room member
has a power level of `Int::Min`.