- Freeradius-Devel - lists.freeradius.org

SecurityTracker Alert ID 1017463
by Alan DeKok 29 Jan '07

29 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SecurityTracker Alert ID 1017463 was recently brought to our attention. Our official statement about this issue is: - -- Official Vendor Statement from the FreeRADIUS Server project This issue is not a security vulnerability. The exploit is available only to local administrators who have write access to the server configuration files. As such, this issue has no security impact on any system running FreeRADIUS. - -- Official Vendor Statement from the FreeRADIUS Server project Please update the title and impact fields to indicate that the issue is NOT remotely exploitable. The "solution" is simple: ensure that only authorized users have write access to the server configuration files. We are curious as to why the issue is labelled "remote execution of code". The original notification did not claim that the issue was vulnerable to remote exploit. If you have any additional data that causes you to believe it is remotely exploitable, that information should be supplied to us so we can fix the problem. Barring additional data, we believe that the issue is non-existent, and has no security impact on any system running FreeRADIUS. Alan DeKok Project Leader The FreeRADIUS Server Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb3g+6kul4vkAkl9AQL59QP/TO4aw3BpNkr3k3/lFqh2jYCymjEPjC1T GsVrW3ptuzDqO/JJ9lMWZYVPOjVWcfYWSPJg7COj+cHgDV331wC2feGeeWkgb3lG SbmX/wv9I+rSTSe3xkTtQL8Fe3tdtNbAaeIIeYx9AhB4c8rv+vO6GKFIXkaEdUq+ 7VoUZqykEbk= =OnAE -----END PGP SIGNATURE-----

1 0

freeradius-smbconnectserver-bo (31248) feedback
by Alan DeKok 29 Jan '07

29 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please update your database with the following vendor statement re: the FreeRADIUS SMB_Connect_Server issue. - -- Official Vendor Statement from the FreeRADIUS Server project This issue is not a security vulnerability. The exploit is available only to local administrators who have write access to the server configuration files. As such, this issue has no security impact on any system running FreeRADIUS. - -- Official Vendor Statement from the FreeRADIUS Server project The current "Description" is, in fact, nonsensical: > By sending a specially-crafted SMB request containing a malformed > Con_Handle parameter, a remote attacker could overflow a buffer and > execute arbitrary code on the system. "Con_Handle" is a data structure inside of the server, and is therefore never sent in a SMB request. The issue is not remotely exploitable, and we are curious as to how ISS arrived at the above text. The original notification did not state that the problem was remotely exploitable. We suggest the following text for the Description, Remedy, and Consequences sections: - -- Description FreeRADIUS is vulnerable to a buffer overflow, caused by improper bounds checking by the SMB_Connect_Server() function of the SMB_Handle_Type class. Local administrators can update the configuration file to overflow a buffer when the server starts. This issue cannot be exploited remotely, and can only be exploited by users who have write access to the server configuration files. - -- Description: - -- Remedy: Administrators should ensure that unauthorized users do not have write access to the server configuration files. - -- Remedy: - -- Consequences: None. - -- Consequences: This issue is not a real vulnerability, and we therefore request that you update your database to indicate that. Alan DeKok. Project Leader The FreeRADIUS Server Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb3fY6kul4vkAkl9AQJtUQQAhOLB4VO3zwNBdPKqTbdTTAA+kgFW66ew NRd1I8pZah0aUUeVCX/+fNC6E6HuWjs93oyJ/Rqi4acK/5EEVxLubMmsQnIDd9+i XFdXIsZSz+e2n8Kc1hxIcgNTnc3ZXretUeIOBxUGngcVLwmTtfGGfK/uZVjw4iHV PGOKIEeG5cQ= =TkSw -----END PGP SIGNATURE-----

1 0

Vendor statement re: CVE-2007-0080
by Alan DeKok 29 Jan '07

