Missing User-Name attribute causing a segfault in attr_rewrite
Hello, I finally got around to upgrading our RADIUS servers to FR 1.1.1. Everything is working well except we seem to have a customer somewhere who is able to attempt to auth without sending a User-Name attribute and a blank User-Password. I'm not sure at this point if it is an attempted exploit or just a badly coded client. Here is an attempt: --- Walking the entire request list --- Cleaning up request 1 ID 88 with timestamp 44512aa3 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:21674, id=218, length=203 Framed-Protocol = PPP User-Password = "" Calling-Station-Id = "##########" Called-Station-Id = "##########" NAS-Port-Type = Async Cisco-NAS-Port = "Async172" NAS-Port = 172 Connect-Info = "28800/26400 V34+/V44/LAPM (53333/26400)" Cisco-AVPair = "v92-info=V.92 QC MOH/QC Full Train Success/0/0" Service-Type = Framed-User NAS-IP-Address = xxx.xxx.xxx.xxx Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 rlm_realm: Proxy reply, or no User-Name. Ignoring. modcall[authorize]: module "suffix" returns noop for request 2 rlm_attr_rewrite: Could not find value pair for attribute Realm modcall[authorize]: module "fix_realm" returns noop for request 2 The very next line is the segfault. Here is my "fix_realm" module: attr_rewrite fix_realm { attribute = Realm searchin = packet searchfor = "blue.*$$" replacewith = "bluefrog.com" ignore_case = yes new_attribute = no max_matches = 1 append = no } (we used to use both bluefrognet.net and bluefrog.biz, so this attempts to normalize everyone since the username in the db is always user@bluefrog.com) I think the fact that there is no realm may be causing the segfault. Unfortunately, I have no idea how to recreate the situation myself and I have yet to try to track down the customer. I didn't see this problem listed on bugs.freeradius.org and don't recall seeing mention of it on the list. The other thing I changed in the authorize section of the config file is that I moved the suffix (and fix_realm) higher in the list (as you can probably tell from the debug output). Here is my authorize section: authorize { suffix fix_realm preprocess chap mschap eap files redundant { # slave first sql2 sql1 handled } } My old config wasn't using huntgroups, so I didn't need to fix_realm before preprocessing. I need to do that now, hence suffix and fix_realm are at the top. I will continue to dig at this problem from my end, but I thought maybe Alan or someone could modify radclient to send a packet like above and see if they can recreate the bug (or better yet, have a look at the code and go, "oh yeah, that is why that happened"). My C coding skills have all but rusted solid at this point. Let me know if you need any more information. Thanks! -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com
Dennis Skinner <dskinner@bluefrog.com> wrote:
rlm_attr_rewrite: Could not find value pair for attribute Realm modcall[authorize]: module "fix_realm" returns noop for request 2
The very next line is the segfault.
Then the problem isn't the "fix_realm" module. It's already returned.
The other thing I changed in the authorize section of the config file is that I moved the suffix (and fix_realm) higher in the list (as you can probably tell from the debug output). Here is my authorize section:
authorize { suffix fix_realm preprocess
I think that's the issue. The "preprocess" module is probably dying.
rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:21674, id=218, length=203 Framed-Protocol = PPP User-Password = "" Calling-Station-Id = "##########" Called-Station-Id = "##########" NAS-Port-Type = Async Cisco-NAS-Port = "Async172" NAS-Port = 172 Connect-Info = "28800/26400 V34+/V44/LAPM (53333/26400)" Cisco-AVPair = "v92-info=V.92 QC MOH/QC Full Train Success/0/0" Service-Type = Framed-User NAS-IP-Address = xxx.xxx.xxx.xxx
There's no User-Name in the request. That's wrong, but it shouldn't cause the server to die. When I test it with the above packet, it works for me. So I'm not sure what's going wrong. If you can get a core file, doc/bugs should help. Alan DeKok.
Alan DeKok wrote:
Then the problem isn't the "fix_realm" module. It's already returned.
Ah. Makes sense.
There's no User-Name in the request. That's wrong, but it shouldn't cause the server to die.
My thoughts exactly.
When I test it with the above packet, it works for me. So I'm not sure what's going wrong. If you can get a core file, doc/bugs should help.
I'll see what I can come up with. Thanks, Alan! -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com
Alan DeKok wrote:
When I test it with the above packet, it works for me. So I'm not sure what's going wrong. If you can get a core file, doc/bugs should help.
Here is the backtrace: (gdb) bt #0 0x4207a703 in strlen () from /lib/tls/libc.so.6 #1 0x420477ed in vfprintf () from /lib/tls/libc.so.6 #2 0x4206a284 in vsnprintf () from /lib/tls/libc.so.6 #3 0x0805029d in vradlog (lvl=1108548116, fmt=0x400e2820 "No huntgroup access: [%s] (%s)", ap=0xbfffcf08 "<") at log.c:132 #4 0x08050485 in radlog (lvl=2, msg=0x400e2820 "No huntgroup access: [%s] (%s)") at log.c:217 #5 0x400e24f7 in preprocess_authorize (instance=0x0, request=0x8161638) at rlm_preprocess.c:550 #6 0x0805304e in call_modsingle (component=1, sp=0x812a798, request=0x8161638, default_result=6) at modcall.c:236 #7 0x080534e0 in modcall (component=1, c=0x812a798, request=0x8161638) at modcall.c:564 #8 0x080530f2 in call_one (component=1, p=0x812a798, request=0x8161638, priority=0xbfffd3f4, result=0xbfffd3f8) at modcall.c:269 #9 0x080531a0 in call_modgroup (component=1, g=0x3c, request=0x8161638, default_result=6) at modcall.c:324 #10 0x08053551 in modcall (component=1, c=0x8129a00, request=0x8161638) at modcall.c:549 #11 0x08052d34 in module_authorize (autz_type=0, request=0x3c) at modules.c:893 #12 0x0804ca42 in rad_authenticate (request=0x8161638) at auth.c:589 #13 0x08055fc5 in rad_respond (request=0x8161638, fun=0x804c960 <rad_authenticate>) at radiusd.c:1642 #14 0x08055ba9 in main (argc=135665208, argv=0x804c960) at radiusd.c:1427 #15 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 Let me know if you need any other information. Thanks! -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com
Any luck with this, Alan? Need any other info from me? Should I open a bug report in bugzilla? Since I sent this, I have updated the system via fedoralegacy (this machine is redhat9) and recompiled. Still segfaults. Going to play with the order of the items in radiusd.conf and see what I can see. Thanks! Dennis Skinner wrote:
Here is the backtrace:
(gdb) bt #0 0x4207a703 in strlen () from /lib/tls/libc.so.6 #1 0x420477ed in vfprintf () from /lib/tls/libc.so.6 #2 0x4206a284 in vsnprintf () from /lib/tls/libc.so.6 #3 0x0805029d in vradlog (lvl=1108548116, fmt=0x400e2820 "No huntgroup access: [%s] (%s)", ap=0xbfffcf08 "<") at log.c:132 #4 0x08050485 in radlog (lvl=2, msg=0x400e2820 "No huntgroup access: [%s] (%s)") at log.c:217 #5 0x400e24f7 in preprocess_authorize (instance=0x0, request=0x8161638) at rlm_preprocess.c:550 #6 0x0805304e in call_modsingle (component=1, sp=0x812a798, request=0x8161638, default_result=6) at modcall.c:236 #7 0x080534e0 in modcall (component=1, c=0x812a798, request=0x8161638) at modcall.c:564 #8 0x080530f2 in call_one (component=1, p=0x812a798, request=0x8161638, priority=0xbfffd3f4, result=0xbfffd3f8) at modcall.c:269 #9 0x080531a0 in call_modgroup (component=1, g=0x3c, request=0x8161638, default_result=6) at modcall.c:324 #10 0x08053551 in modcall (component=1, c=0x8129a00, request=0x8161638) at modcall.c:549 #11 0x08052d34 in module_authorize (autz_type=0, request=0x3c) at modules.c:893 #12 0x0804ca42 in rad_authenticate (request=0x8161638) at auth.c:589 #13 0x08055fc5 in rad_respond (request=0x8161638, fun=0x804c960 <rad_authenticate>) at radiusd.c:1642 #14 0x08055ba9 in main (argc=135665208, argv=0x804c960) at radiusd.c:1427 #15 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
Let me know if you need any other information. Thanks!
-- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com
Dennis Skinner <dskinner@bluefrog.com> wrote:
Any luck with this, Alan? Need any other info from me? Should I open a bug report in bugzilla?
Try the following:
#5 0x400e24f7 in preprocess_authorize (instance=0x0, request=0x8161638) at rlm_preprocess.c:550
That line in rlm_preprocess.c looks at request->username->strvalue. Try editing the radlog() to "if (request->username) radlog(...". Re-build & install. Maybe that will help. Alan DeKok.
Quoting Alan DeKok <aland@nitros9.org>:
Dennis Skinner <dskinner@bluefrog.com> wrote:
Any luck with this, Alan? Need any other info from me? Should I open a bug report in bugzilla?
Try the following:
#5 0x400e24f7 in preprocess_authorize (instance=0x0, request=0x8161638) at rlm_preprocess.c:550
That line in rlm_preprocess.c looks at request->username->strvalue. Try editing the radlog() to "if (request->username) radlog(...".
Re-build & install. Maybe that will help.
That seems to have done it. I recompiled and ran that change on our secondary and when the primary received a bad packet and died, the secondary then got one and kept going. I put the modified version on the primary and it seems to be working well so far. I've seen a couple of these in the log now: Fri May 5 18:50:44 2006 : Error: rlm_sql (sql2): zero length username not permitted Fri May 5 18:50:44 2006 : Auth: Invalid user: [<no User-Name attribute>/] (from client xxxxx port 108 cli xxxxxxxxxx) I included the "return r;" inside the new if statement. Not sure if that is correct. Maybe the request->username should be &&'ed to the outer if? Thanks, Alan! Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com ------------------------------------------------------ This message was sent using BlueFrog's Webmail System http://www.bluefrog.com
participants (3)
-
Alan DeKok -
Dennis Skinner -
dskinner＠bluefrog.com