Bug 1279249 - gss_accept_sec_context fails to return an output_token in certain error cases
gss_accept_sec_context fails to return an output_token in certain error cases
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5 (Show other bugs)
6.7
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Robbie Harwood
Patrik Kis
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-08 15:52 EST by Richard Sharpe
Modified: 2016-05-10 21:01 EDT (History)
7 users (show)

See Also:
Fixed In Version: krb5-1.10.3-54.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 21:01:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A packet capture showing what should be returned (13.44 KB, application/octet-stream)
2015-11-08 16:05 EST, Richard Sharpe
no flags Details
Shows the incorrect response (25.60 KB, application/octet-stream)
2015-11-08 16:11 EST, Richard Sharpe
no flags Details
A slightly modified patch to implement a partial fix (3.84 KB, patch)
2015-11-10 16:25 EST, Richard Sharpe
no flags Details | Diff

  None (edit)
Description Richard Sharpe 2015-11-08 15:52:23 EST
Description of problem:

When the time is set back or forward and gss_accept_sec_context returns a minor code of KRB5KRB_AP_ERR_TKT_NYV or KRB5KRB_AP_ERR_TKT_EXPIRED, it should actually return a status of GSS_S_CONTINUE_NEEDED and an output token with a KRB_ERROR token in it.

However, it does not. Later versions of KRB5, like krb5-1.13.2 behave correctly.

Version-Release number of selected component (if applicable):

RHEL 6.7 with krb5-libs-1.10.3-42.el6...

How reproducible:

Run Samba, join a domain, set the time back or forward, say several days to get outside the window of validity of any ticket. Windows will keep prompting for creds because the wrong response returned by Samba but it is because gss_accept_sec_context returns the incorrect value.

Steps to Reproduce:
1. Install Samba on RHEL 6.7. Join a domain. Set the time back or forward a few days.
2. Try to connect to a share from a client that is also joined to the domain.
3. You will continually get prompted for creds. A Windows member server will return a correctly formatted response to the Session Setup that causes windows to say an Extended Error has occurred (W2K08) or to say that there are time sync problems (Windows 10).

Actual results:

Continuous prompts for creds.

Expected results:

Either an error saying there are time sync problems or that an extended error occurred.

Additional info:

I will add a capture showing the Windows behavior and a capture showing the Samba on RHEL6.7 behavior.
Comment 2 Richard Sharpe 2015-11-08 16:05 EST
Created attachment 1091426 [details]
A packet capture showing what should be returned

This capture against a Windows server shows that we should see a krb-error in the response.
Comment 3 Richard Sharpe 2015-11-08 16:11 EST
Created attachment 1091440 [details]
Shows the incorrect response

This shows the incorrect response.

This was with Samba 4.3-pre, but is caused by problems in gss_accept_sec_token which is called by source3/librpc/crypto/gse.c in Samba.

When I installed a more recent version of Kerberos (by painfully building RPMs with krb5-1.13.2) the correct response is returned.
Comment 4 Richard Sharpe 2015-11-08 19:47:26 EST
I have filed a related informational bug in the Samba bugzilla here:

https://bugzilla.samba.org/show_bug.cgi?id=11592
Comment 5 Robbie Harwood 2015-11-09 13:06:42 EST
If the time is such that the ticket is not yet valid or expired, I don't understand why we should return anything else.

Kerberos requires that clocks be synchronized to within the clock skew.  It will not work otherwise.  The way in which krb5 fails here is correct to my understanding.
Comment 6 Simo Sorce 2015-11-09 16:34:45 EST
Robbie,
GSSAPI is supposed to return an output token with some error messages,
reopening to better understand the issue.

Richard,
I found this commit upstream that I do not think ever landed in 1.10
https://github.com/krb5/krb5/commit/c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4

Would you be able to rebuild 1.10 with this patch and verify if it fixes the issue ?
Comment 7 Richard Sharpe 2015-11-10 09:39:45 EST
(In reply to Simo Sorce from comment #6)
> Robbie,
> GSSAPI is supposed to return an output token with some error messages,
> reopening to better understand the issue.
> 
> Richard,
> I found this commit upstream that I do not think ever landed in 1.10
> https://github.com/krb5/krb5/commit/c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4
> 
> Would you be able to rebuild 1.10 with this patch and verify if it fixes the
> issue ?

OK,

Give me a couple of days and I will do that.

Thanks.
Comment 8 Richard Sharpe 2015-11-10 10:46:09 EST
OK, from the look of the patch it does fix it, and seems to have been applied to 1.13.x.

I will try to apply it today and test, but it might slip a few more days.
Comment 9 Richard Sharpe 2015-11-10 16:21:38 EST
I was mistaken in one aspect of my claims above.

krb5-1.13.2 does not return GSS_C_CONTINUE_NEEDED, it still returns GSS_C_FAILURE, however, it does return a token that we can return to the client in the case of TKT_NYV or TKT_EXPIRED.
Comment 10 Richard Sharpe 2015-11-10 16:23:59 EST
I have now verified that the patch Simo mentioned works (with minor changes) for krb-1.10.3 with my modified Samba. My changes to Samba convert the status code to GSS_C_CONTINUE_NEEDED when TKT_NYV or TKT_EXPIRED are the minor code.

Attached is the patch I applied. I skipped the test program. I have not attached any SPEC file changes.
Comment 11 Richard Sharpe 2015-11-10 16:25 EST
Created attachment 1092447 [details]
A slightly modified patch to implement a partial fix

This patch causes gss_accept_sec_context to return a token in the case of an error with the ticket.

It applies to krb5-1.10.3 and is based on the one Simo mentioned up above.
Comment 12 Simo Sorce 2015-11-10 23:35:31 EST
Richard,
thanks a lot.
The patch looks good.

On the samba side, you shouldn't change the status code do GSS_C_CONTINUE_NEEDED, but rather teach it how to return tokens even when GSS_S_FAILURE is returned.


Robbie,
we'll have to carefully verify that it has no unintended side effects when backported to 1.10, we should probably ask upstream what they think about this, in case they know of other changes in later versions that will affect how this backport behaves.
Comment 13 Richard Sharpe 2015-11-10 23:38:12 EST
> On the samba side, you shouldn't change the status code do 
> GSS_C_CONTINUE_NEEDED, but rather teach it how to return tokens
> even when GSS_S_FAILURE is returned.

Yes, I was coming to that conclusion.

That is a relatively simple change, I believe.
Comment 14 Robbie Harwood 2015-11-23 12:46:12 EST
Simo has checked with upstream and this should be reasonable.
Comment 15 Patrik Kis 2016-01-12 06:46:34 EST
My understanding is that for he complete end-to-end test samba has to be modified too. Is that the case?

And also, would it be possible to backport the test part too?
Comment 17 Richard Sharpe 2016-01-12 14:41:42 EST
(In reply to Patrik Kis from comment #15)
> My understanding is that for he complete end-to-end test samba has to be
> modified too. Is that the case?
> 
> And also, would it be possible to backport the test part too?

A fix has already been committed to Samba. It might already be in the latest release.

There is no automated test, however.

This was simulated by changing the time on the Samba server after tickets have been issued.
Comment 18 Robbie Harwood 2016-01-18 15:42:57 EST
(In reply to Patrik Kis from comment #15)

> And also, would it be possible to backport the test part too?

Yes, it is.  I have backported the test (and checked its failure.).
Comment 24 errata-xmlrpc 2016-05-10 21:01:24 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0945.html

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