openssh unix dev - Apr 2015 - OpenSSH 6.6.x sends invalid SSH_MSG_USERAUTH_INFO_REQUEST

I've had a report from a user that "SSH-2.0-OpenSSH_6.6.1_hpn13v11
FreeBSD-20140420" is sending an invalid SSH_MSG_USERAUTH_INFO_REQUEST.
Checking against the server in question, it first sends a valid request
(empty name, empty instruction, empty language, single prompt for a 
password):

  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................
  00 00 00 28 50 61 73 73 77 6f 72 64 20 66 6f 72  ...(Password for
  [...]

to which I reply with a SSH_MSG_USERAUTH_INFO_RESPONSE.  The server then sends
a second SSH_MSG_USERAUTH_INFO_REQUEST consisting of 16 bytes of zeros:

  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

for which, even if you ignore the fact that it fails a data-validity check,
I'm not sure how you're supposed to respond, since it's asked for
zero
responses to its authentication request.

Peter.

On Tue, Apr 7, 2015 at 12:29 AM, Peter Gutmann <pgut001 at
cs.auckland.ac.nz>
wrote:
> I've had a report from a user that "SSH-2.0-OpenSSH_6.6.1_hpn13v11
> FreeBSD-20140420" is sending an invalid SSH_MSG_USERAUTH_INFO_REQUEST.
>
That's a vendor-modified version of OpenSSH.  Assuming it corresponds to
what's in FreeBSD head, there's about a thousand lines of changes.
Browsing through the diffs I don't see anything that could obviously cause
it, but I am far from sure.

Can you reproduce the problem with an unmodified version from openssh.com?
Failing that, can you get the server-side debug output from a failing
connection (ie /path/to/sshd -ddd)?

Thanks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

OK, I can see similar behaviour on Linux with 6.8p1 with PAM enabled.  This
is the debug output from a slightly modified openssh client:

debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug1: input_userauth_info_req: name '' instructions '' lang
''
debug2: input_userauth_info_req: num_prompts 1
Password:
debug2: input_userauth_info_req
debug1: input_userauth_info_req: name '' instructions '' lang
''
debug2: input_userauth_info_req: num_prompts 0
debug1: Enabling compression at level 6.

On Tue, Apr 7, 2015 at 12:29 AM, Peter Gutmann <pgut001 at
cs.auckland.ac.nz>
wrote:
>
> to which I reply with a SSH_MSG_USERAUTH_INFO_RESPONSE.  The server then
> sends
> a second SSH_MSG_USERAUTH_INFO_REQUEST consisting of 16 bytes of zeros:
>
>   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>
> for which, even if you ignore the fact that it fails a data-validity check,
>
Assuming that's the whole packet, I think that's a
zero-prompt USERAUTH_INFO_REQUEST packet containing empty name,
instructions and language strings.  What do you mean by "fails a
data-validity check"?

If it was just the prompt part of the packet, what's in the name and
instruction fields?

I'm not sure how you're supposed to respond, since it's asked for
zero
> responses to its authentication request.
>
Zero prompts is specifically allowed by RFC4256 section 3.2:

" The num-prompts field may be `0', in which case there will be no
   prompt/echo fields in the message, but the client SHOULD still
   display the name and instruction fields (as described below)."

In my case, those strings are empty, so sshd probably shouldn't generate
them (I'll dig into why they get generated) but it seems like a valid (if
pointless) protocol message to me.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.