Bug 827858 - Segfault during EAP
Summary: Segfault during EAP
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freeradius
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: John Dennis
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-03 10:29 UTC by Thomas Jansen
Modified: 2012-08-14 21:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-14 21:57:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Output of radiusd -X (57.36 KB, text/plain)
2012-06-03 17:22 UTC, Thomas Jansen
no flags Details

Description Thomas Jansen 2012-06-03 10:29:23 UTC
Radiusd (freeradius-2.1.12-5.fc17.x86_64) segfaults due to NULL-pointer dereference during EAP. This is reproducable every time.

The following backtrace reveals, that the pointer s->s3 is NULL but dereferenced in a memcpy in eap_tls_gen_mppe_keys(). It is preceded by the stdout output prior to the segfault in gdb.

[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
[peap] eaptls_verify returned 7
[peap] Done initial handshake
[peap] eaptls_process returned 7
[peap] EAPTLS_OK
[peap] Session established.  Decoding tunneled attributes.
[peap] Peap state send tlv success
[peap] Received EAP-TLV response.
[peap] Success

Program received signal SIGSEGV, Segmentation fault.
eaptls_gen_mppe_keys (reply_vps=0x5555559682c0, s=0x555555947aa0, prf_label=0x7ffff1470bb7 "client EAP encryption")
    at mppe_keys.c:140
140             memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE);
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-29.fc17.x86_64 keyutils-libs-1.5.5-2.fc17.x86_64 krb5-libs-1.10-6.fc17.x86_64 libcom_err-1.42-4.fc17.x86_64 libgcc-4.7.0-5.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 nspr-4.9-2.fc17.x86_64 nss-3.13.4-3.fc17.x86_64 nss-mdns-0.10-10.fc17.x86_64 nss-softokn-freebl-3.13.4-2.fc17.x86_64 nss-util-3.13.4-2.fc17.x86_64 openldap-2.4.30-2.fc17.x86_64 sssd-client-1.8.3-11.fc17.x86_64 zlib-1.2.5-6.fc17.x86_64
(gdb) bt
#0  eaptls_gen_mppe_keys (reply_vps=0x5555559682c0, s=0x555555947aa0, prf_label=0x7ffff1470bb7 "client EAP encryption")
    at mppe_keys.c:140
#1  0x00007ffff1c82f6c in eaptls_success (handler=0x555555947040, peap_flag=0) at eap_tls.c:202
#2  0x00007ffff1e8bfec in eaptype_call (atype=0x55555592a590, handler=handler@entry=0x555555947040) at eap.c:175
#3  0x00007ffff1e8c3c1 in eaptype_select (inst=inst@entry=0x5555559085e0, handler=handler@entry=0x555555947040) at eap.c:409
#4  0x00007ffff1e8b619 in eap_authenticate (instance=0x5555559085e0, request=0x555555968100) at rlm_eap.c:327
#5  0x0000555555573f05 in call_modsingle (request=0x555555968100, component=0, sp=<optimized out>) at modcall.c:297
#6  modcall (component=component@entry=0, c=c@entry=0x555555923740, request=request@entry=0x555555968100) at modcall.c:670
#7  0x0000555555572699 in indexed_modcall (comp=comp@entry=0, idx=idx@entry=6, request=request@entry=0x555555968100)
    at modules.c:737
#8  0x0000555555572fcc in module_authenticate (auth_type=auth_type@entry=6, request=request@entry=0x555555968100)
    at modules.c:1587
#9  0x0000555555561e17 in rad_check_password (request=0x555555968100) at auth.c:382
#10 rad_authenticate (request=0x555555968100) at auth.c:665
#11 0x00005555555800a5 in radius_handle_request (request=request@entry=0x555555968100, fun=0x5555555615c0 <rad_authenticate>)
    at event.c:3780
#12 0x00005555555789d8 in thread_pool_addrequest (request=0x555555968100, fun=0x5555555615c0 <rad_authenticate>)
    at threads.c:886
