Bug 1705143
| Summary: | Privilege escalation due to insecure logrotate configuration | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Wolfgang Hotwagner <sec> |
| Component: | freeradius | Assignee: | Alex Scheel <ascheel> |
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.6 | CC: | ascheel, kdudka, nikolai.kondrashov, pkis, rharwood |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-09-26 18:05:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hi, Any news for this case? Is it fixed? Hi Wolfgang, It will be fixed in RHEL 8.1.0. Please also see the top-level CVE tracker that was created for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1705340 Thanks, Alex *** This bug has been marked as a duplicate of bug 1719368 *** |
Description of problem: freeradius ships with a logrotate-configuration that includes the following lines: /var/log/radius/radacct/*/detail { monthly rotate 4 nocreate missingok compress } User radiusd is allowed to modify the logdirectory /var/log/radius/radacct/: drwx------. 3 radiusd radiusd 4096 26. Apr 16:01 /var/log/radius/radacct/ User radiusd could create the file /var/log/radius/radacct/logdir/file.log. Due to logrotate is prone to a race-condition(see https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition) it is possible for user "radiusd" to replace the directory /var/log/radius/radacct/logdir with a symbolik link to any directory(for example /etc/bash_completion.d). logrotate will place the compressed files AS ROOT into /etc/bash_completition.d and set the owner and group to "radiusd.radiusd". An attacker could simply place a reverse-shell into this file. As soon as root logs in, a reverse shell will be executed then. A sample exploit can be found on github https://github.com/whotwagner/logrotten (Note that this exploit doesn't work well in docker-containers or lvm2 volumes) Default installations might not be affected by this problem because SElinux should prevent logrotate from creating files in /etc. Version-Release number of selected component (if applicable): Name : freeradius Architektur : x86_64 Version : 3.0.13 Ausgabe : 9.el7_5 How reproducible: The following steps don't work on lvm2-volumes or container(overlayfs): 1. yum install freeradiusd 2. <disable SELINUX and reboot> 3. yum install git gcc 4. sudo -u radiusd bash 5. cd /tmp 6. git clone https://github.com/whotwagner/logrotten /tmp/logrotten 7. cd /tmp/logrotten 8. gcc -o logrotten logrotten.c 9. killall auditd # makes the exploit more reliable 10. killall tuned # makes the exploit more reliable 11. mkdir -p /var/log/radius/radacct/logdir 12. touch /var/log/radius/radacct/logdir/detail # run as user radiusd the exploit 13a. ./logrotten -c /var/log/radius/radacct/logdir/detail.1 # if you don't want to wait until next day, run logrotate manually as root: 13b. logrotate -f /etc/logrotate.d/radiusd Actual results: this should create the file /etc/bash_completion.d/detail.1.gz user radiusd could place a reverse-shell into this file and gets a connection as soon as root logs in. Expected results: logrotate should not create the file /etc/bash_completion.d/detail.1.gz Additional info: You could mitigate the problem by changing the owner and group of /var/log/radius/radacct/ to root or by using the "su"-directive in logrotate.