Crash with EAP-PWD #1876

Closed
pauldekkers opened this Issue Jan 12, 2017 · 14 comments

Comments

Projects
None yet
3 participants

pauldekkers commented Jan 12, 2017 edited

Issue type

  • Defect - Crash or memory corruption.

Defect/Feature description

EAP-PWD crashes FreeRADIUS (tested on CentOS 6, CentOS 7 and Ubuntu 16.04)

How to reproduce issue

Compiled FreeRADIUS 3.0.x (git, 3.0.13 at time of writing) with:
./configure --prefix=/home/centos/freeradius --enable-developer

Crash both experienced with ldap and files module for accounts.

Minimal FreeRADIUS config is

  • a user in raddb/mods-config/files/authorize
    paul Cleartext-Password := "testing123"
  • eap_pwd enabled in raddb/mods-enabled/eap

eapol_test file:

network={
        key_mgmt=IEEE8021X
	eap=PWD
        identity="paul"
        password="testing123"
        }

Output of [radiusd|freeradius] -X showing issue occurring

Full backtrace from LLDB or GDB

Backtrace:

(gdb) run -X
Starting program: /home/centos/freeradius/sbin/radiusd -X
[...]
(2) files: users: Matched entry paul at line 1
(2)     [files] = ok
(2)     [expiration] = noop
(2)     [logintime] = noop
(2) pap: No User-Password attribute in the request.  Cannot do PAP
(2)     [pap] = noop
(2)   } # authorize = ok
(2) eap_pwd: } # server inner-tunnel
(2) eap_pwd: Got tunneled reply code 0

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff745b79d in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libpcap-1.4.0-4.20130826git2dbcaa1.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libtalloc-2.1.5-1.el6_7.x86_64 nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x00007ffff745b79d in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10
#1  0x00007ffff744dd7b in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10
#2  0x00007ffff73dc762 in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10
#3  0x00007ffff0a65ce8 in H_Init (ctx=0x7fffffffc3e0) at src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.c:48
#4  0x00007ffff0a66438 in compute_password_element (session=0x96c9b0, grp_num=19, password=0x96ec50 "testing123", password_len=10, id_server=0x91c610 "theserver@example.com",
    id_server_len=21, id_peer=0x96c9bb "\rpaul", id_peer_len=4, token=0x96c9b8) at src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.c:193
#5  0x00007ffef0a6532c in ?? ()
#6  0x000000000096c9bb in ?? ()
#7  0x0000000000000004 in ?? ()
#8  0x000000000096c9b8 in ?? ()
#9  0x00007fffffff0065 in ?? ()
#10 0x00007fffffffc610 in ?? ()
#11 0x000000000096c9b8 in ?? ()
#12 0x0000000000958ae0 in ?? ()
#13 0x000000000091c580 in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) quit

On Ubuntu 16.04

(2) pap: No User-Password attribute in the request.  Cannot do PAP
(2)     [pap] = noop
(2)   } # authorize = ok
(2) eap_pwd: } # server inner-tunnel
(2) eap_pwd: Got tunneled reply code 0

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7612137 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(gdb) bt
#0  0x00007ffff7612137 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1  0x00007ffff76122c9 in ENGINE_finish () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007ffff7624bff in EVP_DigestInit_ex () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3  0x00007ffff758f695 in HMAC_Init_ex () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#4  0x00007ffff27bef99 in H_Init (ctx=0x7fffffffc580) at src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.c:48
#5  0x00007ffff27bf7ec in compute_password_element (session=0x967450, grp_num=19, password=0x969190 "testing123", password_len=10, id_server=0x918780 "theserver@example.com",
    id_server_len=21, id_peer=0x96745c "paul", id_peer_len=4, token=0x967458) at src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.c:193
#6  0x00007ffff27be55b in mod_process (arg=0x9186f0, handler=0x964b80) at src/modules/rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c:480
#7  0x00007ffff5a480dd in eap_module_call (module=0x917fb0, handler=0x964b80) at src/modules/rlm_eap/eap.c:194
#8  0x00007ffff5a48abf in eap_method_select (inst=0x8f2b20, handler=0x964b80) at src/modules/rlm_eap/eap.c:457
#9  0x00007ffff5a46d29 in mod_authenticate (instance=0x8f2b20, request=0x967a20) at src/modules/rlm_eap/rlm_eap.c:286
#10 0x000000000042b037 in call_modsingle (component=MOD_AUTHENTICATE, sp=0x946dd0, request=0x967a20) at src/main/modcall.c:302
#11 0x000000000042b788 in modcall_recurse (request=0x967a20, component=MOD_AUTHENTICATE, depth=1, entry=0x7fffffffd758, do_next_sibling=true) at src/main/modcall.c:578
#12 0x000000000042b1ff in modcall_child (request=0x967a20, component=MOD_AUTHENTICATE, depth=1, entry=0x7fffffffd740, c=0x946dd0, result=0x7fffffffd0d0, do_next_sibling=true)
    at src/main/modcall.c:408
