RUSTSEC-2025-0149

Below is a tool for recording and displaying system data like hardware utilization and cgroup information on Linux.

Symlink Attack in /var/log/below/error_root.log

Below's systemd service runs with full root privileges. It attempts to create a world-writable directory in /var/log/below. Even if the directory already exists, the Rust code ensures [1] that it receives mode 0777 permissions:

    if perm.mode() & 0o777 != 0o777 {
        perm.set_mode(0o777);
        match dir.set_permissions(perm) {
            Ok(()) => {}
            Err(e) => {
                bail!(
                    "Failed to set permissions on {}: {}",
                    path.to_string_lossy(),
                    e
                );
            }
        }
    }

This logic leads to different outcomes depending on the packaging on Linux distributions:

• in openSUSE Tumbleweed the directory was packaged with 01755 permissions (below.spec [2] line 73), thus causing the set_permissions() call to run, resulting in a directory with mode 0777 during runtime.
• in Gentoo Linux the directory is created with mode 01755 resulting in the same outcome as on openSUSE Tumbleweed (below.ebuild [3]). Where the 01755 mode is exactly coming from is not fully clear, maybe the cargo build process assigns these permissions during installation.
• in Fedora Linux the directory is packaged with 01777 permissions, thus the set_permissions() code will not run, because the if condition masks out the sticky bit. The directory stays at mode 01777 (rust-below.spec [4]).
• the Arch Linux AUR package [5] (maybe wrongly) does not pre-create the log directory. Thus the set_permissions() code will run and create the directory with mode 0777.

Below creates a log file in /var/log/below/error_root.log and assigns mode 0666 to it. This (somewhat confusingly) happens via a log_dir variable [6], which has been changed to point to the error_root.log file. The 0666 permission assignment to the logfile happens in logging::setup() [7], also accompanied by a somewhat strange comment in the code.

A local unprivileged attacker can stage a symlink attack in this location and cause an arbitrary file in the system to obtain 0666 permissions, likely leading to a full local root exploit, if done right, e.g. by pointing the symlink to /etc/shadow. Even if the file already exists it can be removed and replaced by a symlink, because of the world-writable directory permissions. The attack is thus not limited to scenarios in which the file has not yet been created by Below.

Further Issues

Even on Fedora Linux, where /var/log/below has "safe" 01777 permissions, there is a time window during which problems can arise. As long as below.service has not been started, another local user can pre-create /var/log/below/error_root.log and e.g. place a FIFO special file there. This will pose a local DoS against the below service, since it will fail to open the path and thus fail to start.

If /var/log/below were to be deleted for any reason, then Below would still recreate it using the bad 0777 mode permissions, which can also happen on distributions that initially package /var/log/below using permissions that do not trigger the set_permissions() call in Below's code.