On May 23, 2022, at 4:30 PM, Ron Frederick <ronf@xxxxxxxxxxxxx> wrote:
> On May 23, 2022, at 12:46 AM, Jakub Jelen <jjelen@xxxxxxxxxx> wrote:
>> I believe the problem here is that the call to sshpkt_getb_froms() is returning an sshbuf in server_host_key_blob which is a reference to the string being consumed from the packet being read, setting that original packet as its parent. As a result, the “ssh” buffer now has a refcount of 2, and when it returns to the top of the do {...} while and tries to read another packet into “ssh”, it gets the error about the sshbuf being “read-only” (for good reason).
>>
>> We track the gsskex patches in the following github repository:
>>
>> https://github.com/openssh-gsskex/openssh-gsskex/
>>
>> I did not read into details about that, but believe I already saw this issue and we were fixing it:
>>
>> https://github.com/openssh-gsskex/openssh-gsskex/pull/19
>>
>> Unfortunately, the repository is not completely up to date, but both Colin and Dmitry should be able to help you around here.
>
> Thanks, Jakub! I did find that Github page, but went looking for the 9.0p1 Debian patch because it seemed more up to date than the Git repo. As you mentioned, it seems like that Git repo is based on something like 8.3p1, though there is an outstanding rebase to 8.8p1 which would get it closer.
>
> The pull request you mention here is also still waiting to be integrated. I appreciate the pointer to that, though — it suggests a possible approach to handling the memory management using sshpkt_get_string() and sshbuf_from(). I’ll give it a try!
Looks like the patch in https://github.com/openssh-gsskex/openssh-gsskex/pull/19 <https://github.com/openssh-gsskex/openssh-gsskex/pull/19> applied cleanly on top of the Debian 9.0p1 patch I used, and it fixes the issue I was seeing with the KEXGSS_HOSTKEY message. I’m no longer seeing a fatal error there about a read-only buffer, and both the GSS key exchange and GSS keyex authentication appear to be working. I also tested GSS MIC authentication, and that appears to be still be working as well, both with & without GSS key exchange.
Thanks again everyone for the help!
The only remaining issue I’m seeing is around getting this patched OpenSSH to offer gssapi-keyex as an auth method when running it as a server. Even when it correctly negotiates GSS key exchange, it doesn’t offer gssapi-keyex as a valid auth method to clients, so they end up falling back to gssapi-with-mic instead. This only happens when running it as a server — if another server offers gssapi-keyex, this patched OpenSSH client has no problem completing gssapi-keyex auth. I’ll take a closer look at that next.
--
Ron Frederick
ronf@xxxxxxxxxxxxx
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