29 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CVE-2007-0080 was recently brought to our attention. Please find our official response below. In short, the response of 3APA3A is correct. (i.e. http://www.securityfocus.com/archive/1/455812/100/0/threaded) We believe that the correct CVSS base score metrics are as follows: http://nvd.nist.gov/cvss.cfm?name=CVE-2007-0080&vector=(AV:L/AC:L/Au:R/C:N/… The issue is NOT remotely exploitable. The attack complexity is low (editing a configuration file). Only authenticated administrators on the local machine can cause this issue. There is no confidentiality impact, as the administrator already has complete access to the local system. There is no integrity or availability impact, because exploiting the issue is done by the local administrator who runs code he is permitted to run, with a privilege level he is permitted to use. Please update the CVE listing with the above CVSS base score. For publication on the web site, our official statement is: - -- Official Vendor Statement from the FreeRADIUS Server project This issue is not a security vulnerability. The exploit is available only to local administrators who have write access to the server configuration files. As such, this issue has no security impact on any system running FreeRADIUS. - -- Official Vendor Statement from the FreeRADIUS Server project Please also update the Overview, with the following suggested text: - -- Overview A buffer overflow in the SMB_Connect_Server function in FreeRADIUS 1.1.4 and earlier allows attackers to execute arbitrary code related to the server desthost field of an SMB_Handle_Type instance. This issue can not be exploited remotely, and can only be exploited by administrators who have write access to the server configuration files. - -- Overview As additional information, the originator of the issue did not contact us for an official vendor statement, and did not respond to our attempts to discuss this issue. Our security contact is clearly available on the web site (http://freeradius.org/security.html) and includes a PGP key for authentication confidentiality. We suggest anyone who believes they find an issue in FreeRADIUS contact us before making the issue public. Alan DeKok Project Leader The FreeRADIUS Server Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb3Seakul4vkAkl9AQLH2gP/Uvi+92B5me9E/nq6tlG58RrlNfsQoRHG E6Kilk/9CACjOHRLk02dLo9eVN9kZYCZ8eOL8ki9Mfx7hRfFFWPmrWQ41w71wegO n85oOooXdH5O8gu/5siu3RlsBkHKfNo72ywMz8xJGbKHUlDcFhoZWNqZOGVIjDW6 TH/oa8nmnYo= =/Jg6 -----END PGP SIGNATURE-----

1 0

freeradius-client
by Chris Parker 28 Jan '07

28 Jan '07

Having some issues with freeradius-client. :) I've build a CDR module for FreeSwitch ( www.freeswitch.org ) that uses the radiusclient library to send accounting data. Right now, it's just sending some basic data as a proof of concept ( User-Name, Call(ed|ing)-Station, etc. ). It sends okay, but the packet is rejected by FreeRADIUS ( v1.1.3 ) with an invalid shared-secret. Here's the relevant code from the client library where it calculates the Req Authenticator: if (data->code == PW_ACCOUNTING_REQUEST) { rc_log(LOG_ERR,"DEBUG-signing accounting request\n"); total_length = rc_pack_list(data->send_pairs, secret, auth) + AUTH_HDR_LEN; auth->length = htons ((unsigned short) total_length); memset((char *) auth->vector, 0, AUTH_VECTOR_LEN); secretlen = strlen (secret); memcpy ((char *) auth + total_length, secret, secretlen); /* cparker */ rc_log(LOG_ERR,"DEBUG-code,seq %d:%d, secret %s, length %d\n", auth->code, auth->id, secret, total_length); rc_md5_calc (vector, (unsigned char *) auth, total_length + secretlen); memcpy ((char *) auth->vector, (char *) vector, AUTH_VECTOR_LEN); } This outputs: DEBUG-code,seq 4:212, secret testing123, length 204 The resulting packet ( intercepted with tcpdump ) is length 204: RADIUS, length: 204 Accounting Request (4), id: 0xd0, Authenticator: 57fe69699a09491bf38cf5e24bdd847b Accounting Status Attribute (40), length: 6, Value: Stop Username Attribute (1), length: 52, Value: starnetusa.net/ 18479630116(a)test-td1.starnetusa.net Called Station Attribute (30), length: 12, Value: 8478797989 Calling Station Attribute (31), length: 52, Value: starnetusa.net/18479630116@test-td1.starnetusa.net Accounting Session Time Attribute (46), length: 6, Value: 540:48:23 hours NAS Port Attribute (5), length: 6, Value: 0 Accounting Delay Attribute (41), length: 6, Value: 00 secs NAS IP Address Attribute (4), length: 6, Value: dev- cr1.starnetusa.net 0x0000: 4500 00e8 0001 4000 4011 773b d87e 901a E.....@.@.w;.~.. 0x0010: d87e 81b1 8030 0715 00d4 c3ae 04d0 00cc .~... 0.......... 0x0020: 57fe 6969 9a09 491b f38c f5e2 4bdd 847b W.ii..I.....K..{ 0x0030: 2806 0000 0002 2c26 6565 3265 3864 3062 (.....,&ee2e8d0b 0x0040: 2d61 3266 392d 3465 3233 2d38 3037 382d - a2f9-4e23-8078- 0x0050: 6638 3162 3731 3361 3732 6139 0134 7374 f81b713a72a9.4st 0x0060: 6172 6e65 7475 7361 2e6e 6574 2f31 3834 arnetusa.net/184 0x0070: 3739 3633 3031 3136 4074 6573 742d 7464 79630116@test-td 0x0080: 312e 7374 6172 6e65 7475 7361 2e6e 6574 1.starnetusa.net 0x0090: 1e0c 3834 3738 3739 3739 3839 1f34 7374 .. 8478797989.4st 0x00a0: 6172 6e65 7475 7361 2e6e 6574 2f31 3834 arnetusa.net/184 0x00b0: 3739 3633 3031 3136 4074 6573 742d 7464 79630116@test-td 0x00c0: 312e 7374 6172 6e65 7475 7361 2e6e 6574 1.starnetusa.net 0x00d0: 2e06 001d b517 0506 0000 0000 2906 0000 ............)... 0x00e0: 0000 0406 d87e 901a .....~.. Any ideas on what's wrong with this? -Chris -- Chris Parker Director, Engineering US LEC Corp. Internet Telephony & ISP Operations (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.

5 14

rlm_mschap support for password changes
by Garber, Neal 28 Jan '07

28 Jan '07

Samba 3.0.24 will provide support for changing passwords via ntlm_auth. Unfortunately (for rlm_mschap in FR), it is implemented using a new helper protocol, "ntlm-change-password-1", which I believe would require non-trivial changes to rlm_mschap as it doesn't currently use ntlm_auth helper protocols. Does anyone have plans to incorporate this functionality? If so, I'd be willing to help. If not, I'm going to start investigating and implementing the changes required. I'm thinking that ideally, it would be implemented in a way that doesn't break the current method of configuring ntlm_auth in radiusd.conf (i.e., it would be backward compatible to avoid requiring everyone to change the config. if they aren't interested in the new functionality). Is anyone else interested in having this capability and/or have ideas on how best to integrate it?

