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

[Andreas Oberritter]

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.

>> Because gss_release_buffer() doesn't allow any other successful return
>> value than GSS_S_COMPLETE, I decided that it would be sufficient to
>> compare with this value.
> 
> Yeah, it would probably work fine in practice.
> 
>> 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.

Regards,
Andreas