#13 0x000055555557dae6 in event_socket_handler (xel=<optimized out>, fd=<optimized out>, ctx=<optimized out>) at event.c:3425
#14 0x00007ffff7bd1e4a in fr_event_loop (el=0x555555934500) at event.c:415
#15 0x0000555555580041 in radius_event_process () at event.c:3766
#16 0x0000555555560b5c in main (argc=<optimized out>, argv=<optimized out>) at radiusd.c:408
(gdb) p s
$1 = (SSL *) 0x555555947aa0
(gdb) p s->s3
$2 = (struct ssl3_state_st *) 0x0
(gdb) print s
$3 = (SSL *) 0x555555947aa0
(gdb) print *s
$4 = {version = 769, type = 8192, method = 0x7ffff7125780, rbio = 0x555555958450, wbio = 0x5555559584d0, bbio = 0x0,
  rwstate = 1, in_handshake = 0, handshake_func = 0x7ffff6eece80 <ssl3_accept>, server = 1, new_session = 0, renegotiate = 0,
  quiet_shutdown = 0, shutdown = 3, state = 240, rstate = 0, init_buf = 0x55555595caa4, init_msg = 0x0,
  init_num = 1435862355, init_off = 21845, packet = 0x0, packet_length = 0, s2 = 0x555555947df0, s3 = 0x0, d1 = 0x0,
  read_ahead = -238540368, msg_callback = 0x5555559482a0, msg_callback_arg = 0x0, hit = 1435751120, param = 0x0,
  cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 1435942752, enc_read_ctx = 0x55555593c840, read_hash = 0x0,
  expand = 0x55555596c600, enc_write_ctx = 0x55555596c6b0, write_hash = 0x0, compress = 0x555555947d10, cert = 0x0,
  sid_ctx_length = 0, sid_ctx = '\000' <repeats 28 times>"\240, \205\226U", session = 0x0, generate_session_id = 0,
  verify_mode = -247006736, verify_callback = 0x7ffff1c82730 <cbtls_info>, info_callback = 0, error = 1435750352,
  error_code = 21845, psk_client_callback = 0, psk_server_callback = 0, ctx = 0x555555922f50, debug = 0, verify_result = 0,
  ex_data = {sk = 0x55555593d630, dummy = 0}, client_CA = 0x0, references = 1, options = 51398660, mode = 0,
  max_cert_list = 102400, first_packet = 0, client_version = 769, max_send_fragment = 16384, tlsext_debug_cb = 0,
  tlsext_debug_arg = 0x0, tlsext_hostname = 0x0, servername_done = 0, tlsext_status_type = -1, tlsext_status_expected = 0,
  tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts = 0x0, tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1,
  tlsext_ticket_expected = 0, tlsext_opaque_prf_input = 0x0, tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0,
  tls_session_ticket_ext_cb = 0, tls_session_ticket_ext_cb_arg = 0x0, tls_session_secret_cb = 0,
  tls_session_secret_cb_arg = 0x0, initial_ctx = 0x555555922f50, next_proto_negotiated = 0x0,
  next_proto_negotiated_len = 225 '\341', srtp_profiles = 0x555555947d60, srtp_profile = 0x1, tlsext_heartbeat = 281,
  tlsext_hb_pending = 0, tlsext_hb_seq = 165}

Comment 1 John Dennis 2012-06-03 13:53:03 UTC
Thank you for your bug report. Since you say this is reproducible I'd appreciate if you could provide the reproducer and/or the *full* debug output of radiusd when running the reproducer.

To get debug output do this as root:

stop the existing daemon via

systemctl stop radiusd.service

Then run the server in debug mode:

/sbin/radiusd -X 

The reproducer is important because many people run EAP successfully so there must be something specific to your installation.

Comment 2 Thomas Jansen 2012-06-03 17:22:20 UTC
Created attachment 588899 [details]
Output of radiusd -X

Comment 3 Thomas Jansen 2012-06-03 17:43:15 UTC
The attachment above contains the debug output, where I replaced my passwords with XXX.

What exactly is meant by 'reproducer'? Perhaps I'll just give you a general picture of what I'm trying to do (and successfully did until I upgraded to F17). 

