World Writable Directory in /var/log/below Allows Local Privilege Escalation
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.
[1]: https://github.com/facebookincubator/below/blob/v0.8.1/below/src/main.rs#L379
[2]: https://build.opensuse.org/projects/openSUSE:Factory/packages/below/files/below.spec?expand=1&rev=5e78e7f743f87bea8648eeee673c649b
[3]: https://github.com/gentoo/gentoo/blob/master/sys-process/below/below-0.8.1-r1.ebuild#L344
[4]: https://src.fedoraproject.org/rpms/rust-below/blob/6ae58353b5d12e58462425c20a2aedfbae2e769a/f/rust-below.spec#_108
[5]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=below#n34
[6]: https://github.com/facebookincubator/below/blob/v0.8.1/below/src/main.rs#L552
[7]: https://github.com/facebookincubator/below/blob/v0.8.1/below/src/open_source/logging.rs#L68