#13 0x000000000042c277 in modcall_recurse (request=0x967a20, component=MOD_AUTHENTICATE, depth=0, entry=0x7fffffffd740, do_next_sibling=true) at src/main/modcall.c:789
#14 0x000000000042d0e9 in modcall (component=MOD_AUTHENTICATE, c=0x946cd0, request=0x967a20) at src/main/modcall.c:1134
#15 0x000000000042854a in indexed_modcall (comp=MOD_AUTHENTICATE, idx=160731, request=0x967a20) at src/main/modules.c:1028
#16 0x000000000042a927 in process_authenticate (auth_type=160731, request=0x967a20) at src/main/modules.c:2168
#17 0x000000000040f78f in rad_check_password (request=0x967a20) at src/main/auth.c:252
#18 0x00000000004101ad in rad_authenticate (request=0x967a20) at src/main/auth.c:571
#19 0x00000000004407b6 in request_running (request=0x967a20, action=1) at src/main/process.c:1527
#20 0x000000000043f4a9 in request_queue_or_run (request=0x967a20, process=0x440654 <request_running>) at src/main/process.c:1015
#21 0x0000000000441048 in request_receive (ctx=0x9677c0, listener=0x95f820, packet=0x967820, client=0x8560d0, fun=0x40fc0f <rad_authenticate>) at src/main/process.c:1783
#22 0x000000000041948f in auth_socket_recv (listener=0x95f820) at src/main/listen.c:1571
#23 0x0000000000448776 in event_socket_handler (xel=0x8e9f40, fd=8, ctx=0x95f820) at src/main/process.c:4585
#24 0x00007ffff79803f0 in fr_event_loop (el=0x8e9f40) at src/lib/event.c:649
#25 0x000000000044a73b in radius_event_process () at src/main/process.c:5658
#26 0x0000000000433c13 in main (argc=2, argv=0x7fffffffe678) at src/main/radiusd.c:585
(gdb)
Member

mcnewton commented Jan 12, 2017

Also reproducible on Debian jessie. Caused by 41d68e6.

Owner

arr2036 commented Jan 12, 2017

Guess we actually need to pass an engine in?

Member

mcnewton commented Jan 12, 2017

That's what it looks like. Maybe it depends on OpenSSL version...

Right, reverting the 41d68e6 change resolves this indeed on 3.0.x

Owner

arr2036 commented Jan 12, 2017 edited

Weirdly on the master branch and 1.0.0 stable HMAC_Init is just a wrapper (which passes NULL as the engine)... https://github.com/openssl/openssl/blob/c42a78cb57cd335f3e2b224d4d8c8d7c2ecfaa44/crypto/hmac/hmac.c#L83

Owner

arr2036 commented Jan 12, 2017

rather cryptic note from openssl docs

"HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the function evp_md and key key. Either can be NULL , in which case the existing one will be reused. HMAC_CTX_init() must have been called before the first use of an HMAC_CTX in this function. N.B. HMAC_Init() had this undocumented behaviour in previous versions of OpenSSL - failure to switch to HMAC_Init_ex() in programs that expect it will cause them to stop working."

Owner

arr2036 commented Jan 12, 2017

yeah we're missing the appropriate call to HMAC_CTX_init before the call to HMAC_Init_ex

Owner

arr2036 commented Jan 12, 2017

never mind... probably done by HMAC_CTX_new()

Member

mcnewton commented Jan 12, 2017

Tried that - doesn't fix it. And it seems to depend on OpenSSL version - HMAC_CTX_init for 1.0.0 and HMAC_CTX_reset for 1.1.0.

Not 1.1.0 here - maybe it works with HMAC_Init_ex(..., NULL) on 1.1.0, but needs the non _ex version prior to that (no matter what their docs say).

Member

mcnewton commented Jan 12, 2017

Oh, actually, no - it crashes further on... so that's probably correct.

Member

mcnewton commented Jan 12, 2017

Got it. There's another HMAC_Init_ex futher down that needs the same treatment. I'll sort a patch.

@mcnewton mcnewton added a commit to mcnewton/freeradius-server that referenced this issue Jan 12, 2017

@mcnewton mcnewton rlm_eap_pwd: initialise HMAC context
Closes #1876
d014b8b
Member

mcnewton commented Jan 12, 2017

Yeah - it's fine on v4.0.x, as you say guess it's due to the HMAC_CTX_new().

@mcnewton mcnewton added a commit that referenced this issue Jan 12, 2017

@mcnewton mcnewton rlm_eap_pwd: initialise HMAC context
Closes #1876
a28b2a4

mcnewton closed this Jan 12, 2017

Owner

arr2036 commented Jan 12, 2017

Great 👍

Yes, works for me! Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment