Missing User-Name attribute causing a segfault in attr_rewrite

[Dennis Skinner]

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 at 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