I use radiusd on a virtual machine for authentication in my WiFi network. It uses an LDAP backend that stores usernames and passwords. If I try to connect my phone or my laptop to the WiFi network, either device fails to establish a connection and radiusd segfaults. Reproducable in this context means that every time I try to connect either device to the network radiusd segfaults.

I did not change my config during the upgrade from F16 to F17 and /etc/raddb does not contain any *.rpmnew files. I'm by no means a freeradius expert, so it might be config-related. The same config however used to work fine under the latest freeradius in F16 though.

Comment 4 Thomas Jansen 2012-06-07 08:28:44 UTC
Manual downgrading to freeradius-2.1.12-3.fc16.x86_64 and freeradius-ldap-2.1.12-3.fc16.x86_64 on a F17 system is a viable workaround. This version does not segfault.

Comment 5 Łukasz Trąbiński 2012-07-10 12:31:55 UTC
Hi

We have the same problem, after upgrade to FC17 after a few minutes we got:


Jul 10 13:02:25 see-you-later kernel: [ 1765.775309] radiusd[1070]: segfault at c0 ip b70ed6f2 sp b589f1b0 error 4 in libfreeradius-eap-2.1.12.so[b70e8000+9000]
Jul 10 13:36:37 see-you-later kernel: [ 3818.239572] radiusd[2230]: segfault at c0 ip b70026f2 sp b57b41b0 error 4 in libfreeradius-eap-2.1.12.so[b6ffd000+9000]
Jul 10 13:36:59 see-you-later kernel: [ 3839.694793] radiusd[2253]: segfault at c0 ip b706d6f2 sp b68211b0 error 4 in libfreeradius-eap-2.1.12.so[b7068000+9000]
Jul 10 14:00:10 see-you-later kernel: [ 5230.510892] radiusd[2281]: segfault at c0 ip b705d6f2 sp b580f1b0 error 4 in libfreeradius-eap-2.1.12.so[b7058000+9000]


[root@see-you-later log]# rpm -q freeradius
freeradius-2.1.12-5.fc17.i686

Comment 6 John Dennis 2012-08-09 16:25:55 UTC
Alan DeKok (FreeRADIUS author) responded on the freeradius-users list with this comment in reference to this bug. I will do a rebuild and push.

  This is typically caused by having discordant versions of OpenSSL
installed.  i.e. the server was built using version X, and the current
OpenSSL library is version Y.

  There's really no solution, other than to re-build && re-link the
server.  I can put some hacks in, but all they'll do is ensure that the
server doesn't crash.  It WON'T cause authentication to work.

Comment 7 Fedora Update System 2012-08-09 17:13:42 UTC
freeradius-2.1.12-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/freeradius-2.1.12-6.fc17

Comment 8 John Dennis 2012-08-09 17:28:15 UTC
freeradius-2.1.12-6.fc17 has been submitted to updates-testing, it may take a day before it appears in the repos. Please test this and see if it resolves your problems. If not please let me know the version of openssl you're running.

Comment 9 Thomas Jansen 2012-08-09 21:32:28 UTC
This fixes the problem for me. The following versions were used in the quick test I just did:

> rpm -q openssl freeradius
openssl-1.0.0j-2.fc17.x86_64
freeradius-2.1.12-6.fc17.x86_64

Thanks for your effort.

Comment 10 John Dennis 2012-08-09 21:54:32 UTC
Thank you for testing Thomas. Since this worked for you would you please click on this link and give it a positive karma vote, that will speed it's inclusion into the stable repos.

https://admin.fedoraproject.org/updates/freeradius-2.1.12-6.fc17?_csrf_token=dad239723f63730a64a20b6fc5d2a52d33a3df8b

Comment 11 Łukasz Trąbiński 2012-08-10 07:58:13 UTC
For me freeradius-2.1.12-6.fc17.i686 also works without any problems and stable. Thank You.

Comment 12 Fedora Update System 2012-08-10 22:29:27 UTC
Package freeradius-2.1.12-6.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing freeradius-2.1.12-6.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11708/freeradius-2.1.12-6.fc17
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2012-08-14 21:57:21 UTC
freeradius-2.1.12-6.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.