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.
Upstream patch: https://github.com/FreeRADIUS/freeradius-server/pull/2666
Mitigation: 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.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1705143
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.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3353 https://access.redhat.com/errata/RHSA-2019:3353
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-10143
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:3984 https://access.redhat.com/errata/RHSA-2020:3984