Re: [PATCH 1/2] _gsasl_gssapi_server_step: don't overwrite maj_stat

[Simon Josefsson]

Andreas Oberritter <address@hidden> writes:

> On 18.10.2011 20:04, Simon Josefsson wrote:
>> Andreas Oberritter <address@hidden> writes:
>> 
>>> Hi Simon,
>>>
>>> On 18.10.2011 15:26, Simon Josefsson wrote:
>>>> Hi Andreas.  Thank you!  The code definitely looks buggy.  I'm not
>>>> convinced this is exploitable though since GSSAPI means Kerberos V5 and
>>>> the code will in the next steps unwrap/wrap a token which will fail
>>>> unless the context hasn't been negotiated successfully.  Do you agree,
>>>> or do you have some other analysis?
>>>>
>>>> Your patch makes a direct comparison against GSS_S_COMPLETE which is
>>>> poor style in general, and using GSS_ERROR is preferred.  How about the
>>>> following patch instead?
>>>
>>> I considered your proposal before, but dismissed it, because if
>>> gss_release_buffer() fails, sasl->step would already have been
>>> incremented. I'm not sure whether this would be a problem, though.
>> 
>> No it wouldn't, if gss_release_buffer fails, the entire authentication
>> attempt will fail, and then it doesn't matter which state it is in.  Ok
>> to push revised patch?
>
> Thanks for the explanation! I'm fine with your patch.

I analysed this a bit further.  While normally a GSS-API Kerberos v5
acceptor would never return CONTINUE_NEEDED, at least MIT Kerberos V5
does in some situations (for error codes and DCE style).  However, in
none of the cases it appears that the context is established, so the
later gss_wrap and gss_unwrap that are required will fail.  So again I
don't think this has real-world security consequence, but it comes
pretty close.  Just wanted to write down my analysis somewhere for later
reference.

I have applied the patch.

>>> Btw.: I'm implementing a custom authentication mechanism on top of
>>> GSSAPI. Even though Kerberos is probably the only public user of GSSAPI,
>>> more unknown users might exist out there.
>> 
>> You really want GS2 then!  It is the generic GSS-API bridge to SASL.
>> The SASL mech GSSAPI only supports Kerberos V5. 
>
> For now, my focus was on getting our GSS mechanism to work with existing
> server software. I'm already considering moving to GS2 at a later stage,
> at the same time making the necessary changes to the server software.
>
>> If you are designing a
>> secure GSS mech and publish it as free software, I could add the
>> necessary glue to make it work via GS2 in GNU SASL.  Your mech needs to
>> support mutual authentication and channel binding.
>
> Thanks, but my project is targeted at internal users only, based on a
> custom smartcard design. A public release is unlikely to happen.
> However, if changes to GNU SASL will be required, I'll be gladly sharing
> the code, of course.

Thanks for explaining.  Code is happily accepted (larger contributions
require copyright assignment).

/Simon