I am reporting to you a security finding in chronyc somewhat similar to CVE-2020-14367 which I reported many years ago. # Coordinated Disclosure We offer [coordinated disclosure](https://en.opensuse.org/openSUSE:Security_disclosure_policy) for a maximum of 90 days if you want to keep finding private for a while. If you rather want to handle everything in public, feel free to make this issue public right away. We prefer short embargo periods and suggest a coordinated release date of 2025-07-29 (14 days). The latest release date we can offer would be 2025-10-13 (90 days). # The Problem The problem is found in [bind_unix_address()](https://gitlab.com/chrony/chrony/-/blob/545bd59563d80aac2f48b89e6305937d72895fa3/socket.c#L645) where, after binding the socket name to the file system, a `chmod()` with mode 0666 is performed. This function might be called from different contexts, but I encountered it specifically when calling `chronyc cyclelogs`, which is found in the [logrotate example configuration file](https://gitlab.com/chrony/chrony/-/blob/master/examples/chrony.logrotate#L6). Logrotate invokes this with root privileges, and in `strace` we can observe the following sequence of system calls in `chronyc`: ``` socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 unlink("/run/chrony/chronyc.4307.sock") = -1 ENOENT (No such file or directory) bind(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.4307.sock"}, 32) = 0 chmod("/run/chrony/chronyc.4307.sock", 0666) = 0 connect(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyd.sock"}, 27) = -1 ENOENT (No such file or directory) getsockname(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.4307.sock"}, [112 => 32]) = 0 unlink("/run/chrony/chronyc.4307.sock") = 0 ``` The directory `/run/chrony` is typically owned by the unprivileged `chrony:chrony` user and group. This means the unprivileged `chrony` user can exploit a race condition found in the above system call sequence. It can wait e.g. via `inotifywait` for the socket to be bound, unlink and quickly replace it by a symlink to an arbitrary file in the system. If this succeeds, then the target file will receive move 0666, likely allowing for a local root exploit. The user isolation of the chrony service user account is thus violated and a compromised chronyd can rather easily gain full system access (although it has to wait for `chronyc` to be invoked to attempt the attack). I successfully tested the attack using a simple Python script. It took many attempts to succeed, but will likely be much easier when using a fast C program to perform the attack. # Suggested Fix On Linux an elegant fix is to call `fchmod(socket, mode)` before binding the socket. The umask might still apply during `bind()`, however. Therefore, also to cover other supported systems, the best fix is likely to call `umask(0111)`, then bind, then restore the original umask. This is not multi-threading safe, but I believe this is no issue in Chrony. Alternatively the socket could be placed in a different directory, e.g. directly into /run, or into /tmp. In `/tmp` no other users can remove the socket, due to the sticky bit. # Affected Systems I looked into openSUSE Tumbleweed and Fedora 42 and believe both are equally affected. # Note on Logrotate The line `su chrony chrony` should be added to the logrotate example configuration file, which lets logrotate drop to the service account for performing log rotation. This reduces potential symlink attack surface in the log directory. It does not lower privileges for the shell script execution, however.