2 1

POD/Disconnect-Packet Port
by Peter Nixon 27 Jan '07

27 Jan '07

Hi Guys radius.h has: #define PW_POD_UDP_PORT 1700 This is great, and works for me as it is the default for Cisco brand equipment however RFC 3576 specifies port 3799. I suggest that we change this in order to be "RFC compliant" instead of "Cisco compliant" by default. Does anyone have an issue with this? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 2

rlm_python
by Peter Nixon 26 Jan '07

26 Jan '07

Hi Guys Is anyone actually using rlm_python in production? Unlike rlm_perl we don't seem to have any example code or any decent documentation. I am looking at using it myself and just looking for some feedback.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

1 0

fork and wait
by Joe Maimon 26 Jan '07

26 Jan '07

code calls rad_fork(1) (such as rad_check_ts()) This means that no entry is stored in thread_pool.waiters This means that rad_waitpid() calls reap_children() which means that subsequent calls to waitpid() -- since there is no thread_pool.waiters entry for the pid -- return an ECHILD, which leads rad_check_ts() to print this message radlog(L_ERR, "Check-TS: unknown error in waitpid()"); So basically rad_fork(1) and rad_waitpid() and waitpid() are now unreliable. Furthermore, using rad_fork(0) without rad_waitpid(pid,...,...) will eventualy result in a full thread_pool.waiters hashtable and calls to rad_fork(0) will fail. So waitpid(0,...,...) in reap_children() buys nothing except elimination of zombie processes by trading it in for causing calls of rad_fork(0) to fail. (why 0 and not -1 main waitpid..... -1 meaning wait for any child process. 0 meaning wait for any child process whose process group ID is equal to that of the calling process. ) I am getting errors forking my scripts off with rlm_exec -- apparently thread_pool.waiters is getting full somehow, since this is logged. Error: Couldn't fork /usr/local/sbin/radius-dns-update.sh: No child processes Which isnt a documented errno for fork() grep "No child" /usr/include/ -r /usr/include/asm-generic/errno-base.h:#define ECHILD 10 /* No child processes */ The fix? Here are some ideas. 1) reap_children() should only call waitpid() for entries in thread_pool.waiters -- this was the old way, should be fairly easy to revert to. This was changed due to zombies being created by creative forking in rlm_perl. I think that problem should have properly been resolved by using rad_fork() or by building its own long lived fork/wait mechanism or by properly daemonizing the child process. -- rad_fork(1)s or fork()s that are not followed by waitpid()s will result in zombies (which is a bug owned by the code doing the call to fork) IMHO this makes the most sense -- freeradius should not try to fix other code bugs by introducing all the breakage as descibed above. 2) reap_children() should create a thread_pool.waiters entry for pids that have exited for subsequent retrieval of status by rad_waitpid -- rad_fork(1)s or fork()s that are not followed by waitpid()s will result in thread_pool.waiters running out of elements. -- waitpid() is still unreliable -- rad_fork(1) is still (nearly) meaningless This can be handled by rad_fork() behaving differently, such as deleting all thread_pool.waiters elements that created by reap_children() if the thread_pool.waiters reaches its limit. This is a series of nasty kludges and workarounds for a problem that should exist in the first place. Attached find proof-of-concept patch 3) calls to rad_fork(1) should also result in creation of thread_pool.waiters element -- This doesnt completely solve anything and 2 is still needed. -- rad_fork(1) is meaningless 4) rad_fork() should mark elements in the hash table as deletable when the table is full -- after all, this is what exec_wait == 0 means, right? Perhaps to make it as correct as possible, it should only delete a percentage of the table, sorted by oldest entry. That might be hard. Why have a waiters pool anyway when calling waitpid(0 ? exec_wait == 1 processes get waited upon and their status discarded exec_wait == 0 processes get waited upon and their status kept until an explicit call to rad_waitpid() with the pid. #! /bin/sh /usr/share/dpatch/dpatch-run ## 360-rad_check_ts_waitpid.dpatch by <joe(a)nameserver3.ttec.com> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad freeradius-2.0.0~/src/main/threads.c freeradius-2.0.0/src/main/threads.c --- freeradius-2.0.0~/src/main/threads.c 2007-01-17 09:00:25.000000000 -0500 +++ freeradius-2.0.0/src/main/threads.c 2007-01-17 09:02:37.000000000 -0500 @@ -113,10 +113,12 @@ RAD_REQUEST_FUNP fun; } request_queue_t; +#define MAX_WAITERS 1024 typedef struct thread_fork_t { pid_t pid; int status; int exited; + int reaper_created; } thread_fork_t; @@ -257,10 +259,10 @@ pid_t pid; int status; thread_fork_t mytf, *tf; - - if (lrad_hash_table_num_elements(thread_pool.waiters) == 0) return; - - pthread_mutex_lock(&thread_pool.wait_mutex); + int num_waiters = lrad_hash_table_num_elements(thread_pool.waiters); + + if (!num_waiters) + return; while (1) { pid = waitpid(0, &status, WNOHANG); @@ -268,12 +270,26 @@ mytf.pid = pid; tf = lrad_hash_table_finddata(thread_pool.waiters, &mytf); - if (!tf) continue; - - tf->status = status; + if (!tf) + { + tf = rad_malloc(sizeof(*tf)); + memset(tf, 0, sizeof(*tf)); + tf->pid = pid; + tf->status = status; + tf->exited = 1; + tf->reaper_created = 1; + if (!lrad_hash_table_insert(thread_pool.waiters, tf)) + { + free(tf); + tf = NULL; + } + if (++num_waiters >= MAX_WAITERS) + break; + continue; + } tf->exited = 1; + tf->status = status; } - pthread_mutex_unlock(&thread_pool.wait_mutex); } @@ -1049,16 +1065,29 @@ /* * Thread wrapper for fork(). */ +static int reap_reaper_children(void * context, void * data) +{ + thread_fork_t *tf = data; + if (tf->reaper_created) + lrad_hash_table_delete(thread_pool.waiters, tf); + return 0; +} + pid_t rad_fork(int exec_wait) { pid_t child_pid; + int num_waiters; if (exec_wait) return fork(); reap_children(); /* be nice to non-wait thingies */ - if (lrad_hash_table_num_elements(thread_pool.waiters) >= 1024) { - return -1; + if (lrad_hash_table_num_elements(thread_pool.waiters) >= MAX_WAITERS) { + lrad_hash_table_walk(thread_pool.waiters, reap_reaper_children, NULL); + if ((num_waiters = lrad_hash_table_num_elements(thread_pool.waiters)) >= MAX_WAITERS) { + radlog(L_ERR, "too many child waiters: %d", num_waiters); + return -1; + } } /* @@ -1104,8 +1133,8 @@ pid_t rad_waitpid(pid_t pid, int *status, int options) { thread_fork_t mytf, *tf; + pid_t child_pid = 0; - reap_children(); /* be nice to non-wait thingies */ if (pid <= 0) return -1; @@ -1117,22 +1146,21 @@ tf = lrad_hash_table_finddata(thread_pool.waiters, &mytf); if (!tf) { /* not found. It's a problem... */ - pthread_mutex_unlock(&thread_pool.wait_mutex); - return waitpid(pid, status, options); + child_pid = waitpid(pid, status, options); } - - if (tf->exited) { + else if (tf->exited) { *status = tf->status; lrad_hash_table_delete(thread_pool.waiters, &mytf); - pthread_mutex_unlock(&thread_pool.wait_mutex); - return pid; + child_pid = pid; } - /* - * Don't wait, and it hasn't exited. Return. + * else { + * Don't wait, and it hasn't exited. Return 0. + * } */ + reap_children(); /* be nice to non-wait thingies */ pthread_mutex_unlock(&thread_pool.wait_mutex); - return 0; + return child_pid; } #else /* HAVE_PTHREAD_H */

