RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1279249 - gss_accept_sec_context fails to return an output_token in certain error cases
Summary: gss_accept_sec_context fails to return an output_token in certain error cases
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5
Version: 6.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-08 20:52 UTC by Richard Sharpe
Modified: 2016-05-11 01:01 UTC (History)
7 users (show)

Fixed In Version: krb5-1.10.3-54.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-11 01:01:24 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0945 0 normal SHIPPED_LIVE krb5 bug fix and enhancement update 2016-05-10 22:55:41 UTC

Description Richard Sharpe 2015-11-08 20:52:23 UTC 
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 21:05:00 UTC 
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 21:11:22 UTC 
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-09 00:47:26 UTC 
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 18:06:42 UTC 
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 21:34:45 UTC 
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 14:39:45 UTC 
(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 15:46:09 UTC 
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 21:21:38 UTC 
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 21:23:59 UTC 
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 21:25:52 UTC 
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-11 04:35:31 UTC 
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-11 04:38:12 UTC 
> 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 17:46:12 UTC 
Simo has checked with upstream and this should be reasonable.
Comment 15 Patrik Kis 2016-01-12 11:46:34 UTC 
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 19:41:42 UTC 
(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 20:42:57 UTC 
(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-11 01:01:24 UTC 
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.