Date: Fri, 21 Aug 2020 10:57:25 +0200 From: Matthias Gerstner <mgerstner@...e.de> To: oss-security@...ts.openwall.com Subject: chrony: CVE-2020-14367: unsafe pidfile creation allows privilege escalation from chrony user to root Hello, chrony is a versatile implementation of the Network Time Protocol (NTP) . # Issue Description The following applies to chrony version 3.5. In chronyd's main() function the call to `write_pidfile()` is made with full root privileges, while the privilege drop logic is only performed later via `SYS_DropRoot()`. The pidfile is created using `fopen()`. It seems a common default setup for chronyd currently is as follows: - "chrony" user and group are used as unprivileged accounts to run chronyd as. - The directory /run/chrony is created via systemd-tmpfiles (or during runtime by chronyd itself, in `CNF_CreateDirs()`). Ownership is passed to chrony:chrony, mode is 0750. - The DEFAULT_PID_FILE path is set to /run/chrony/chronyd.pid (since chrony 3.4). This constellation means that a compromised chrony user account can stage a symlink attack in /run/chrony/chronyd.pid like follows: ``` root# systemctl stop chronyd.service root# sudo -u chrony /bin/bash # simulate a compromised chrony user staging a symlink attack chrony# cd /run/chrony chrony# ln -s /etc/fstab chronyd.pid chrony# exit # make sure to keep a backup of /etc/fstab if it is dear to you root# cp /etc/fstab /etc/fstab.back root# /usr/sbin/chronyd -n ^C # fstab content got replaced by the chronyd PID root# cat /etc/fstab 11354 ``` So this attack mostly poses denial-of-service attack vector. It could also be used to pre-create a file with mode 0644 that would then later be used by other programs to store sensitive data. # Mitigations On recent systemd versions the issue is not severe as long as chronyd is only started via the systemd service unit. This is the case because it contains the ProtectSystem=full directive and thus no write permission is granted for system file locations. # Upstream Fixes Upstream created a bugfix release 3.5.1  that fixes this issue. The development master branch in the upstream git repository was not affected any more due to changed file open logic (switched from using `fopen()` to using `open()` and appropriate flags). The bugfix  was performed on a release branch for version 3.5.1. # Timeline - 2020-08-05: I found the issue and reported it privately to the upstream main developer Miroslav Lichvar. During the following two weeks We discussed the issue and the possible fixes and agreed on a patch. SUSE tracked the issue internally via Bugzilla . - 2020-08-19: Upstream communicated to me a CVE assignment for the issue and prepared the publication of bugfix release 3.5.1. : https://chrony.tuxfamily.org : https://bugzilla.suse.com/show_bug.cgi?id=1174911 : https://chrony.tuxfamily.org/news.html : https://git.tuxfamily.org/chrony/chrony.git/commit/?id=f00fed20092b6a42283f29c6ee1f58244d74b545 Cheers Matthias -- Matthias Gerstner <matthias.gerstner@...e.de> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security Phone: +49 911 740 53 290 GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.