2 9

Automatic report from sources (radiusd) between 24.01.2007 - 25.01.2007 GMT
by Automatic cvs log generator 25 Jan '07

25 Jan '07

CVS log entries from 24.01.2007 (Wed) 09:00:01 - 25.01.2007 (Thu) 09:00:00 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_eap/libeap/tls.c; Revisions: 1.6, 1.1.2.4 ===================================================== Log entries ===================================================== Description: Pull fix from 1.1 branch Modified files: File: radiusd/src/modules/rlm_eap/libeap/tls.c; Revision: 1.6; Date: 2007/01/24 12:38:25; Author: aland; Lines: (+11 -11) ------------------------------- Description: Fix longstanding bug where the session wasn't being properly terminated on SSL error. Instead, it continued, but set a bad pointer, causing a server crash. Modified files: File: radiusd/src/modules/rlm_eap/libeap/tls.c; Revision: 1.1.2.4; Date: 2007/01/24 12:24:49; Author: aland; Lines: (+10 -10) ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_eap/libeap/tls.c Revisions: 1.6, 1.1.2.4 Authors: aland (+11 -11), aland (+10 -10) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Automatic report from sources (radiusd) between 23.01.2007 - 24.01.2007 GMT
by Automatic cvs log generator 24 Jan '07

24 Jan '07

CVS log entries from 23.01.2007 (Tue) 09:00:00 - 24.01.2007 (Wed) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: pnixon File: radiusd/raddb/experimental.conf; Revisions: 1.35 ===================================================== Log entries ===================================================== Description: Clean up the comments a little Modified files: File: radiusd/raddb/experimental.conf; Revision: 1.35; Date: 2007/01/23 16:26:06; Author: pnixon; Lines: (+8 -8) ===================================================== Summary of modified files ===================================================== File: radiusd/raddb/experimental.conf Revisions: 1.35 Authors: pnixon (+8 -8) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0