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 - [email protected]
+
+- 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">[email protected]</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 <[email protected]> and Lea Themint
<[email protected]> 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.
