An issue was discovered in GNOME gvfs 1.29.4 through 1.41.2. daemon/gvfsbackendadmin.c mishandles file ownership because setfsuid is not used. Upstream commit: https://gitlab.gnome.org/GNOME/gvfs/compare/5cd76d627f4d1982b6e77a0e271ef9301732d09e...3895e09d784ebec0fbc4614d5c37068736120e1d
Created gvfs tracking bugs for this issue: Affects: fedora-all [bug 1728563]
Upstream patch: https://gitlab.gnome.org/GNOME/gvfs/commit/d7d362995aa0cb8905c8d5c2a2a4c305d2ffff80
When using the admin:// backend to copy a file owned by root, the target file has the wrong ownership, making it accessible by the regular user and not by root only. admin:// backend can be used with GNOME gvfs to copy file owned by root by prompting the user to elevate his privileges. Regular `cp` utility would keep the same ownership of the source file and so gvfs should do as well.
Attack Vector set to Network (AV:N) as the vulnerability can be triggered in any application that makes use of gvfs and can use the admin:// backend. Attack Complexity set to High (AC:H) because even though any network application could use the admin:// backend provided by gvfs, you must have the authorization of an admin user to access root-owned files and a way to access the copied files afterwards. Privileged Required set to Low (PR:L) because the attacker needs to have at least some access on the vulnerable system to read the copied file accessible by the regular user. User Interaction set to Required (UI:R) as usually an operation with the admin:// backend requires the user to provide a password to elevate his privileges. Confidentiality and Integrity set to High (C:H) because the file created by the admin:// backend can be read/written by the regular user.
The issue is that function acquire_caps() drops root privileges to make dbus work, however it does not use setfsuid() to still behave like root when working with files. For this reason, when using admin:// target files are owned by the regular user and not by root.
In reply to comment #4: > When using the admin:// backend to copy a file owned by root, the target > file has the wrong ownership, making it accessible by the regular user and > not by root only. > > admin:// backend can be used with GNOME gvfs to copy file owned by root by > prompting the user to elevate his privileges. Regular `cp` utility would > keep the same ownership of the source file and so gvfs should do as well. Actually this flaw is only about copying file to a target one through the admin:// backend. The destination file, handled by the admin:// backend, is created with the regular user privileges instead that with the root ones, allowing the regular user to access the new file.
Reference: https://www.openwall.com/lists/oss-security/2019/07/09/3
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1766 https://access.redhat.com/errata/RHSA-2020:1766
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-12447