gix-worktree-state nonexclusive checkout sets executable files world-writable
Date: 2025-01
Affected: rust/gix-worktree-state
Attack vector: other
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2025-22620
CWE: CWE-281
CWE-687
CVSS: 5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N)

### Summary `gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations. ### Details Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported). [`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable: - If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask. - If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask. Specifically, [`checkout::entry::checkout`](https://github.co


Mitigations:

Architectural layers (MAESTRO):