| Summary: | <net-dialup/freeradius-2.1.11: Two Denial of Service Vulnerabilities (CVE-2010-{3696,3697}) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Tim Sammut (RETIRED) <underling> | ||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | minor | CC: | hwoarang, mrness | ||||
| Priority: | High | ||||||
| Version: | unspecified | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| URL: | http://freeradius.org/press/index.html#2.1.10 | ||||||
| Whiteboard: | B3 [glsa] | ||||||
| Package list: | Runtime testing required: | --- | |||||
| Bug Depends on: | 385575 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Tim Sammut (RETIRED)
2010-10-01 21:04:05 UTC
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). |
