CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
NONE
Availability Impact
NONE
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
EPSS
Percentile
40.0%
The filesystem glob pattern wildcards *
, ?
, and [...]
match file path literals and leading dots by default, which unintentionally exposes sub folder content of allowed paths.
Example: The fs
scope $HOME/*.key
would also allow $HOME/.ssh/secret.key
to be read even though it is in a sub directory of $HOME
and is inside a hidden folder.
Scopes without the wildcards are not affected. As **
allows for sub directories the behavior there is also as expected.
The issue has been patched in the latest release and was backported into the currently supported 1.x branches.
No workaround is known at the time of publication.
The original report contained information that the dialog.open
component automatically allows one sub directory to be read, regardless of the recursive
option.
Imagine a file system looking like
o ../
o documents/
- file.txt
- deeper/
o deep_file.txt
Reproduction steps:
The recursive flag is used in https://github.com/tauri-apps/tauri/blob/cd8c074ae6592303d3f6844a4fb6d262eae913b2/core/tauri/src/scope/fs.rs#L154 to scope the filesystem access to either files in the folder or to also include sub directories.
The original issue was replicated and further investigated.
The root cause was triaged to the glob
crate facilitating defaults, which allow the *
and [...]
to also match path literals.
MatchOptions {
case_sensitive: true,
require_literal_separator: false,
require_literal_leading_dot: false
}
This implicated that not only the dialog.open
component was affected but rather all fs
scopes containing the *
or [...]
glob.
During this investigation it became obvious that the current glob matches would also match hidden folder (e.g: .ssh
) content by default, without explicitly allowing hidden folders to be matched. This is not commonly expected behavior in comparison to for example bash
.
The new default Match options are:
MatchOptions {
case_sensitive: true,
require_literal_separator: true,
require_literal_leading_dot: true
}
> Another note security relevant for developers building applications interacting with case sensitive filesystems is, that the case_sensitive
option only affects ASCII file paths and is not valid in Unicode based paths. This is considered a known risk until the glob
crate supports non-ASCII file paths for this type of case sensitive matching.
If you have any questions or comments about this advisory:
Open an issue in tauri
Email us at [email protected]
github.com/advisories/GHSA-6mv3-wm7j-h4w5
github.com/tauri-apps/tauri/commit/14d567f7ecb25a6d1024cf3d796f86aee89d0dd4
github.com/tauri-apps/tauri/commit/72389b00d7b495ffd7750eb1e75a3b8537d07cf3
github.com/tauri-apps/tauri/commit/f0602e7c294245ab6ef6fbf2a976ef398340ef58
github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5
nvd.nist.gov/vuln/detail/CVE-2022-46171