On 6/2/22 23:22, Damien Miller wrote: > 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. Ouch. That sucks. >>> 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. Okay, that makes sense. I hadn’t considered the possibility of an exploit against the code that interfaces between OpenSSH and the GSSAPI. A vulnerability in the GSSAPI itself would obviously be the responsibility of whoever maintains the GSSAPI implementation, not you. One option (which might be a terrible one 🙂) would be to implement GSSAPI kex support as a plugin. That would allow it to be maintained by those who are actually familiar with the code. It would also allow GSSAPI auth to be made part of the plugin, meaning that you would not need to worry about it anymore. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
