oss-security - chrony: CVE-2020-14367: unsafe pidfile creation allows privilege escalation from chrony user to root

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20200821085725.GB24102@f195.suse.de>
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)
[1].

# 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 [3] 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 [4] 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 [2].

- 2020-08-19: Upstream communicated to me a CVE assignment for the issue
  and prepared the publication of bugfix release 3.5.1.

[1]: https://chrony.tuxfamily.org
[2]: https://bugzilla.suse.com/show_bug.cgi?id=1174911
[3]: https://chrony.tuxfamily.org/news.html
[4]: 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)

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.