January 2007 - Freeradius-Devel - lists.freeradius.org

New dynamic IP pools module
by Pawel Foremski 25 Feb '07

25 Feb '07

Hi group, Here is a new FreeRADIUS module which provides dynamic IP addresses. It uses some new approaches and IMHO has greater functionality in some areas than already existing solutions. More information: http://projects.asn.pl/freemods/wiki/rlm_netvim_pools Source code (last test with v. 1.1.3): svn co http://svn.asn.pl/freemods/trunk/rlm_netvim_pool The code has been in production use since 2005, so I would consider it quite stable. BTW, I would like to submit a new vendor-specific RADIUS dictionary to the FreeRADIUS project: http://svn.asn.pl/misc/freeradius/dictionary.asn We, guys at ASN, develop a Linux distribution for network access servers - Lintrack [1] - and we use this dictionary for functionality implemented in our system. I would like to thank the FreeRADIUS development team for their great work. It's one of the best coded servers implemented in C I've ever seen (at least the core ;-)). Stay tuned for our further contributions to the project (and hey, don't miss our FreeRADIUS web interface [2])!. [1] http://www.lintrack.org/ [2] http://projects.asn.pl/ara/ Cheers, -- Pawel Foremski pjf(a)asn.pl

4 13

Bug in radclient when parsing long value from file (FreeRADIUS 1.1.3)
by Geoffroy Arnoud 07 Feb '07

07 Feb '07

Hi all, There a bug in radclient when reading a valuepair from a file, when the value is to long to be read, when written in hexadecimal. Actually, when a value can be at most 253 bytes (on the network), when expressed in hexadecimal, it requires 253x2 + 2 (0x) characters. Here is a sample request that shows the issue. NAS-IP-Address = 10.194.96.114 Framed-IP-Address = 192.168.100.69 Event-Timestamp = "Dec 18 2006 08:42:08 CET" Acct-Status-Type = Stop WISPr-Location-Name = "Something" Acct-Output-Octets = 32411 Acct-Terminate-Cause = Session-Timeout Acct-Session-Id = "00000743" NAS-Identifier = "SomethingNAS" Acct-Output-Gigawords = 0 NAS-Port-Type = Virtual User-Name = "user@company" Acct-Session-Time = 600 Acct-Input-Gigawords = 0 Class = 0x53425232434cc383c2a6c382c2b4c383efbfbdc383c2adc383c2a7c383c2acc383c5b8c383e280b9c383c2b7c3a2e2809ac2ac11c3a2e2809ac2ac3901c3a2e2809ac2ac08c3afc2bfc2bdc385c2bec3a2e282acc2bac383c2acc383c2a7c3a2e282acc593c383e280b0c383c5bec382c2be02c3a2e2809ac2ac17c3afc2bfc2bdc385e2809cc385e28099c383c2a6c3a2e282acc593c3af Acct-Input-Octets = 324352 The bug is located in file src/lib/valuepair.c in function pairread. A patch is attached that increases the size of the "value" buffer to 512 bytes. Does anyone see side effects? Best regards, Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 1

Question about rad_fork
by Garber, Neal 01 Feb '07

01 Feb '07

While reviewing rad_fork, as part of an enhancement I'm working on, I found something questionable. After the call to fork, it tests if child_pid != 0 (to see if the parent is the process executing, I presume). If true, then, the child_pid is added to the thread pool and the thread pool mutex is unlocked. However, if the fork failed, -1 is returned (and stored in child_pid), which I believe will then be added to the thread pool (because -1 != 0 and there isn't an explicit test for fork success/failure). Shouldn't there be a test for fork success (child_pid > 0) before adding to the thread pool? Perhaps this isn't a big deal because fork probably doesn't fail that often. But, it isn't clear to me what would happen in reap_children when it calls waitpid with -1 as this tells waitpid to return status for any child. Am I missing something? If not, and you want me to submit a bug report with the minor code change, let me know..

4 9

RFC 3748 compliancy
by Geoffroy Arnoud 01 Feb '07

01 Feb '07

hi all, I took a look at EAP method source code (even if crypto is not my speciality), and I'm wondering if all EAP methods shipped into freeRADIUS are compliant with RFC3748, regarding MSK and EMSK generation? This RFC states that "EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets." (§ 7.10) Which are the EAP methods that supports key derivation? And regarding other EAP methods, is there a way to add EMSK generation (maybe this is a stupid question)? I need those answers to see if FreeRADIUS would be able to act as a EAP RADIUS server compliant with WiMAX NWG stage 3. Many thanks for your answers Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 2

Acct-Status-Type block
by Peter Nixon 01 Feb '07

01 Feb '07

It just occurred to me that it would be pretty cool to be able to do: accounting { Acct-Status-Type Stop { ## Log stop packets to disk stop_log } } In the same manner as: post-auth { Post-Auth-Type REJECT { ## Log authentication rejects to disk reply_log } } Is there any way to do this at present (short of writing a custom module)? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 2

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

30 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chang, Robert wrote: > Thank you for bringing this to our attention. I'm in the process of > updating this vulnerability with the vendor statement, the updated > evaluation, and the overview. I've read the Security Focus thread, and > I understand the vector of attack is through the manipulation of a > configuration file (stored locally). Yes. > However, it seems like obtaining > additional access privileges is still possible if a normal user was > given write/complete access to the program's directory. To me, that's a misconfiguration of local file permissions, and not a vulnerability in the server. > Could you > please confirm that a local user with full access to application's > directory cannot gain root access to the machine? If a local user can > gain root access, by default, Confidentiality, Integrity, and > Availability are set to complete. If a local user can write to the config files, then *any* server available on the net is vulnerable to this attack. There's no way for a server to reliably determine that users with write permission on the files are "authorized", or "unauthorized". Since many servers can be configured to execute arbitrary programs, this "vulnerability" would appear to be common across a wide range of servers. And in any case, it has nothing whatsoever to do with the SMB buffer overflow. And users who cannot run arbitrary programs as root can still cause configuration file parse errors, and take down programs that are critical to a systems operation. > Each NVD vulnerability is based on > worst-case, so the final scoring would reflect the worst case of root > access. If this is impossible by design, then I'll be sure to update > the vulnerability accordingly. Thank you again for your help. Like many servers, FreeRADIUS permits arbitrary programs to be executed from the configuration files. Buffer overflows are unnecessary, as there are ways to configure the server to directly execute arbitrary programs. As a data point, I just tested Apache2. It is similarly "vulnerable" to the "exploit" of local file permissions, since it also is able to run as "root". If you list this as a vulnerability in FreeRADIUS, then I'm curious as to whether or not you'd accept a similar vulnerability notification for Apache2. If so, I will submit one. If not, please explain why. I'm also curious as to how the server can determine that users with write permission are not, in fact, authorized to write to the configuration files. Some minimal checking is possible, but it does not help in all circumstances, and it can likewise be bypassed by local file permission misconfigurations. Alan DeKok Project Leader The FreeRADIUS Server Project PGP key: http://freeradius.org/pgp/aland@freeradius.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRb4rKakul4vkAkl9AQL6twP9EYmIxtWKmLMM5aeGvNNgznb6D43+Nlx3 nL1yxSkFbN7bjYqKtPQ74MdDH4RaI3jYJktqOb8vqRrl3cxq/NBK67w1gC8y3tOT qqsVkjw5gHi6hYC4i79p2lVG/7SvFo2BTdAhlgkqewxNIYFcKAqdGUmjGsB+azfk 5yRQE1y+nzA= =BxuH -----END PGP SIGNATURE-----

2 1

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