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. -d
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?> 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 surfaceWould it be attack surface even when disabled? The default should obviously be disabled.> 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.-- Sincerely, Demi Marie Obenour (she/her/hers) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB288B55FFF9C22C1.asc Type: application/pgp-keys Size: 4885 bytes Desc: OpenPGP public key URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220530/50191356/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220530/50191356/attachment.asc>
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