It was discovered freeradius does not correctly configure logrotate, allowing a local attacker who already has control of the radiusd user to escalate his privileges to root, by tricking logrotate into writing a radiusd-writable file to a directory normally inaccessible by the radiusd user.
A reverse-shell facilitating situation due to insecure logrotate configuration leading to privilege escalation.
Created freeradius tracking bugs for this issue:
Affects: fedora-all [bug 1705343]
It is possible for the radiusd user to abuse logrotate to write files in directories normally writable only by root (or other users). freeradius uses logrotate to rotate its logs, but if the radiusd user replaces its log directory with a link to another directory, he could writes file in directories where he normally could not write, possibly leading to code execution as root.
Given the attack can be performed only from the radiusd user, Privilege Required(PR) in CVSSv3 is set to High(H).
Moreover, if SELinux is enabled it restricts the set of directories the attacker can writes to.
Add `su radiusd:radiusd` to all log sections in /etc/logrotate.d/radiusd.
By keeping SELinux in "Enforcing" mode, radiusd user will be limited in the directories he can write to.
Red Hat Enterprise Linux 5, 6, 7, and 8 are all affected as the logrotate configuration does not use `su radiusd:radiusd` to copy files as the radiusd user.
This flaw requires an attacker to already have control of the radiusd server to perform the attack. However, an attacker who was able to execute code as the radiusd user (e.g. by exploiting a code execution flaw in the radius server) can run the attack and elevate his privileges to root.