Crash with EAP-PWD #1876

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

Projects

None yet

3 participants

@pauldekkers
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)
@mcnewton
Member

Also reproducible on Debian jessie. Caused by 41d68e6.

@arr2036
Member
arr2036 commented Jan 12, 2017

Guess we actually need to pass an engine in?

@mcnewton
Member

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

@pauldekkers

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

@arr2036
Member
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

@arr2036
Member
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."

@arr2036
Member
arr2036 commented Jan 12, 2017

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

@arr2036
Member
arr2036 commented Jan 12, 2017

never mind... probably done by HMAC_CTX_new()

@mcnewton
Member

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).

@mcnewton
Member

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

@mcnewton
Member

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
@mcnewton
Member

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 mcnewton closed this Jan 12, 2017
@arr2036
Member
arr2036 commented Jan 12, 2017

Great 👍

@pauldekkers

Yes, works for me! Thanks

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