Here's what we sent CVE. In short, there is no actual "exploit".
--- We disagree with this CVE. In the GitHub report [1], the RedHat reporter claims: > we are aware of a way to exploit this, No description of this alleged exploit has been shared with us. Our security contact is "secur...@freeradius.org", which has been active for almost 20 years. This address and security instructions are available on our web site at: https://freeradius.org/security/ It is not clear why RedHat would refuse to share information about this issue, as is normal practice. In the GitHub report, RedHat further claims that exploitation > ... requires the attacker to already have "high privileges" (that is, he > needs to have access to the radiusd user) Which demonstrates that this issue is largely nonsense. A full explanation follows. While the FreeRADIUS server runs as user/group "radiusd/radiusd", that account has no login shell, no home directory, and no default password. The account is used solely to run the FreeRADIUS server, and to control ownership of configuration files and log files. These files are typically administered solely by the "root" user. As such, the CVE can be better stated as "if the root user misconfigures FreeRADIUS, then the RADIUS server can later elevate privileges to root". We have to ask why the "root" user would need to leverage a less-privileged account in order to gain "root" permissions. Further, anyone who can operate as the RADIUS server can perform all RADIUS authentication and authorization. i.e. authenticating all users on the network, including unknown and malicious users. There is at this time no known exploit which would let malicious users gain access to the "radiusd" user. Therefore as discussed here, there is simply no way for anyone to *gain* privileges through this alleged issue. In addition, there also appears to be disagreement within RedHat about the severity and scope of this issue. The original reporter [2] states: > The su directive to logrotate ensures that log rotation happens under the > owner of the logs. Otherwise, logrotate runs as root:root, potentially > enabling privilege escalation if a RCE is discovered against the > FreeRADIUS daemon. > > This attack avenue seems quite unlikely to me. We agree. We take great care in securing FreeRADIUS. We use multiple source code analyzers and fuzzing tests. Even the most charitable interpretation of this issue shows that the vulnerability is theoretical in nature, and is not currently exploitable. As such, we disagree with the issuance of this CVE. We also express dismay at the process by which this CVE was issued. We recommend that security "experts" follow best practices in discussing issues with authors prior to requesting spurious CVEs. [1] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issuecomment-495511510 [2] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issue-276755666 ---
signature.asc
Description: Message signed with OpenPGP
