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)
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)
On 9 Aug 2013, at 16:14, Brian Julin bju...@clarku.edu 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 a.cudba...@freeradius.org 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:27, Arran Cudbard-Bell a.cudba...@freeradius.org wrote: On 9 Aug 2013, at 16:14, Brian Julin bju...@clarku.edu 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 a.cudba...@freeradius.org 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)
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)
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)
...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 a.cudba...@freeradius.org 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)
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
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
