Bug 1058025

Summary: [REGRESSION] update to 0.3.0 causes ssh to crash
Product: [Fedora] Fedora Reporter: Stefan Becker <chemobejk>
Component: gssntlmsspAssignee: Simo Sorce <ssorce>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dwmw2, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gssntlmssp-0.3.1-0.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-27 13:11:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed fix
none
Tested fix none

Description Stefan Becker 2014-01-26 14:08:59 UTC
Description of problem:

After updating my machine to the latest F20 packages, ssh crashes during authentication handshake. Here the tail of "ssh -vvv somehost":

 debug3: remaining preferred: publickey,keyboard-interactive,password
 debug3: authmethod_is_enabled gssapi-with-mic
 debug1: Next authentication method: gssapi-with-mic
 debug1: Unspecified GSS failure.  Minor code may provide more information
 Cannot determine realm for numeric host address

 debug1: Unspecified GSS failure.  Minor code may provide more information
 Cannot determine realm for numeric host address

 debug1: Unspecified GSS failure.  Minor code may provide more information
 debug1: Unspecified GSS failure.  Minor code may provide more information
 Cannot determine realm for numeric host address

 Segmentation fault


Version-Release number of selected component (if applicable):
openssh-6.4p1-3.fc20.x86_64        (updated: Wed Dec 18 16:07:33 2013)
gssntlmssp-0.3.0-0.fc20.x86_64    (updated: Sun Jan 26 14:47:00 2014)
krb5-libs-1.11.3-38.fc20.x86_64     (updated: Sun Jan 26 14:40:46 2014)

How reproducible:
always

Steps to Reproduce:
1. ssh somehost
2.
3.

Actual results:
ssh crashes with SIGSEGV

Expected results:
no crash :-)

Additional info:

Machine:

Linux stefanb-lnx.NVIDIA.COM 3.12.8-300.fc20.x86_64 #1 SMP Thu Jan 16 01:07:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux


GDB backtrace:

Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
ntlm_free_ctx (ctx=ctx@entry=0x5555557f54f0) at src/ntlm.c:196
196         ret = iconv_close((*ctx)->from_oem);
(gdb) bt
#0  ntlm_free_ctx (ctx=ctx@entry=0x5555557f54f0) at src/ntlm.c:196
#1  0x00007ffff322a78f in gssntlm_delete_sec_context (
    minor_status=0x7fffffffb230,
    context_handle=context_handle@entry=0x7fffffffb198,
    output_token=output_token@entry=0x0) at src/gss_sec_ctx.c:632
#2  0x00007ffff322aa94 in gssntlm_init_sec_context (
    minor_status=0x5555557f2df4, claimant_cred_handle=<optimized out>,
    context_handle=0x5555557f5718, target_name=<optimized out>,
    mech_type=<optimized out>, req_flags=<optimized out>, time_req=0,
    input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0,
    output_token=0x7fffffffb4b0, ret_flags=0x0, time_rec=0x0)
    at src/gss_sec_ctx.c:600
#3  0x00007ffff62b231b in gss_init_sec_context ()
   from /lib64/libgssapi_krb5.so.2
#4  0x000055555559c750 in ssh_gssapi_init_ctx ()
#5  0x000055555559ca35 in ssh_gssapi_check_mechanism ()
#6  0x000055555556d7bf in userauth_gssapi ()
#7  0x000055555556fa09 in userauth ()
#8  0x0000555555593bae in dispatch_run ()
#9  0x000055555556f6ab in ssh_userauth2 ()
#10 0x000055555556b2bd in ssh_login ()
#11 0x000055555555f5c5 in main ()

If I comment out gssntlmssp_v1 in /etc/gss/mech, the crash disappears.

If I downgrade to gssntlmssp-0.2.0-0.fc20.x86_64, the crash disappears.

Comment 1 Simo Sorce 2014-01-26 18:51:57 UTC
Created attachment 855752 [details]
Proposed fix

I think the attached patch should fix the issue.
Do you think you can test it ?

Comment 2 Simo Sorce 2014-01-26 19:05:40 UTC
Btw I have builds in this copr repo:
http://copr.fedoraproject.org/coprs/simo/gssntlmssp/

the build with the patch applied is called gssntlmssp-0.3.0-0fix1 and is availble for i386/x86_64 for F19/F20/rawhide

Comment 3 Stefan Becker 2014-01-26 19:16:44 UTC
(In reply to Simo Sorce from comment #1)
> I think the attached patch should fix the issue.

Nope, still crashes. It seems that the value (*ctx) is invalid:

 Program received signal SIGSEGV, Segmentation fault.
 ntlm_free_ctx (ctx=ctx@entry=0x5555557f54b0) at src/ntlm.c:196
 196         if ((*ctx)->from_oem) {
 (gdb) l
 191     {
 192         int ret;
 193
 194         if (!ctx || !*ctx) return 0;
 195
 196         if ((*ctx)->from_oem) {
 197             ret = iconv_close((*ctx)->from_oem);
 198             if (ret) goto done;
 199         }

 (gdb) break src/ntlm.c:194
 Breakpoint 1 at 0x7ffff2e1e509: file src/ntlm.c, line 194.

 (gdb) run
 Starting program: /usr/bin/ssh somehost
 [Thread debugging using libthread_db enabled]

 Breakpoint 1, ntlm_free_ctx (ctx=ctx@entry=0x5555557f54b0) at src/ntlm.c:194
 194         if (!ctx || !*ctx) return 0;

 (gdb) print ctx
 $1 = (struct ntlm_ctx **) 0x5555557f54b0

 (gdb) print *ctx
 $2 = (struct ntlm_ctx *) 0x6e61

 (gdb) print (*ctx)->from_oem
 Cannot access memory at address 0x6e61

Comment 4 Simo Sorce 2014-01-26 20:19:22 UTC
Created attachment 855772 [details]
Tested fix

Ok I was able to reproduce on my machine, and this new patch fixes it for me.
I've spinned a new copr build too, it's named fix2, if you can confirm I will make a new release upstream and build new official packages for Fedora.

Comment 5 Stefan Becker 2014-01-26 20:43:47 UTC
Yep, the latest patch fixes the problem.

Comment 6 Fedora Update System 2014-01-26 21:20:02 UTC
gssntlmssp-0.3.1-0.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gssntlmssp-0.3.1-0.fc20

Comment 7 Simo Sorce 2014-01-26 21:22:53 UTC
Please provide karma so it can go quickly to stable

Comment 8 Fedora Update System 2014-01-27 13:11:35 UTC
gssntlmssp-0.3.1-0.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Stefan Becker 2014-01-28 07:41:56 UTC
This got pushed faster to stable than it arrived at my updates-testing mirror. I've updated to the new version and the problem disappeared.