Bug 639397 (CVE-2010-3697)

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:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	aland, dpal, jdennis, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-11-25 18:09:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	639490
Bug Blocks:

Description Vincent Danen 2010-10-01 16:11:03 UTC

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).

Comment 2 Vincent Danen 2010-10-01 21:53:46 UTC

This issue has been assigned the name CVE-2010-3697.

Comment 3 Vincent Danen 2010-10-01 21:59:08 UTC

Created freeradius tracking bugs for this issue

Affects: fedora-all [bug 639490]

Comment 4 aland 2010-10-03 16:45:32 UTC

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 17:51:23 UTC

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 16:49:46 UTC

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.