Bug 3356 - sshconnect2: SSH_MSG_EXT_INFO implementation seems broken based on RFC 8308
Summary: sshconnect2: SSH_MSG_EXT_INFO implementation seems broken based on RFC 8308
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 8.8p1
Hardware: amd64 Linux
: P5 major
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-22 05:46 AEDT by Kristin Davidson
Modified: 2021-10-22 05:46 AEDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.