segfault in master 3.0.x checking for empty realm
Ran into an interesting issue with my realm code that should have just given me a reject rather than a segfault. In my default site I have added to the end the realm: realm "~.*$" { } So that suffix matches every realm as I don't have control over the realm names and need to perform lookups in the database on the realm. But if I then try and run suffix with an empty realm and do if check to see if it's not a particular realm I get a segfault. suffix if ( Realm == "testing" ) { reject } or if ( &Realm == "testing" ) { reject } or if ( "%{Realm}" == "testing" ) { reject } I always get the segfault. (0) Received Access-Request Id 46 from 127.0.0.1:34518 to 127.0.0.1:1812 length 256 (0) User-Password = "1234" (0) User-Name = "user" (0) # Executing section authorize from file ./sites-enabled/default ... (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "user", looking up realm NULL (0) suffix: Found realm "~.*$" (0) suffix: Adding Stripped-User-Name = "user" (0) suffix: Adding Realm = "(null)" (0) suffix: Authentication realm is LOCAL (0) [suffix] = ok (0) if ( Realm == "testing" ) { Segmentation fault That's a bit nasty response really. Granted it's not exactly elegant that I am doing the lookup in the first place. But I didn't expect a segfault from that. I've worked around it by doing a check to make sure the realm isn't empty first. if ( !&Realm == "" ) { if ( Realm == "testing" ) { reject } } else { reject } And that drops into the else nicely (0) if ( !&Realm == "" ) { (0) if ( !&Realm == "" ) -> FALSE (0) else { (0) [reject] = reject (0) } # else = reject (0) } # authorize = reject Haven't gone looking into the code to see where the issue is yet, but I will have a look tomorrow.
On Mar 4, 2016, at 11:34 AM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Ran into an interesting issue with my realm code that should have just given me a reject rather than a segfault.
In my default site I have added to the end the realm:
realm "~.*$" { }
You don't need that. The DEFAULT realm already does that.
So that suffix matches every realm as I don't have control over the realm names and need to perform lookups in the database on the realm.
But if I then try and run suffix with an empty realm and do if check to see if it's not a particular realm I get a segfault.
I've pushed a fix. Alan DeKok.
On Sat, Mar 5, 2016 at 8:17 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 4, 2016, at 11:34 AM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Ran into an interesting issue with my realm code that should have just given me a reject rather than a segfault.
In my default site I have added to the end the realm:
realm "~.*$" { }
You don't need that. The DEFAULT realm already does that.
But the default realm doesn't set the Realm VSA to the value passed in the request after the @ or whatever we are splitting the realm on. If there is nothing in the realm I get: (0) Received Access-Request Id 159 from 127.0.0.1:47635 to 127.0.0.1:1812 length 264 (0) User-Password = "1234" (0) User-Name = "user@testing" (0) # Executing section authorize from file ./sites-enabled/default (0) suffix: Checking for suffix after "@" (0) suffix: Looking up realm "testing" for User-Name = "user@testing" (0) suffix: No such realm "testing" (0) [suffix] = noop Or if I have the realm "DEFAULT" realm DEFAULT { } Then I get. (0) suffix: Checking for suffix after "@" (0) suffix: Looking up realm "testing" for User-Name = "user@testing" (0) suffix: Found realm "DEFAULT" (0) suffix: Adding Stripped-User-Name = "user" (0) suffix: Adding Realm = "DEFAULT" (0) suffix: Authentication realm is LOCAL (0) [suffix] = ok ... (0) perl: $RAD_REQUEST{'Realm'} = &request:Realm -> 'DEFAULT' Whereas when I have realm "~.*$" realm "~.*$" { } I get the realm passed in the request into the Realm VSA. (0) suffix: Checking for suffix after "@" (0) suffix: Looking up realm "testing" for User-Name = "user@testing" (0) suffix: Found realm "~.*$" (0) suffix: Adding Stripped-User-Name = "user" (0) suffix: Adding Realm = "testing" (0) suffix: Authentication realm is LOCAL (0) [suffix] = ok ... (0) perl: $RAD_REQUEST{'Realm'} = &request:Realm -> 'testing' So then I can do some logic based on the realm passed and lookup which realm I want to use. As the proxy.conf has realm value such as "CryptServer1" as the realm name, and I do a lookup based on the realm passed in the request "crypt.co.nz" and do an update control Proxy-To-Realm CryptServer1. So I use the suffix module to do the split of the User-Name rather than complex regex. And make decisions on which realm to Proxy to (or not Proxy) based on data in the database. I get a Proxy-To-Realm in the response from suffix then someone is doing something very untoward using a suffix on the request that actually does match to a realm in the proxy file. Which should never happen as the realms in the proxy.conf are something like "ServerName1-bignumber" so if a user uses "user@ServerName1-bignumber" then they are trying to hack knowing some internal only information or do something untoward so I just reject those requests.
So that suffix matches every realm as I don't have control over the realm
names and need to perform lookups in the database on the realm.
But if I then try and run suffix with an empty realm and do if check to see if it's not a particular realm I get a segfault.
I've pushed a fix.
Brilliant, I'll have a go with it later on this afternoon.
On Mar 4, 2016, at 3:59 PM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
But the default realm doesn't set the Realm VSA to the value passed in the request after the @ or whatever we are splitting the realm on.
Ah, OK.
... So then I can do some logic based on the realm passed and lookup which realm I want to use.
That makes sense. Alan DeKok.
participants (2)
-
Alan DeKok -
Peter Lambrechtsen