AI_ONLY_REPORT
package: cockpit-files-36-1.el10
------
Summary: Recursive Ownership Change in Paste Follows Symlinks: the  
privileged `Paste as owner` flow can recursively change ownership of  
symlink referents outside the pasted tree when a copied directory contains  
symlinks.
Requirements to exploit: A low-privileged local user must be able to  
prepare a directory tree containing a symlink, and another user must use  
the `cockpit-files` privileged paste flow with superuser mode available,  
choose `Paste as owner`, and select a non-`original` owner.
Component affected: `cockpit-files-36-1.el10`,  
`src/dialogs/copyPasteOwnership.tsx`, `pasteAsOwner()` privileged paste flow
Version affected: `cockpit-files-36-1.el10`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:L - 6.3 (MEDIUM)
AV:L - The attacker needs local access to prepare the copied directory  
tree and reach the file-management workflow.
AC:L - The behavior follows directly from copying a directory containing  
a symlink and triggering the privileged ownership-change path.
PR:L - Basic local user privileges are needed to create the crafted  
source tree.
UI:R - A user must confirm the `Paste as owner` dialog and choose a  
non-`original` owner.
S:U - The impact is limited to the same host and security authority.
C:L - Confidentiality can be reduced if the changed ownership grants  
read access to the symlink referent.
I:H - Ownership of files outside the pasted tree can be modified  
unexpectedly, which is a direct integrity violation and can enable  
follow-on abuse.
A:L - Changing ownership of sensitive files can disrupt access or  
require recovery, but broad denial of service is not established from the  
available evidence.
Impact: Moderate. Based on Red Hat's severity guidance, this issue can  
compromise integrity and, in some cases, confidentiality of local  
resources, but it requires local access, a crafted symlink tree, a  
privileged paste workflow, and user interaction in the ownership dialog.  
Those preconditions make it materially less straightforward to exploit than  
a typical Important issue.
Embargo: no
Reason: The issue is local and user-assisted, with reachable  
mitigations available before a fix is shipped. The available evidence  
supports prompt remediation, but it does not indicate a wormable,  
unauthenticated, or default-remote compromise scenario.
Acknowledgement: Aisle Research
Vulnerability Details: In the privileged paste flow, `pasteAsOwner()` first  
performs a privileged archive copy and then, when the selected owner is not  
`original`, performs a privileged recursive ownership change on the pasted  
paths:
```tsx
await cockpit.spawn([
"cp",
"--archive",
...clipboard.files.map(file => clipboard.path + "/" + file.name),
dstPath
], { superuser: "require" });
if (ownerStr !== "original") {
await cockpit.spawn([
"chown",
"--recursive",
ownerStr,
...clipboard.files.map(file => dstPath + "/" + file.name),
], { superuser: "require" });
}
```
On GNU `chown`, dereferencing symlinks is the default behavior unless  
`--no-dereference` is supplied. As a result, if a pasted directory contains  
a symlink, the recursive `chown` may affect the symlink referent rather  
than only objects within the copied tree. Because this code runs with  
`superuser: "require"`, the resulting ownership change can reach files  
outside the pasted directory.
The available evidence establishes unintended ownership changes outside the  
pasted tree. Any follow-on privilege escalation depends on the selected  
owner and the targeted referent, so that effect should be treated as  
conditional rather than guaranteed.
Steps to reproduce:
1. As an unprivileged user, prepare a source tree containing a symlink to a  
sensitive file:
```bash
mkdir -p /tmp/src/evil
ln -s /etc/shadow /tmp/src/evil/link_to_shadow
stat -c '%U:%G %n' /etc/shadow
```
2. In the UI, navigate to `/tmp/src` and copy `evil`.
3. Navigate to a destination where unprivileged paste fails but superuser  
mode is available.
4. Paste, then in `Paste as owner` choose any non-`original` owner and  
confirm.
5. Verify whether the referent ownership changed:
```bash
stat -c '%U:%G %n' /etc/shadow
```
6. Expected behavior: only files within the pasted tree should have their  
ownership changed.
7. Observed behavior: the symlink referent may have its ownership changed.
Mitigation: Until a fix is available, avoid using `Paste as owner` on  
copied trees that may contain symlinks. If privileged paste is required,  
keep the owner selection at `original`, which avoids the recursive `chown`  
path described above.
Proposed Fix: Add `--no-dereference` to the privileged recursive `chown`  
invocation so ownership changes apply to symlink objects rather than their  
referents.
```diff
diff --git a/src/dialogs/copyPasteOwnership.tsx  
b/src/dialogs/copyPasteOwnership.tsx
@@
if (ownerStr !== "original") {
await cockpit.spawn([
"chown",
"--recursive",
+                "--no-dereference",
ownerStr,
...clipboard.files.map(file => dstPath + "/" + file.name),
], { superuser: "require" });
}
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use