Bug 3356

Summary:	sshconnect2: SSH_MSG_EXT_INFO implementation seems broken based on RFC 8308
Product:	Portable OpenSSH	Reporter:	Kristin Davidson <bugzilla+mindrot>
Component:	ssh	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	major
Priority:	P5
Version:	8.8p1
Hardware:	amd64
OS:	Linux

Description Kristin Davidson 2021-10-22 05:46:02 AEDT

Hello!

I'm currently working on an implementation of RFC 8308 for Go and was basing my implementation off of the RFC. However, when I tried to use the ssh 8.8p1 client to connect to my server implementation it considered the second SSH_MSG_EXT_INFO sent as invalid.

I looked through the openssh-portable code and found the two places where SSH_MSG_EXT_INFO is currently referenced and it seems like the code is expecting the second message in the wrong place.

The RFC says the second message may be sent "Immediately preceding the server's SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].", but it looks like "input_userauth_service_accept", where SSH_MSG_USERAUTH_SUCCESS is handled, is set to specifically consider SSH_MSG_EXT_INFO at this point an error: https://github.com/openssh/openssh-portable/blob/master/sshconnect2.c#L523

The other place where SSH_MSG_EXT_INFO is handled on the receiving end is in "ssh_userauth2", which seems to deal with SSH_MSG_SERVICE_ACCEPT: https://github.com/openssh/openssh-portable/blob/master/sshconnect2.c#L480

I'm trying to find where the discrepancy is and the RFC's definition seemed to make the most sense to me. I thought I'd check sshd's implementation to see where that was being sent but it looks like it's only sending the first message from within the kex.