Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package cargo-audit-advisory-db for openSUSE:Factory checked in at 2024-07-30 11:55:16 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/cargo-audit-advisory-db (Old) and /work/SRC/openSUSE:Factory/.cargo-audit-advisory-db.new.1882 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "cargo-audit-advisory-db" Tue Jul 30 11:55:16 2024 rev:41 rq:1190363 version:20240730 Changes: -------- --- /work/SRC/openSUSE:Factory/cargo-audit-advisory-db/cargo-audit-advisory-db.changes 2024-05-29 19:36:52.626715764 +0200 +++ /work/SRC/openSUSE:Factory/.cargo-audit-advisory-db.new.1882/cargo-audit-advisory-db.changes 2024-07-30 11:57:32.936999013 +0200 @@ -1,0 +2,15 @@ +Tue Jul 30 02:41:17 UTC 2024 - william.br...@suse.com + +- Update to version 20240730: + * Assigned RUSTSEC-2024-0360 to xmp_toolkit (#2030) + * Unsoundness notice for xmp_toolkit < 1.9.0 (#2029) + * Assigned RUSTSEC-2024-0359 to gix-attributes (#2028) + * Unsoundness notice for gix-attributes (kstring integration) (#2027) + * Assigned RUSTSEC-2024-0358 to object_store (#2026) + * Add advisory for object_store credentials leak via logs (#2025) + * Assigned RUSTSEC-2024-0357 to openssl (#2022) + * Added advisory for undefined behavior in openssl (#2021) + * Assigned RUSTSEC-2024-0356 to matrix-sdk-crypto (#2019) + * Add CVE-2024-40648 for matrix-sdk-crypto (#2018) + +------------------------------------------------------------------- Old: ---- advisory-db-20240528.tar.xz New: ---- advisory-db-20240730.tar.xz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ cargo-audit-advisory-db.spec ++++++ --- /var/tmp/diff_new_pack.9sNEcD/_old 2024-07-30 11:57:33.605026031 +0200 +++ /var/tmp/diff_new_pack.9sNEcD/_new 2024-07-30 11:57:33.605026031 +0200 @@ -17,7 +17,7 @@ Name: cargo-audit-advisory-db -Version: 20240528 +Version: 20240730 Release: 0 Summary: A database of known security issues for Rust depedencies License: CC0-1.0 ++++++ _service ++++++ --- /var/tmp/diff_new_pack.9sNEcD/_old 2024-07-30 11:57:33.637027326 +0200 +++ /var/tmp/diff_new_pack.9sNEcD/_new 2024-07-30 11:57:33.641027487 +0200 @@ -2,7 +2,7 @@ <service mode="disabled" name="obs_scm"> <param name="url">https://github.com/RustSec/advisory-db.git</param> <param name="scm">git</param> - <param name="version">20240528</param> + <param name="version">20240730</param> <param name="revision">main</param> <param name="changesgenerate">enable</param> <param name="changesauthor">william.br...@suse.com</param> ++++++ advisory-db-20240528.tar.xz -> advisory-db-20240730.tar.xz ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/.duplicate-id-guard new/advisory-db-20240730/.duplicate-id-guard --- old/advisory-db-20240528/.duplicate-id-guard 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/.duplicate-id-guard 2024-07-26 20:09:25.000000000 +0200 @@ -1,3 +1,3 @@ This file causes merge conflicts if two ID assignment jobs run concurrently. This prevents duplicate ID assignment due to a race between those jobs. -033b059b6cbbf2107fc1270372f4f929601a920f3927c9d46b3f1f937901c634 - +f52db948a1d9ab0f9f40dfdb4192e6e0762ffdbcf4c28552b8002cde58d02c6e - diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/CONTRIBUTING.md new/advisory-db-20240730/CONTRIBUTING.md --- old/advisory-db-20240528/CONTRIBUTING.md 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/CONTRIBUTING.md 2024-07-26 20:09:25.000000000 +0200 @@ -69,6 +69,19 @@ have been lifted and details have been disclosed to the public prior to filing them against RustSec. +**Q: Is this where I report a vulnerability in `rustc`?** + +A: No, for official Rust projects, please see the [Rust Security Policy](https://www.rust-lang.org/policies/security) and follow the guidelines there. + +**Q: Is this where I report intentionally malicious code or malware present on crates.io?** + +A: No, please see the [Crates.io Security Policy](https://crates.io/policies/security) to get content violating crates.io's policies taken down. + +**Q: I'm a crate author and someone reported a vulnerability in my crate to me. Can you help me?** + +A: The Rust Foundation has resources that can help handle Rust ecosystem security issues. +Please see the [Ecosystem security help for crate authors](https://crates.io/policies/security#ecosystem-security-help) section of the crates.io security policy. + [Pull Request]: https://github.com/RustSec/advisory-db/pulls [TOML advisory template]: https://github.com/RustSec/advisory-db#advisory-format [Yank]: https://doc.rust-lang.org/cargo/commands/cargo-yank.html diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/HOWTO_UNMAINTAINED.md new/advisory-db-20240730/HOWTO_UNMAINTAINED.md --- old/advisory-db-20240528/HOWTO_UNMAINTAINED.md 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/HOWTO_UNMAINTAINED.md 2024-07-26 20:09:25.000000000 +0200 @@ -8,7 +8,7 @@ switching to maintained alternatives. When approaching a potentially unmaintained crate, do not behave rudely -towards open soruce maintainers. Submitting a RUSTSEC advisory for an +towards open source maintainers. Submitting a RUSTSEC advisory for an unmaintained crate should not be treated as a weapon to coerce open source maintainers. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/README.md new/advisory-db-20240730/README.md --- old/advisory-db-20240528/README.md 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/README.md 2024-07-26 20:09:25.000000000 +0200 @@ -96,7 +96,7 @@ # Optional: the advisory license as an SPDX identifier. The default is "CC0-1.0". # Accepted values are "CC0-1.0" and "CC-BY-4.0". -# When using "CC-BY-4.0", the `url` field must constain the link to the source +# When using "CC-BY-4.0", the `url` field must contain the link to the source # advisory. This should only be used for advisories imported for the GitHub # Advisory database ("GHSA"). #license = "CC-BY-4.0" diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/curve25519-dalek/RUSTSEC-2024-0344.md new/advisory-db-20240730/crates/curve25519-dalek/RUSTSEC-2024-0344.md --- old/advisory-db-20240528/crates/curve25519-dalek/RUSTSEC-2024-0344.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/curve25519-dalek/RUSTSEC-2024-0344.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,42 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0344" +package = "curve25519-dalek" +date = "2024-06-18" +categories = ["crypto-failure"] +url = "https://github.com/dalek-cryptography/curve25519-dalek/pull/659" + +[versions] +patched = [">= 4.1.3"] +``` + +# Timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub` + +Timing variability of any kind is problematic when working with potentially secret values such as +elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a +problem was recently discovered in `curve25519-dalek`. + +The `Scalar29::sub` (32-bit) and `Scalar52::sub` (64-bit) functions contained usage of a mask value +inside a loop where LLVM saw an opportunity to insert a branch instruction (`jns` on x86) to +conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt: + +- 32-bit (see L106): <https://godbolt.org/z/zvaWxzvqv> +- 64-bit (see L48): <https://godbolt.org/z/PczYj7Pda> + +A similar problem was recently discovered in the Kyber reference implementation: + +<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ> + +As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a +volatile read as an optimization barrier, which prevents the compiler from optimizing it away. + +The fix can be validated in godbolt here: + +- 32-bit: <https://godbolt.org/z/jc9j7eb8E> +- 64-bit: <https://godbolt.org/z/x8d46Yfah> + +The problem was discovered and the solution independently verified by +Alexander Wagner <alexander.wag...@aisec.fraunhofer.de> and Lea Themint <lea.thi...@tum.de> using +their DATA tool: + +<https://github.com/Fraunhofer-AISEC/DATA> diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-attributes/RUSTSEC-2024-0359.md new/advisory-db-20240730/crates/gix-attributes/RUSTSEC-2024-0359.md --- old/advisory-db-20240528/crates/gix-attributes/RUSTSEC-2024-0359.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-attributes/RUSTSEC-2024-0359.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,23 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0359" +package = "gix-attributes" +date = "2024-07-24" +url = "https://github.com/Byron/gitoxide/issues/1460" +informational = "unsound" + +[versions] +patched = [">= 0.22.3"] +``` + +# 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`. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-fs/RUSTSEC-2024-0350.md new/advisory-db-20240730/crates/gix-fs/RUSTSEC-2024-0350.md --- old/advisory-db-20240528/crates/gix-fs/RUSTSEC-2024-0350.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-fs/RUSTSEC-2024-0350.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,87 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0350" +package = "gix-fs" +date = "2024-05-22" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-7w47-3wg8-547c" +references = [ + "https://github.com/advisories/GHSA-7w47-3wg8-547c", + "https://nvd.nist.gov/vuln/detail/CVE-2024-35186", +] +categories = ["code-execution"] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H" +keywords = ["directory-traversal"] +aliases = ["CVE-2024-35186", "GHSA-7w47-3wg8-547c"] +license = "CC0-1.0" + +[versions] +patched = [">= 0.11.0"] +``` + +# 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-index/RUSTSEC-2024-0348.md new/advisory-db-20240730/crates/gix-index/RUSTSEC-2024-0348.md --- old/advisory-db-20240528/crates/gix-index/RUSTSEC-2024-0348.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-index/RUSTSEC-2024-0348.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,87 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0348" +package = "gix-index" +date = "2024-05-22" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-7w47-3wg8-547c" +references = [ + "https://github.com/advisories/GHSA-7w47-3wg8-547c", + "https://nvd.nist.gov/vuln/detail/CVE-2024-35186", +] +categories = ["code-execution"] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H" +keywords = ["directory-traversal"] +aliases = ["CVE-2024-35186", "GHSA-7w47-3wg8-547c"] +license = "CC0-1.0" + +[versions] +patched = [">= 0.33.0"] +``` + +# 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-index/RUSTSEC-2024-0352.md new/advisory-db-20240730/crates/gix-index/RUSTSEC-2024-0352.md --- old/advisory-db-20240528/crates/gix-index/RUSTSEC-2024-0352.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-index/RUSTSEC-2024-0352.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,91 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0352" +package = "gix-index" +date = "2024-05-22" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-49jc-r788-3fc9" +references = [ + "https://github.com/advisories/GHSA-49jc-r788-3fc9", + "https://nvd.nist.gov/vuln/detail/CVE-2024-35197", +] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L" +aliases = ["CVE-2024-35197", "GHSA-49jc-r788-3fc9"] +license = "CC0-1.0" + +[affected] +os = ["windows"] + +[versions] +patched = [">= 0.33.0"] +``` + +# 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 <kbd>Ctrl</kbd>+<kbd>C</kbd>. + +However, if desired, input can be provided. Ending input with <kbd>Ctrl</kbd>+<kbd>Z</kbd> followed by <kbd>Enter</kbd> 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-path/RUSTSEC-2024-0355.md new/advisory-db-20240730/crates/gix-path/RUSTSEC-2024-0355.md --- old/advisory-db-20240528/crates/gix-path/RUSTSEC-2024-0355.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-path/RUSTSEC-2024-0355.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,73 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0355" +package = "gix-path" +date = "2024-07-18" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-mgvv-9p9g-3jv4" +references = ["https://github.com/advisories/GHSA-mgvv-9p9g-3jv4"] +categories = ["code-execution", "privilege-escalation"] +cvss = "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L" +keywords = ["search-path"] +aliases = ["CVE-2024-40644", "GHSA-mgvv-9p9g-3jv4"] +license = "CC0-1.0" + +[affected] +os = ["windows"] + +[affected.functions] +"gix_path::env::exe_invocation" = ["*"] +"gix_path::env::installation_config" = ["*"] +"gix_path::env::installation_config_prefix" = ["*"] +"gix_path::env::system_prefix" = ["*"] + +[versions] +patched = [">= 0.10.9"] +unaffected = ["< 0.10.8"] +``` + +# 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-ref/RUSTSEC-2024-0351.md new/advisory-db-20240730/crates/gix-ref/RUSTSEC-2024-0351.md --- old/advisory-db-20240528/crates/gix-ref/RUSTSEC-2024-0351.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-ref/RUSTSEC-2024-0351.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,91 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0351" +package = "gix-ref" +date = "2024-05-22" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-49jc-r788-3fc9" +references = [ + "https://github.com/advisories/GHSA-49jc-r788-3fc9", + "https://nvd.nist.gov/vuln/detail/CVE-2024-35197", +] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L" +aliases = ["CVE-2024-35197", "GHSA-49jc-r788-3fc9"] +license = "CC0-1.0" + +[affected] +os = ["windows"] + +[versions] +patched = [">= 0.44.0"] +``` + +# 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 <kbd>Ctrl</kbd>+<kbd>C</kbd>. + +However, if desired, input can be provided. Ending input with <kbd>Ctrl</kbd>+<kbd>Z</kbd> followed by <kbd>Enter</kbd> 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-transport/RUSTSEC-2024-0335.md new/advisory-db-20240730/crates/gix-transport/RUSTSEC-2024-0335.md --- old/advisory-db-20240528/crates/gix-transport/RUSTSEC-2024-0335.md 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/crates/gix-transport/RUSTSEC-2024-0335.md 2024-07-26 20:09:25.000000000 +0200 @@ -29,7 +29,7 @@ - The difficulty of forming an option argument `ssh` accepts, given that characters such as `=`, `/`, and `\`, are URL-encoded, `:` is removed, and the argument passed to `ssh` contains the `@` sign and subsequent host identifier, which in an effective attack must be parseable as a suffix of the operand passed to the last option. - The inability to include a literal `=` prevents the use of `-oNAME=VALUE` (e.g., `-oProxyCommand=payload`). The inability to include a literal `/` or `\` prevents smuggling in a path operand residing outside the current working directory, incuding on Windows. (Although a `~` character may be smuggled in, `ssh` does not perform its own tilde expansion, so it does not form an absolute path.) + The inability to include a literal `=` prevents the use of `-oNAME=VALUE` (e.g., `-oProxyCommand=payload`). The inability to include a literal `/` or `\` prevents smuggling in a path operand residing outside the current working directory, including on Windows. (Although a `~` character may be smuggled in, `ssh` does not perform its own tilde expansion, so it does not form an absolute path.) - The difficulty, or perhaps impossibility, of completing a connection (other than when arbitrary code execution has been achieved). This complicates or altogether prevents the use of options such as `-A` and `-X` together with a connection to a real but malicious server. The reason a connection cannot generally be completed when exploiting this vulnerability is that, because the argument `gix-transport` intends as a URL is treated as an option argument, `ssh` treats the subsequent non-option argument `git-upload-pack` as the host instead of the command, but it is not a valid host name. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-worktree/RUSTSEC-2024-0349.md new/advisory-db-20240730/crates/gix-worktree/RUSTSEC-2024-0349.md --- old/advisory-db-20240528/crates/gix-worktree/RUSTSEC-2024-0349.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-worktree/RUSTSEC-2024-0349.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,87 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0349" +package = "gix-worktree" +date = "2024-05-22" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-7w47-3wg8-547c" +references = [ + "https://github.com/advisories/GHSA-7w47-3wg8-547c", + "https://nvd.nist.gov/vuln/detail/CVE-2024-35186", +] +categories = ["code-execution"] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H" +keywords = ["directory-traversal"] +aliases = ["CVE-2024-35186", "GHSA-7w47-3wg8-547c"] +license = "CC0-1.0" + +[versions] +patched = [">= 0.34.0"] +``` + +# 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/gix-worktree/RUSTSEC-2024-0353.md new/advisory-db-20240730/crates/gix-worktree/RUSTSEC-2024-0353.md --- old/advisory-db-20240528/crates/gix-worktree/RUSTSEC-2024-0353.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/gix-worktree/RUSTSEC-2024-0353.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,91 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0353" +package = "gix-worktree" +date = "2024-05-22" +url = "https://github.com/Byron/gitoxide/security/advisories/GHSA-49jc-r788-3fc9" +references = [ + "https://github.com/advisories/GHSA-49jc-r788-3fc9", + "https://nvd.nist.gov/vuln/detail/CVE-2024-35197", +] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L" +aliases = ["CVE-2024-35197", "GHSA-49jc-r788-3fc9"] +license = "CC0-1.0" + +[affected] +os = ["windows"] + +[versions] +patched = [">= 0.34.0"] +``` + +# 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 <kbd>Ctrl</kbd>+<kbd>C</kbd>. + +However, if desired, input can be provided. Ending input with <kbd>Ctrl</kbd>+<kbd>Z</kbd> followed by <kbd>Enter</kbd> 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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/lexical/RUSTSEC-2023-0055.md new/advisory-db-20240730/crates/lexical/RUSTSEC-2023-0055.md --- old/advisory-db-20240528/crates/lexical/RUSTSEC-2023-0055.md 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/crates/lexical/RUSTSEC-2023-0055.md 2024-07-26 20:09:25.000000000 +0200 @@ -24,7 +24,7 @@ ## Alternatives -For quickly parsing floating-point numbers third-party crates are no longer needed. A fast float parsing algorith by the author of `lexical` has been [merged](https://github.com/rust-lang/rust/pull/86761) into libcore. +For quickly parsing floating-point numbers third-party crates are 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. For quickly parsing integers, consider `atoi` and `btoi` crates (100% safe code). `atoi_radix10` provides even faster parsing, but only with `-C target-cpu=native`, and at the cost of some `unsafe`. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/matrix-sdk-crypto/RUSTSEC-2024-0356.md new/advisory-db-20240730/crates/matrix-sdk-crypto/RUSTSEC-2024-0356.md --- old/advisory-db-20240528/crates/matrix-sdk-crypto/RUSTSEC-2024-0356.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/matrix-sdk-crypto/RUSTSEC-2024-0356.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,30 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0356" +package = "matrix-sdk-crypto" +date = "2024-07-18" +url = "https://github.com/matrix-org/matrix-rust-sdk/security/advisories/GHSA-4qg4-cvh2-crgg" +categories = ["crypto-failure"] +aliases = ["CVE-2024-40648", "GHSA-4qg4-cvh2-crgg"] + +[affected] +functions = { "matrix_sdk_crypto::UserIdentity::is_verified" = ["< 0.7.2"] } + +[versions] +patched = [">= 0.7.2"] + +``` +# `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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/nano-id/RUSTSEC-2024-0343.md new/advisory-db-20240730/crates/nano-id/RUSTSEC-2024-0343.md --- old/advisory-db-20240528/crates/nano-id/RUSTSEC-2024-0343.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/nano-id/RUSTSEC-2024-0343.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,74 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0343" +package = "nano-id" +date = "2024-06-03" +categories = ["crypto-failure"] +cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L" +aliases = ["GHSA-2hfw-w739-p7x5", "GHSA-9hc7-6w9r-wj94", "CVE-2024-36400"] + +[affected] +functions = { "nano_id::base58" = ["< 0.4.0"], "nano_id::base62" = ["< 0.4.0"], "nano_id::gen" = ["< 0.4.0"] } + +[versions] +patched = [">= 0.4.0"] +``` + +# Reduced entropy due to inadequate character set usage + +## Description + +Affected versions of the nano-id crate incorrectly generated IDs using a reduced character set in the `nano_id::base62` and `nano_id::base58` functions. Specifically, the `base62` function used a character set of 32 symbols instead of the intended 62 symbols, and the `base58` function used a character set of 16 symbols instead of the intended 58 symbols. Additionally, the `nano_id::gen` macro is also affected when a custom character set that is not a power of 2 in size is specified. + +It should be noted that `nano_id::base64` is not affected by this vulnerability. + +## Impact + +This can result in a significant reduction in entropy, making the generated IDs predictable and vulnerable to brute-force attacks when the IDs are used in security-sensitive contexts such as session tokens or unique identifiers. + +## Patches + +The flaws were corrected in commit [a9022772b2f1ce38929b5b81eccc670ac9d3ab23](https://github.com/viz-rs/nano-id/commit/a9022772b2f1ce38929b5b81eccc670ac9d3ab23) by updating the the `nano_id::gen` macro to use all specified characters correctly. + +## PoC + +```rust +use std::collections::BTreeSet; + +fn main() { + test_base58(); + test_base62(); +} + +fn test_base58() { + let mut produced_symbols = BTreeSet::new(); + + for _ in 0..100_000 { +id = "RUSTSEC-2024-0343" + for c in id.chars() { + produced_symbols.insert(c); + } + } + + println!( + "{} symbols generated from nano_id::base58", + produced_symbols.len() + ); +} + +fn test_base62() { + let mut produced_symbols = BTreeSet::new(); + + for _ in 0..100_000 { +id = "RUSTSEC-2024-0343" + for c in id.chars() { + produced_symbols.insert(c); + } + } + + println!( + "{} symbols generated from nano_id::base62", + produced_symbols.len() + ); +} +``` diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/object_store/RUSTSEC-2024-0358.md new/advisory-db-20240730/crates/object_store/RUSTSEC-2024-0358.md --- old/advisory-db-20240528/crates/object_store/RUSTSEC-2024-0358.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/object_store/RUSTSEC-2024-0358.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,41 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0358" +package = "object_store" +date = "2024-07-23" +url = "https://github.com/apache/arrow-rs/pull/6074" +references = ["https://www.openwall.com/lists/oss-security/2024/07/23/3"] +cvss = "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N" + +keywords = ["information", "leak", "aws", "oidc", "logs"] +aliases = ["CVE-2024-41178"] + +[versions] +patched = [">= 0.10.2"] + +unaffected = ["< 0.5.0"] +``` + +# 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 diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/openssl/RUSTSEC-2024-0357.md new/advisory-db-20240730/crates/openssl/RUSTSEC-2024-0357.md --- old/advisory-db-20240528/crates/openssl/RUSTSEC-2024-0357.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/openssl/RUSTSEC-2024-0357.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,17 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0357" +package = "openssl" +date = "2024-07-21" +url = "https://github.com/sfackler/rust-openssl/pull/2266" + +[affected] +functions = { "openssl::bio::MemBio::get_buf" = ["< 0.10.66, >=0.8.0"] } + +[versions] +patched = [">= 0.10.66"] +``` + +# `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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/sequoia-openpgp/RUSTSEC-2024-0345.md new/advisory-db-20240730/crates/sequoia-openpgp/RUSTSEC-2024-0345.md --- old/advisory-db-20240528/crates/sequoia-openpgp/RUSTSEC-2024-0345.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/sequoia-openpgp/RUSTSEC-2024-0345.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,54 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0345" +package = "sequoia-openpgp" +date = "2024-06-26" +url = "https://gitlab.com/sequoia-pgp/sequoia/-/issues/1106" +categories = ["denial-of-service"] +keywords = ["infinite-loop"] + +[versions] +patched = [">= 1.21.0"] +unaffected = ["< 1.13.0"] + +[affected] +functions = { "sequoia_openpgp::cert::raw::RawCertParser" = [">= 1.13.0, < 1.21.0"] } +``` + +# Low severity (DoS) vulnerability in sequoia-openpgp + +There is a denial-of-service vulnerability in sequoia-openpgp, our +crate providing a low-level interface to our OpenPGP implementation. +When triggered, the process will enter an infinite loop. + +Many thanks to Andrew Gallagher for disclosing the issue to us. + +## Impact + +Any software directly or indirectly using the interface +`sequoia_openpgp::cert::raw::RawCertParser`. Notably, this includes all +software using the `sequoia_cert_store` crate. + +## Details + +The `RawCertParser` does not advance the input stream when +encountering unsupported cert (primary key) versions, resulting in an +infinite loop. + +The fix introduces a new raw-cert-specific +`cert::raw::Error::UnuspportedCert`. + +## Affected software + +- sequoia-openpgp 1.13.0 +- sequoia-openpgp 1.14.0 +- sequoia-openpgp 1.15.0 +- sequoia-openpgp 1.16.0 +- sequoia-openpgp 1.17.0 +- sequoia-openpgp 1.18.0 +- sequoia-openpgp 1.19.0 +- sequoia-openpgp 1.20.0 +- Any software built against a vulnerable version of sequoia-openpgp + which is directly or indirectly using the interface + `sequoia_openpgp::cert::raw::RawCertParser`. Notably, this includes + all software using the `sequoia_cert_store` crate. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/time/RUSTSEC-2020-0071.md new/advisory-db-20240730/crates/time/RUSTSEC-2020-0071.md --- old/advisory-db-20240528/crates/time/RUSTSEC-2020-0071.md 2024-05-26 22:27:57.000000000 +0200 +++ new/advisory-db-20240730/crates/time/RUSTSEC-2020-0071.md 2024-07-26 20:09:25.000000000 +0200 @@ -42,7 +42,7 @@ ### Impact -Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. +The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries. The affected functions from time 0.2.7 through 0.2.22 are: @@ -55,9 +55,10 @@ The affected functions in time 0.1 (all versions) are: -- `at` -- `at_utc` -- `now` +- `time::at_utc` +- `time::at` +- `time::now` +- `time::tzset` Non-Unix targets (including Windows and wasm) are unaffected. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/vodozemac/RUSTSEC-2024-0354.md new/advisory-db-20240730/crates/vodozemac/RUSTSEC-2024-0354.md --- old/advisory-db-20240528/crates/vodozemac/RUSTSEC-2024-0354.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/vodozemac/RUSTSEC-2024-0354.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,34 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0354" +package = "vodozemac" +date = "2024-07-17" +url = "https://github.com/matrix-org/vodozemac/security/advisories/GHSA-j8cm-g7r6-hfpq" +categories = ["crypto-failure", "memory-exposure"] +aliases = ["CVE-2024-40640", "GHSA-j8cm-g7r6-hfpq"] + +[versions] +patched = [">= 0.7.0"] +``` + +# 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 diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/xmp_toolkit/RUSTSEC-2024-0360.md new/advisory-db-20240730/crates/xmp_toolkit/RUSTSEC-2024-0360.md --- old/advisory-db-20240528/crates/xmp_toolkit/RUSTSEC-2024-0360.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/xmp_toolkit/RUSTSEC-2024-0360.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,27 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0360" +package = "xmp_toolkit" +date = "2024-07-26" +url = "https://github.com/adobe/xmp-toolkit-rs/issues/233" +informational = "unsound" +keywords = ["xmp"] + +[affected] +functions = { "xmp_toolkit::XmpFile::close" = ["< 1.9.0"] } + +[versions] +patched = [">= 1.9.0"] +``` + +# `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. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/zerovec/RUSTSEC-2024-0347.md new/advisory-db-20240730/crates/zerovec/RUSTSEC-2024-0347.md --- old/advisory-db-20240528/crates/zerovec/RUSTSEC-2024-0347.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/zerovec/RUSTSEC-2024-0347.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,19 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0347" +package = "zerovec" +date = "2024-07-01" +categories = ["memory-corruption"] + +[versions] +patched = [">= 0.10.4", ">= 0.9.7, <0.10.0"] +``` + +# Incorrect usage of `#[repr(packed)]` + +The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. + +The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts +reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses. + +The patched versions `0.9.7` and `0.10.4` use `#[repr(C, packed)]`, which guarantees field order. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/advisory-db-20240528/crates/zerovec-derive/RUSTSEC-2024-0346.md new/advisory-db-20240730/crates/zerovec-derive/RUSTSEC-2024-0346.md --- old/advisory-db-20240528/crates/zerovec-derive/RUSTSEC-2024-0346.md 1970-01-01 01:00:00.000000000 +0100 +++ new/advisory-db-20240730/crates/zerovec-derive/RUSTSEC-2024-0346.md 2024-07-26 20:09:25.000000000 +0200 @@ -0,0 +1,19 @@ +```toml +[advisory] +id = "RUSTSEC-2024-0346" +package = "zerovec-derive" +date = "2024-07-01" +categories = ["memory-corruption"] + +[versions] +patched = [">= 0.10.3", ">= 0.9.7, <0.10.0"] +``` + +# Incorrect usage of `#[repr(packed)]` + +The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. + +The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts +reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses. + +The patched versions `0.9.7` and `0.10.3` use `#[repr(C, packed)]`, which guarantees field order.