Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2010-3697 freeradius: crash when processing requests queued for more than 30 seconds|
|Product:||[Other] Security Response||Reporter:||Vincent Danen <vdanen>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Version:||unspecified||CC:||aland, dpal, jdennis, security-response-team|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-11-25 13:09:07 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||639490|
Description Vincent Danen 2010-10-01 12:11:03 EDT
It was reported , 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  in 2.1.10.  https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=35  http://secunia.com/advisories/41621  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).
Comment 2 Vincent Danen 2010-10-01 17:53:46 EDT
This issue has been assigned the name CVE-2010-3697.
Comment 3 Vincent Danen 2010-10-01 17:59:08 EDT
Created freeradius tracking bugs for this issue Affects: fedora-all [bug 639490]
Comment 4 aland 2010-10-03 12:45:32 EDT
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.
Comment 5 Vincent Danen 2010-11-25 12:51:23 EST
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.
Comment 6 Vincent Danen 2011-05-03 12:49:46 EDT
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.