Re: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Brian Julin wrote: > Alan DeKok wrote: > >> Well... I tried it, and I didn't see any errors. > >> Can you check that you're really running a *stock* binary, and a >> *stock* configuration? > > Attached is a recipe for how I replicated it (and another doublefree) on a > clean system. I've pushed a fix, thanks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
On 9 Aug 2013, at 16:27, Arran Cudbard-Bell wrote: > > On 9 Aug 2013, at 16:14, Brian Julin wrote: > >> >> Alan DeKok wrote: >> >>> Well... I tried it, and I didn't see any errors. >> >>> Can you check that you're really running a *stock* binary, and a >>> *stock* configuration? >> >> Attached is a recipe for how I replicated it (and another doublefree) on a >> clean system. > > With which version of the server? Never mind, release_branch_3_0_0 Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
On 9 Aug 2013, at 16:14, Brian Julin wrote: > > Alan DeKok wrote: > >> Well... I tried it, and I didn't see any errors. > >> Can you check that you're really running a *stock* binary, and a >> *stock* configuration? > > Attached is a recipe for how I replicated it (and another doublefree) on a > clean system. With which version of the server? Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Alan DeKok wrote:
> Well... I tried it, and I didn't see any errors.
> Can you check that you're really running a *stock* binary, and a
> *stock* configuration?
Attached is a recipe for how I replicated it (and another doublefree) on a
clean system.
1) started on a fresh system that had never seen freeradius before.
2) apt-get build-dep freeradius
3) apt-get install libtalloc-dev
4) git clone git://git.freeradius.org/freeradius-server
5) git branch --track release_branch_3.0.0
6) git checkout release_branch_3.0.0
7) configure --prefix=/usr/local; make; make install
8) download wpa source and build eapol_test
9) configure an eapol_peap.conf:
network={
ssid="example"
key_mgmt=WPA-EAP
eap=PEAP
identity="f...@domain.site"
anonymous_identity="a...@domain.site"
password="foo"
phase1="peaplabel=0"
phase2="auth=MSCHAPv2"
}
10) Try an auth against stock config, no memory errors as expected
11) copy proxy-inner-tunnel from sites-available to sites-enabled
12) change mods-enabled/eap peap{} to virtual_server = "proxy-inner-tunnel"
13) Run the test. Get a GCC doublefree that ends as follows:
(7) # Executing section post-proxy from file
/usr/local/etc/raddb/sites-enabled/default
(7) group post-proxy {
(7) - entering group post-proxy {...}
(7) eap : Doing post-proxy callback
(7) eap : Passing reply from proxy back into the tunnel
(7) eap : Got tunneled reply RADIUS code 11
EAP-Message = 0x010800160410ea08d4982a033fac8f7f1f0bc63b952f
Message-Authenticator = 0xbe82b369c495e2bceed47fd6f1b710d5
State = 0xc10fbed8c107ba1915db9798d8125486
Proxy-State = 0x37
(7) eap : Got tunneled Access-Challenge
(7) eap : Reply was handled
*** glibc detected *** /usr/local/sbin/radiusd: double free or corruption
(out): 0x08cb34d8 ***
15) Note that proxy-inner-tunnel.post-proxy is not being entered, scratch head
14) Note this is a different error that the talloc-detected double-use
I originally reported. To see that one proceed as follows:
16) comment out "virtual-server" option in mods-enabled/eap peap{}
17) add this clause to top of sites-enabled/default.authorize:
if (Freeradius-Proxied-To == "127.0.0.1") {
update control {
Proxy-To-Realm = "example.com"
}
}
18) Run the test. Get the talloc error originally reported:
(7) [suffix] = noop
(7) eap : Request is supposed to be proxied to Realm example.com. Not doing EAP.
(7) [eap] = noop
(7) [files] = noop
(7) [expiration] = noop
(7) [logintime] = noop
(7) [pap] = noop
} # server default
(7) eap_peap : Got tunneled reply code 0
PEAP: Tunneled authentication will be proxied to example.com
talloc: access after free error - first free may be at src/main/util.c:230
Bad talloc magic value - access after free
Aborted
18) Note that the error happens on the first unwrapped proxy before it is
sent, so decide not to worry about anything past authorize {} in the
default server.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
>>> ...and it doesn't matter that example.com defaults to home_server >> localhost, it does not get that far. >> >> Well... I tried it, and I didn't see any errors. >> >> Can you check that you're really running a *stock* binary, and a >> *stock* configuration? > > I will -- should I preferably be testing against the release git branch, or > against a release tag in master, BTW? release git branch. It contains many fixes since rc1. -Arran Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
> Alan DeKok wrote:
> Brian Julin wrote:
> > I tried to replicate on a test server with lightly modified 3.0 stock
> > configs.
> The error only
> > happens when everything is running through the same server/eap
> instances, so good
> > instincts there. Replicating it is easy: just uncomment the peap virtual-
> server directive
> > and add at the top of authorize:
> >
> > if (Freeradius-Proxied-To == "127.0.0.1") {
> > update control {
> > Proxy-To-Realm = example.com
> > }
> > }
>
> That doesn't make much sense. If it's in the "default" virtual
> server, the FreeRADIUS-Proxied-To attribute will never exist. If it's
> in the "inner-tunnel" virtual server, it will always exist, and always
> have that value.
Only if you send it there with a virtual_server="inner-tunnel" statement
in the peap block. This happens if you do not, as documented in the
comments for that option. Ah -- maybe to replicate you can't
have inner-tunnel in sites-enabled, since it has that loopback
listen directive. I had swapped in proxy-inner-tunnel at some point,
it appears, which does not have it.
> > ...and it doesn't matter that example.com defaults to home_server
> localhost, it does not get that far.
>
> Well... I tried it, and I didn't see any errors.
>
> Can you check that you're really running a *stock* binary, and a
> *stock* configuration?
I will -- should I preferably be testing against the release git branch, or
against a release tag in master, BTW?
> > I believe it is the way it is because at some point we were having trouble
> using outer.request
> > and such between virtual servers. I'll have to test those and see if that
> limitation is still
> > in effect.
>
> All that should work...
Good.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Brian Julin wrote:
> I tried to replicate on a test server with lightly modified 3.0 stock
> configs. The error only
> happens when everything is running through the same server/eap instances, so
> good
> instincts there. Replicating it is easy: just uncomment the peap
> virtual-server directive
> and add at the top of authorize:
>
> if (Freeradius-Proxied-To == "127.0.0.1") {
> update control {
> Proxy-To-Realm = example.com
> }
> }
That doesn't make much sense. If it's in the "default" virtual
server, the FreeRADIUS-Proxied-To attribute will never exist. If it's
in the "inner-tunnel" virtual server, it will always exist, and always
have that value.
> ...and it doesn't matter that example.com defaults to home_server localhost,
> it does not get that far.
Well... I tried it, and I didn't see any errors.
Can you check that you're really running a *stock* binary, and a
*stock* configuration?
> I believe it is the way it is because at some point we were having trouble
> using outer.request
> and such between virtual servers. I'll have to test those and see if that
> limitation is still
> in effect.
All that should work...
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
a.l.m.bu...@lboro.ac.uk [a.l.m.bu...@lboro.ac.uk] wrote:
> how did you configure the server...from scratch or copy pasting bits over
> from a 2.x ?
It's a mongrel, not an alteration of fresh 3.0. It was working on a pre-talloc
3.0 development branch.
> does this 'eap' module use its own virtual_server or does it inherit the
> virtual_server that
> instigated it (you have no 'virtual_server = "blah"' line in your peap{}
> section...so i assume
> its using eduroam_idp VS for the unwrapping?)
There's only one incestuous server clause, and only one EAP configuration
block, yes.
I tried to replicate on a test server with lightly modified 3.0 stock configs.
The error only
happens when everything is running through the same server/eap instances, so
good
instincts there. Replicating it is easy: just uncomment the peap
virtual-server directive
and add at the top of authorize:
if (Freeradius-Proxied-To == "127.0.0.1") {
update control {
Proxy-To-Realm = example.com
}
}
...and it doesn't matter that example.com defaults to home_server localhost, it
does not get that far.
I believe it is the way it is because at some point we were having trouble
using outer.request
and such between virtual servers. I'll have to test those and see if that
limitation is still
in effect.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Hi,
>peap {
> default_eap_type = mschapv2
> proxy_tunneled_request_as_eap = yes
> copy_request_to_tunnel = no
> use_tunneled_reply = yes
> tls = eduroam-eap-tls
>}
okay
> Any request that tries to go to the proxy causes this to happen:
> Wed Aug 7 11:57:35 2013 : Debug: (5) - entering if
> ("%{FreeRADIUS-Proxied-To}" == 127.0.0.1) {...}
> Wed Aug 7 11:57:35 2013 : Debug: (5)update control {
> Wed Aug 7 11:57:35 2013 : Debug: (5) Proxy-To-Realm := "idpi"
> Wed Aug 7 11:57:35 2013 : Debug: (5)} # update control = ok
> Wed Aug 7 11:57:35 2013 : Debug: (5) - if ("%{FreeRADIUS-Proxied-To}" ==
> 127.0.0.1) returns ok
> Wed Aug 7 11:57:35 2013 : Debug: (5)... skipping else for request 5:
> Preceding "if" was taken
> } # server eduroam_idp
> Wed Aug 7 11:57:35 2013 : Debug: (5) eap_peap : Got tunneled reply code 0
> Wed Aug 7 11:57:35 2013 : Debug: PEAP: Tunneled authentication will be
> proxied to idpi
> Wed Aug 7 11:57:35 2013 : Info: talloc: access after free error - first
> free may be at src/main/util.c:230
> Wed Aug 7 11:57:35 2013 : Info: Bad talloc magic value - access after free
this sample doesnt show enough of the process..
how did you configure the server...from scratch or copy pasting bits over from
a 2.x ?
does this 'eap' module use its own virtual_server or does it inherit the
virtual_server that
instigated it (you have no 'virtual_server = "blah"' line in your peap{}
section...so i assume
its using eduroam_idp VS for the unwrapping?)
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
I finally got around to trying some RC code (the release_branch_3.0.0 on
github) on our
production configurations, after a bit of massaging got them looking like they
were working,
but not so much the one that re-proxies the inner tunnel contents to an internal
server after unwrapping EAP-PEAP:
peap {
default_eap_type = mschapv2
proxy_tunneled_request_as_eap = yes
copy_request_to_tunnel = no
use_tunneled_reply = yes
tls = eduroam-eap-tls
}
Any request that tries to go to the proxy causes this to happen:
Wed Aug 7 11:57:35 2013 : Debug: (5) - entering if
("%{FreeRADIUS-Proxied-To}" == 127.0.0.1) {...}
Wed Aug 7 11:57:35 2013 : Debug: (5)update control {
Wed Aug 7 11:57:35 2013 : Debug: (5) Proxy-To-Realm := "idpi"
...
Wed Aug 7 11:57:35 2013 : Debug: (5)} # update control = ok
Wed Aug 7 11:57:35 2013 : Debug: (5) - if ("%{FreeRADIUS-Proxied-To}" ==
127.0.0.1) returns ok
Wed Aug 7 11:57:35 2013 : Debug: (5)... skipping else for request 5:
Preceding "if" was taken
} # server eduroam_idp
Wed Aug 7 11:57:35 2013 : Debug: (5) eap_peap : Got tunneled reply code 0
Wed Aug 7 11:57:35 2013 : Debug: PEAP: Tunneled authentication will be
proxied to idpi
Wed Aug 7 11:57:35 2013 : Info: talloc: access after free error - first free
may be at src/main/util.c:230
Wed Aug 7 11:57:35 2013 : Info: Bad talloc magic value - access after free
... I don't know if this is of any use, being so far removed from the free():
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x75eb4700 (LWP 27579)]
0x003fe54328a5 in raise () from /lib64/libc.so.6
...
(gdb) bt
#0 0x003fe54328a5 in raise () from /lib64/libc.so.6
#1 0x003fe5434085 in abort () from /lib64/libc.so.6
#2 0x77782c3c in ?? () from /usr/lib64/libtalloc.so.2
#3 0x77782dd8 in talloc_get_name () from /usr/lib64/libtalloc.so.2
#4 0x777857eb in _talloc_get_type_abort ()
from /usr/lib64/libtalloc.so.2
#5 0x77bb4d95 in pairnext (cursor=0x75eb2950)
at src/lib/valuepair.c:290
#6 0x77bb4b42 in pairfind (vp=0x7fffe8007d80, attr=80, vendor=0,
tag=-128 '\200') at src/lib/valuepair.c:209
#7 0x76f58d45 in mod_authenticate (instance=0x7f8b30,
request=0x844e40) at src/modules/rlm_eap/rlm_eap.c:360
#8 0x00421812 in call_modsingle (component=0, sp=0x81ce30,
request=0x844e40) at src/main/modcall.c:311
#9 0x00422f93 in modcall (component=0, c=0x81cf30, request=0x844e40)
at src/main/modcall.c:782
#10 0x0041f4c6 in indexed_modcall (comp=0, idx=6, request=0x844e40)
at src/main/modules.c:758
#11 0x00421127 in process_authenticate (auth_type=6, request=0x844e40)
at src/main/modules.c:1648
#12 0x0040c910 in rad_check_password (request=0x844e40)
at src/main/auth.c:252
#13 0x0040cee4 in rad_authenticate (request=0x844e40)
---Type to continue, or q to quit---
at src/main/auth.c:490
#14 0x00430b79 in request_running (request=0x844e40, action=1)
at src/main/process.c:1185
#15 0x0042d02e in request_handler_thread (arg=0x8397c0)
at src/main/threads.c:685
#16 0x003fe5c07851 in start_thread () from /lib64/libpthread.so.0
#17 0x003fe54e811d in clone () from /lib64/libc.so.6
(gdb)
(gdb) up
#1 0x003fe5434085 in abort () from /lib64/libc.so.6
(gdb) up
#2 0x77782c3c in ?? () from /usr/lib64/libtalloc.so.2
(gdb) up
#3 0x77782dd8 in talloc_get_name () from /usr/lib64/libtalloc.so.2
(gdb) up
#4 0x777857eb in _talloc_get_type_abort ()
from /usr/lib64/libtalloc.so.2
(gdb) up
#5 0x77bb4d95 in pairnext (cursor=0x75eb2950)
at src/lib/valuepair.c:290
290 VERIFY_VP(cursor->current);
(gdb) list
285*/
286VALUE_PAIR *pairnext(vp_cursor_t *cursor)
287{
288 cursor->current = cursor->next;
289 if (cursor->current) {
290 VERIFY_VP(cursor->current);
291
292 /*
293 * Set this now in case 'current' gets freed before
294 * pairnext is called again.
(gdb) print cursor->current
$1 = (VALUE_PAIR *) 0x7fffe8007820
(gdb) print cursor->current->da
$2 = (const DICT_ATTR *) 0x6c6c617420646142
(gdb) print *cursor->current->da
Cannot access memory at address 0x6c6c617420646142
(gdb) up
#6 0x77bb4b42 in pairfind (vp=0x7fffe8007d80, attr=80, vendor=0,
tag=-128 '\200') at src/lib/valuepair.c:209
209 i = pairnext(&cursor)) {
(gdb) list
204 vp_cursor_t cursor;
205 VALUE_PAIR *i;
206
207 for (i = paircursor(&cursor, &vp);
208 i;
209 i = pairnext(&cursor)) {
210 VERIFY_VP(i);
211 if ((i->da->attr == attr) && (i->da->vendor == vendor)
212 && ((tag == TAG_ANY) || (i->da->flags.has_tag &&
213 (i->tag == tag {
(gdb) print attr
$3 = 80
(gdb) print vendor
$4 = 0
(gdb) print tag
$5 =
