From the secunia advisory: Two vulnerabilities have been reported in FreeRADIUS, which can be exploited by malicious people to cause a DoS (Denial of Service). 1) An error when processing requests queued for more than 30 seconds in main/event.c can be exploited to cause the process to crash by sending high volume of requests for an extended period of time. 2) An error when processing DHCP requests with the "Relay Agent Information" option (82) in lib/dhcp.c can be exploited to cause an infinite loop in the process denying further requests via a packet with multiple sub-options. The vulnerabilities are reported in version 2.1.9. Other versions may also be affected. The upstream bugs are at: https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=35 https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=77
CVEs assigned: > > Requesting CVE names for two flaws fix in freeradius 2.1.10: > > > > DoS via certain DHCP requests > > [1] https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=77 > > [2] http://secunia.com/advisories/41621 > > [3] http://github.com/alandekok/freeradius-server/commit/4dc7800b866f889a1247685bbaa6dd4238a56279 > > [4] https://bugzilla.redhat.com/show_bug.cgi?id=639390 Use CVE-2010-3696 > > > > crash when processing requests queued for more than 30 seconds > > [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 > > [4] https://bugzilla.redhat.com/show_bug.cgi?id=639397 > > > > > > Both issues only affect 2.1.x (1.1.x does not have the affected files or > > functions). It looks as though the first issue only affected 2.1.9; I'm > > not yet sure if or how far the second issue may go back. > > Use CVE-2010-3697
2.1.{10,11} are in portage. Maybe we can stabilize those and close this bug?
(In reply to comment #2) > 2.1.{10,11} are in portage. Maybe we can stabilize those and close this bug? Thanks, Markos. Stabilizing 2.1.11; please correct me if you'd rather go with 2.1.10 which is also fixed (but currently masked). Arches, please test and mark stable: =net-dialup/freeradius-2.1.11 Target keywords : "amd64 x86"
(In reply to comment #3) > (In reply to comment #2) > > 2.1.{10,11} are in portage. Maybe we can stabilize those and close this bug? > > Thanks, Markos. Stabilizing 2.1.11; please correct me if you'd rather go with > 2.1.10 which is also fixed (but currently masked). > > Arches, please test and mark stable: > =net-dialup/freeradius-2.1.11 > Target keywords : "amd64 x86" The 2.1.10 mask has been lifted 2-3 days ago. It was masked for broader testing since I am not the actual maintainer of this package but I am taking care of it until mrness is back. I think 2.1.11 can go stable but ATs do need to test it very thoroughly.
Created attachment 288081 [details] /var/tmp/portage/net-dialup/freeradius-2.1.11/temp/build.log USE=frxp fails
(In reply to comment #5) > Created attachment 288081 [details] > /var/tmp/portage/net-dialup/freeradius-2.1.11/temp/build.log > > USE=frxp fails This is on x86.
@Thomas, please open a new bug and add as a block. with LC_ALL=C if you can ;)
amd64: emerges ok with all use flags set, unlike x86. No test suite. Only flaw is some QA notices, relates to upstream; i.e. not a blocker Passes
CVE-2010-3697 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3697): The wait_for_child_to_die function in main/event.c in FreeRADIUS 2.1.x before 2.1.10, in certain circumstances involving long-term database outages, does not properly handle long queue times for requests, which allows remote attackers to cause a denial of service (daemon crash) by sending many requests. CVE-2010-3696 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3696): The fr_dhcp_decode function in lib/dhcp.c in FreeRADIUS 2.1.9, in certain non-default builds, does not properly handle the DHCP Relay Agent Information option, which allows remote attackers to cause a denial of service (infinite loop and daemon outage) via a packet that has more than one sub-option. NOTE: some of these details are obtained from third party information.
x86 stable, thanks!
not passes for me. It fails to start without any error(s). amd64box ~ # /etc/init.d/radiusd start -vvv radiusd | * Starting radiusd ...[ !! ] radiusd | * ERROR: radiusd failed to start amd64box ~ # Any advise/other how to test?
@mrness, since you're "back" can you take a look at this?
If you use the default configuration file, you should check the logs in /var/log/radius directory.
I've not experience with raidus, I hope that is not my fault: Error: rlm_eap: Failed to link EAP-Type/tls: file not found Error: /etc/raddb/eap.conf[17]: Instantiation failed for module "eap" Error: /etc/raddb/sites-enabled/default[299]: Failed to load module "eap". Error: /etc/raddb/sites-enabled/default[241]: Errors parsing authenticate section. Error: Failed to load virtual server <default>
Well, the easiest way to fix this is to comment out everything that it fails to start (e.g. eap).
ok, the daemon starts as well now, amd64 ok
amd64 done. Thanks Agostino
Thanks, folks. GLSA Vote: yes.
Vote: Yes. GLSA request filed.
This issue was resolved and addressed in GLSA 201311-09 at http://security.gentoo.org/glsa/glsa-201311-09.xml by GLSA coordinator Sergey Popov (pinkbyte).
