Merging GSSAPI kex?

[Demi Marie Obenour]

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)
-------------- 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/20220603/8f2afcf1/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/20220603/8f2afcf1/attachment.asc>