Bug 1395288 - Krb5 using futex breaks GSSAPI key exchange in OpenSSH
Summary: Krb5 using futex breaks GSSAPI key exchange in OpenSSH
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-15 15:55 UTC by Jakub Jelen
Modified: 2017-01-06 20:21 UTC (History)
11 users (show)

Fixed In Version: openssh-7.2p2-14.fc24 openssh-7.3p1-6.fc25 openssh-7.4p1-1.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-06 20:21:42 UTC
Type: Bug


Attachments (Terms of Use)

Description Jakub Jelen 2016-11-15 15:55:32 UTC
Description of problem:
Some of the recent version of krb5 brought the usage of threads and futexes in the function gss_indicate_mechs() which breaks GSSAPI key exchange with seccomp filter enabled.

We call  gss_indicate_mechs()  in the privsep child (limited by seccomp filter), but system call futex() is not in our current whitelist in this limited environment. 

Does this function really need to fully initialize krb5, threads and futexes? Do the futexes need to succeed? Is it considered safe to call this method from such limited process?

If it is expected change, feel free to reassign back on me for to openssh. I can either whitelist futex() syscall, if it is safe, or we can move this call back to the privileged monitor process.

Version-Release number of selected component (if applicable):
krb5-devel-1.14.4-4.fc24.x86_64
openssh-7.3p1-3.fc26.x86_64

How reproducible:
deterministic

Steps to Reproduce:
1. Set up GSSAPI authentication and GSSAPI key exchange in OpenSSH with explicit algorithm (eg. gss-group1-sha1-)
2. Try to connect to this server using the same algorithm

Actual results:
The connection fails (exit code 255), server reports failed privsep child.

Expected results:
The connection works.

Additional info:
Thread 2.1 "sshd" received signal SIGSYS, Bad system call.
#0  0x00007ffff3c6b340 in __pthread_once_slow () from /lib64/libpthread.so.0
#1  0x00007ffff384e6c9 in krb5int_pthread_loaded () from /lib64/libkrb5support.so.0
#2  0x00007ffff5e113a9 in gssint_mechglue_initialize_library () from /lib64/libgssapi_krb5.so.2
#3  0x00007ffff5e114ec in gss_indicate_mechs () from /lib64/libgssapi_krb5.so.2
#4  0x000000000042d125 in ssh_gssapi_supported_oids (oidset=oidset@entry=0x7fffffffd920)
    at gss-serv.c:180
#5  0x000000000042d25c in ssh_gssapi_server_mechanisms () at gss-serv.c:151
#6  0x000000000040c111 in do_ssh2_kex () at sshd.c:2833
#7  main (ac=<optimized out>, av=<optimized out>) at sshd.c:2420

Comment 1 Robbie Harwood 2016-11-15 17:36:00 UTC
(In reply to Jakub Jelen from comment #0)
> Description of problem:
> Some of the recent version of krb5 brought the usage of threads and futexes
> in the function gss_indicate_mechs() which breaks GSSAPI key exchange with
> seccomp filter enabled.
> 
> We call  gss_indicate_mechs()  in the privsep child (limited by seccomp
> filter), but system call futex() is not in our current whitelist in this
> limited environment. 
> 
> Does this function really need to fully initialize krb5, threads and
> futexes? Do the futexes need to succeed? Is it considered safe to call this
> method from such limited process?
>
> If it is expected change, feel free to reassign back on me for to openssh. I
> can either whitelist futex() syscall, if it is safe, or we can move this
> call back to the privileged monitor process.

futex() is widely considered a safe syscall, and is used for synchronization.  I don't see why one would want it blocked.

Please note that we are not calling this function directly; it is being called as part of (setting up) pthreads.  To my knowledge, calling into libpthread here is not new, so if futex() is an issue for some reason of which I'm not aware, the pthread (libc) people would be better to ask than me if it needs changed.

Almost every call into GSSAPI needs to have GSSAPI fully initialized in order to know what mechanisms are available (because they're configurable at runtime).  This means that it needs to initialize the krb5 mechanism, which is what you're seeing here.

Hope that helps!

Comment 2 Fedora Update System 2016-11-16 13:10:27 UTC
openssh-7.3p1-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e

Comment 3 Fedora Update System 2016-11-16 13:10:40 UTC
openssh-7.3p1-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e

Comment 4 Fedora Update System 2016-11-16 13:32:34 UTC
openssh-7.2p2-14.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-48f5186dfb

Comment 5 Jakub Jelen 2016-11-16 13:38:45 UTC
OK. Thank you. I added the exception to the seccomp filter.

Comment 6 Fedora Update System 2016-11-16 20:24:04 UTC
openssh-7.3p1-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6d0ee59e4e

Comment 7 Fedora Update System 2016-11-17 03:58:02 UTC
openssh-7.2p2-14.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-48f5186dfb

Comment 8 Fedora Update System 2016-11-19 17:25:31 UTC
openssh-7.2p2-14.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2016-11-19 21:13:08 UTC
openssh-7.3p1-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 Colin Watson 2016-12-28 20:07:30 UTC
I think this is probably the wrong fix, given the changes in response to https://bugzilla.mindrot.org/show_bug.cgi?id=2107.  Consider this patch instead (sorry, split into multiple links for reasons, but should be clear enough):

  https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/diff/gss-serv.c?id=31ed1f715e4c1dd986c32b8c5e6687c185258db9
  https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/diff/sshd.c?id=31ed1f715e4c1dd986c32b8c5e6687c185258db9

Comment 11 Jakub Jelen 2016-12-31 11:42:50 UTC
Thank you Colin for a notice. Your fix looks much better (does not open more switches in the seccomp). I still miss some connections in the gssapi code.

I will fix that after I will be done with rebase.

Comment 12 Fedora Update System 2017-01-03 14:50:51 UTC
openssh-7.4p1-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4767e2991d

Comment 13 Fedora Update System 2017-01-03 22:21:55 UTC
openssh-7.4p1-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4767e2991d

Comment 14 Fedora Update System 2017-01-06 20:21:42 UTC
openssh-7.4p1-1.fc25 has been pushed to the Fedora 25 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.