Re: freeradius 0.8.1 crash with EAP-TLS bad packets

2003-04-04 Thread Alan DeKok
Frank Higgens <[EMAIL PROTECTED]> wrote:
> Here is some more information that might help. The 
> EAP-TLS packet that is received is poorly formated.
> After the normal EAP header, the EAP-TLS packet
> only contains the flags '0xC0' and then the packet
> ends. Since the 'length included' flag is set in the
> flags portion, the packet should contain another 4
> bytes of data.

  OK... does the EAP header (length field) say that the 4 bytes are
*not* in the packet?

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: freeradius 0.8.1 crash with EAP-TLS bad packets

2003-04-04 Thread Frank Higgens

Alan,

Here is some more information that might help. The 
EAP-TLS packet that is received is poorly formated.
After the normal EAP header, the EAP-TLS packet
only contains the flags '0xC0' and then the packet
ends. Since the 'length included' flag is set in the
flags portion, the packet should contain another 4
bytes of data. I believe this is the root of the
problem. The eap_tls decoding does not catch this
decoding problem and you end up with a corrupt tls
packet. The data_len used for the memcpy is bogus.

#1  0x400cbda4 in eaptls_extract (eap_ds=0x42142084,
status=135215584) at eap_tls.c:474
474 memcpy(tlspacket->data, data, data_len);
(gdb) p /x data_len
$6 = 0x42142084
(gdb) p /x *tlspacket
$7 = {code = 0x28, id = 0xa8, length = 0x80ba820,
flags = 0x38, data = 0x80b8060, dlen = 0xbfffdae8}
(gdb) p data
$8 = (uint8_t *) 0x400c4618 "rlm_eap: processing type
%s"
(gdb) 



Alan DeKok wrote:
> 
> Frank Higgens <[EMAIL PROTECTED]> wrote:
> > I am running some EAP-TLS tests against our AP
using
> > freeradius 0.8.1 as the authentication server.
> >
> > I ran into a crash running a EAP DoS attack that
sent
> > a EAP TLS packet with flags 'c0' and with no TLS
> > message length or TLS message data. The tests are
> > part of qacafe's cdrouter test suite.
> 
>   Ok... do you have the values of the variables in
the core dump?
> 
>   Knowing where it core dumped is nice, but to fix
it, we need to
> know what it received, and why it did something
wrong.
> 
> > #0  0x4207c46c in memcpy () from
/lib/i686/libc.so.6
> > #1  0x400cbda4 in eaptls_extract
(eap_ds=0x4213158c,
> > status=135226888) at eap_tls.c:474
> 
>   So something goes wrong in memcpy, but since we
don't have the
> arguments to memcpy, or the internal variables in
eaptls_extract(),
> it's difficult to know how to fix the problem.
> 
>   Alan DeKok.

__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: freeradius 0.8.1 crash with EAP-TLS bad packets

2003-04-02 Thread Alan DeKok
Frank Higgens <[EMAIL PROTECTED]> wrote:
> I am running some EAP-TLS tests against our AP using 
> freeradius 0.8.1 as the authentication server.
> 
> I ran into a crash running a EAP DoS attack that sent
> a EAP TLS packet with flags 'c0' and with no TLS
> message length or TLS message data. The tests are 
> part of qacafe's cdrouter test suite.

  Ok... do you have the values of the variables in the core dump?

  Knowing where it core dumped is nice, but to fix it, we need to
know what it received, and why it did something wrong.

> #0  0x4207c46c in memcpy () from /lib/i686/libc.so.6
> #1  0x400cbda4 in eaptls_extract (eap_ds=0x4213158c,
> status=135226888) at eap_tls.c:474

  So something goes wrong in memcpy, but since we don't have the
arguments to memcpy, or the internal variables in eaptls_extract(),
it's difficult to know how to fix the problem.

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


freeradius 0.8.1 crash with EAP-TLS bad packets

2003-04-02 Thread Frank Higgens

MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


I am running some EAP-TLS tests against our AP using 
freeradius 0.8.1 as the authentication server.

I ran into a crash running a EAP DoS attack that sent
a EAP TLS packet with flags 'c0' and with no TLS
message length or TLS message data. The tests are 
part of qacafe's cdrouter test suite.

modcall: group authorize returns updated
  rad_check_password:  Found Auth-Type EAP
auth: type "EAP"
modcall: entering group authenticate
rlm_eap: Request found, released from the list
rlm_eap: EAP_TYPE - tls
rlm_eap: processing type tls
rlm_eap_tls:  More Fragments with length included

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 19876)]
0x4207c46c in memcpy () from /lib/i686/libc.so.6
(gdb) where
#0  0x4207c46c in memcpy () from /lib/i686/libc.so.6
#1  0x400cbda4 in eaptls_extract (eap_ds=0x4213158c,
status=135226888) at eap_tls.c:474
#2  0x400cb66b in eaptls_authenticate (arg=0x80c32b0,
handler=0x80f6608) at rlm_eap_tls.c:198
#3  0x400c2f30 in eaptype_call (eap_type=13,
action=INITIATE, type_list=0x80b9e30,
handler=0x80f6608)
at eap.c:205
#4  0x400c3063 in eaptype_select (type_list=0x80b9e30,
handler=0x80f6608, conftype=0x80b8060 "tls")
at eap.c:280
#5  0x400c29f8 in eap_authenticate
(instance=0x80c5910, request=0x80f5878) at
rlm_eap.c:200


Frank.


__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html