|Summary:||CVE-2020-14367 chrony: Insecure writing to PID file|
|Product:||[Other] Security Response||Reporter:||Marco Benatto <mbenatto>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||NEW ---||QA Contact:|
|Fixed In Version:||chrony 3.5.1||Doc Type:||If docs needed, set a value|
A flaw was found in chrony when creating the PID file under the /var/run/chrony folder. The file is created during chronyd startup while still running as the root user, and when it's opened for writing, chronyd does not check for an existing symbolic link with the same file name. This flaw allows an attacker with privileged access to create a symlink with the default PID file name pointing to any destination file in the system, resulting in data loss and a denial of service due to the path traversal.
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1872720, 1872721, 1870299, 1870312, 1870313|
Description Marco Benatto 2020-08-19 17:25:16 UTC
When chronyd is configured to save the pidfile in a directory where the chrony user has write permissions (e.g. /var/run/chrony - the default since chrony-3.4), an attacker that compromised the chrony user account could create a symbolic link at the location of the pidfile to make chronyd starting with root privileges follow the symlink and write its process ID to a file for which the chrony user doesn't have write permissions, causing a denial of service, or data loss.
Comment 1 Marco Benatto 2020-08-19 17:25:36 UTC
Created chrony tracking bugs for this issue: Affects: fedora-all [bug 1870299]
Comment 2 Marco Benatto 2020-08-19 17:28:25 UTC
Acknowledgments: Name: Matthias Gerstner (Suse)
Comment 5 Marco Benatto 2020-08-19 20:14:40 UTC
There's an issue on chrony when creating the PID file under /var/run/chrony folder. The file is created during chronyd startup, while still running under as root user, and when it's opened for writing chronyd doesn't check if there's already a symbolic link with the same file name. An attack with privileged access may leverage this issue by creating a symlink with the default pid file name point to any destination file in the system, this may cause data loss and/or deny of service as result of the path traversal.
Comment 6 Marco Benatto 2020-08-20 14:27:08 UTC