Merging GSSAPI kex?
djm at mindrot.org
Mon May 30 14:03:07 AEST 2022
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.
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), the fact that this is definitionally
highly sensitivew pre-auth attack surface and an upstream that removed
Kerberos/GSSAPI from its base OS some years ago,
Not speaking for any of the other developers, but I don't see any
appetite or path to getting it merged.
That's not to say that the situation couldn't be improved for those who
want it. IMO getting a github project with the patches applied that
is kept up to date and with a real set of regression tests would be a
significant improvement over the status quo.
More information about the openssh-unix-dev