Merging GSSAPI kex?

[Damien Miller]

On Mon, 30 May 2022, Demi Marie Obenour wrote:

> On 5/30/22 00:03, Damien Miller wrote:
> > On Thu, 26 May 2022, Demi Marie Obenour wrote:
> > 
> >> I was thinking about the recent problems with the GSSAPI kex patch,
> >> and I wonder if it would be best to merge GSSAPI kex into OpenSSH
> >> upstream. My (admittedly dated) understanding is that the patch is
> >> of high quality, and that the concerns are instead about the GSSAPI
> >> implementation in use. However, I believe this is a non-issue for most
> >> environments where GSSAPI kex would be useful: if someone can find
> >> an RCE in the GSSAPI implementation, there are bigger problems (like
> >> compromised domain controllers).
> > 
> > The main problem is that (AFAIK) none of the maintainers suffciently
> > know kerberos/GSSAPI nor use it regularly. The last time I used it was
> > over 10 years ago and I don't even have a working test setup for it ATM.
> 
> How is GSSAPI authentication (still supported IIRC) handled?

Poorly - there is no functional testing AFAIK, only builds.

> > Additional impediments are consierable scepticism about the safety
> > of the GSSAPI implementations (e.g. none of them include fuzz tests
> > or are enrolled in oss-fuzz),
> 
> That is definitely valid.  That said, in most organizations I can
> think of that would be interested in using GSSAPI kex, the same attack
> surface can be reached in other ways.  This is trivially true in an
> Active Directory environment, for example.
> 
> > the fact that this is definitionally
> > highly sensitivew pre-auth attack surface
> 
> Would it be attack surface even when disabled?  The default should
> obviously be disabled.

Sure, but the costs to the developers should a an exploit be found are
essentially the same regardless of whether it is enabled by default or
not - we're still on the hook for analysis (of a system that we're not
familiar with), triage, potentially-urgent release and communication.

-d