[Pkg-freeradius-maintainers] Bug#929466: FreeRADIUS opinion of this issue

Alan DeKok aland at freeradius.org
Sat May 25 20:55:30 BST 2019

  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 "security at freeradius.org", which has been
active for almost 20 years.  This address and security instructions
are available on our web site at:


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

In addition, there also appears to be disagreement within RedHat about
the severity and scope of this issue.  The original reporter [2]

> 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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20190525/2a43badc/attachment.sig>

More information about the Pkg-freeradius-maintainers mailing list