- Reported
-
- Issued
-
- Package
-
below
(crates.io)
- Type
-
Vulnerability
- Categories
-
- Aliases
-
- References
-
- CVSS Score
- 7.3
HIGH
- CVSS Details
-
- Attack Complexity
- Low
- Attack Requirements
- Present
- Attack Vector
- Local
- Privileges Required
- Low
- Availability Impact to the Subsequent System
- None
- Confidentiality Impact to the Subsequent System
- None
- Integrity Impact to the Subsequent System
- None
- User Interaction
- None
- Availability Impact to the Vulnerable System
- High
- Confidentiality Impact to the Vulnerable System
- High
- Integrity Impact to the Vulnerable System
- High
- CVSS Vector
- CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
- Patched
-
Description
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.
Advisory available under CC0-1.0
license.