GSSAPI security context integrity check

[Alexandr Nedvedicky]

Hello,

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
discovered.

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
imports it.

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.

thanks and
regards
sasha

On Fri, Jun 12, 2020 at 08:13:59AM +0200, Alexandr Nedvedicky wrote:
> Hello,
> 
> just to let you know about the progress of the things...
> it looks like issue specific to Solaris at the moment.
> 
> </snip>
> > > 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
> regard
> sashan
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev