GSSAPI security context integrity check
alexandr.nedvedicky at oracle.com
Fri Jun 26 04:10:26 EDT 2020
I owe an answer here. Just hit delete if you don't care. To keep story short:
the bug was hiding at Solaris specific code, which deals with GSS security
context export/import. It was sitting there for 4 years or so waiting to be
It looks like SAP software has one dedicated server, which performs
authentication. As soon as client is authenticated the security
context is exported and passed to another (worker) process, which
There are two GSS kerberos mechanisms in Solaris:
- MIT one (native)
- kernel one (Solairs). Think of it like it's MIT 12 years ago
bent enough to work in Solaris kernel.
There is a Solaris specific change to native kerberos, which deals with
incompatibility between Solaris and MIT, when it comes to sequence number
checking. The Solaris kernel mechanism still uses sequence number tracking as
implemented in src/lib/gssapi/generic/util_ordering.c, which MIT dropped
in 1.14 in favor of src/lib/gssapi/generic/util_seqstate.c.
Once issue was understood the fix is straightforward. The export/import
process must serialize security context such it will be compatible with kernel
mechanism (turn seqstate to order). And vice-versa import process must turn
order to seqstate. End of story.
On Fri, Jun 12, 2020 at 08:13:59AM +0200, Alexandr Nedvedicky wrote:
> just to let you know about the progress of the things...
> it looks like issue specific to Solaris at the moment.
> > > The two filenames had the same suffix (c523660). If I understand
> > > correctly, that is the pointer value of the krb5 GSS context object--so
> > > both g_seqstate_init() calls were for the same context (which is
> > > consistent with the initial sequence numbers being the same). It would
> > > be very interesting to know the stack traces of the two
> > > g_seqstate_init() calls, although that might be difficult to collect
> > > remotely. Normally there should only be one g_seqstate_init() call for
> > > a context, from kg_accept_krb5().
> > I'll ask customer to collect the stack with dtrace. After spending couple
> > days browsing through source code the g_seqstate_init() gets only called
> > when new security context is born (import, accept or init).
> > Assuming I interpret the log from SAPware right, we run as GSS acceptor,
> > so g_seqstate_init() is being called from kg_accept_krb5() in
> > lib/gssapi/krb5/accept_sec_context.c.
> > yes, that's a good idea to try to collect stack trace using dtrace.
> we've got a dtrace output, which shows security context export/import
> is involved. I suspect there are multiple SAP processes. One of them
> accepts security context, exports it and passes to worker process, which
> imports it. I've noticed there is a Solaris specific diff, which deals
> context serialization. Therefore I think the issue might be specific to
> Solaris. I'll send pull request in case the investigation will reveal
> it's bug in MIT kerberos.
> thanks and
> krbdev mailing list krbdev at mit.edu
More information about the krbdev