It was reported [1],[2] that an error when processing requests queued for more than 30 seconds in src/main/event.c could be exploited to cause the process to crash by sending a large number of requests for an extended period of time. This flaw seems to only affect 2.1.x and was fixed [3] in 2.1.10. [1] https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=35 [2] http://secunia.com/advisories/41621 [3] http://github.com/alandekok/freeradius-server/commit/ff94dd35673bba1476594299d31ce8293b8bd223 The offending file (event.c), nor the affected function (wait_for_child_to_die()) are not present in the version of freeradius as provided with Red Hat Enterprise Linux 5 (1.1.3).
This issue has been assigned the name CVE-2010-3697.
Created freeradius tracking bugs for this issue Affects: fedora-all [bug 639490]
It would help to talk to the vendor before requesting a CVE, and filing a security issue. 1) it is exploitable *only* by known clients. i.e. by people within the trust network 2) you have to send 10's of millions of packets to see it on some systems I've sent *billions* of packets, and not seen it. 3) the system has to log to a database 4) which is down for extended periods of time. The net effect is that "if your RADIUS server is unresponsive for extended periods, there's an issue which can make it unresponsive" As a result, the issue is annoying, but minor. It is *not* externally exploitable, and has *no* security impact.
I am inclined to agree with Alan here. If the RADIUS server is down already, it isn't really a denial of service since the service is already unavailable. As a result, this is not something we intend to fix as it has no security impact. Statement: Red Hat does not consider this to a security issue. In order for the crash condition to be observed, the RADIUS server must already be unresponsive for extended periods of time, the net result of which is that you cannot DoS an already-unresponsive server. Other specialized conditions are required as well, that make an attack using this flaw unviable.
Upstream has made the following public dispute to this flaw (http://freeradius.org/security.html): 2010.10.01 CVE-2010-3697 - This issue was filed without consulting with us, and we do not agree with the assessment. The correct summary is that if the database is down for a long time and the server is unresponsive, there are corner cases where known clients (not attackers) sending large amounts of data can cause the server to crash. In normal operation, when the server stops responding to packets (i.e. because the database is down), the NAS will stop sending it packets, and will fail over to another server. In addition, our tests indicate that this issue occurs only when the database is down for extended periods of time, and the server receives many millions of packets during that time. i.e. the problem will not occur in most deployments. We recommend that deployments monitor their database and RADIUS server. If the database is down for extended periods, the root cause should be investigated and corrected. When FreeRADIUS is configured to depend on a database, database outages will naturally cause service outages for the RADIUS server. People who want a fix to this issue can upgrade to the latest version of the server.