Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Jakub Jelen <jjelen@xxxxxxxxxx>]

Right, this message sounds suspicious, but it is not clear to me where
does it come from, especially when I can not reproduce the issue with
just libssh as mentioned before.

I see in the log that the `trilead-ping` is received twice over the
exchange, but both are processed only at the end of the output. The
first comes with type 0:

2024-09-04 10:02:36,496 (Slf4jLogConsumer.java:73)  INFO : STDERR:
[2024/09/04 08:02:36.482476, 3] ssh_message_reply_default:  Don't know
what to default reply to 0 type

but the second comes with the suspicious large value, which differs
between invocations (If I read right):

2024-09-04 10:02:36,920 (Slf4jLogConsumer.java:73)  INFO : STDERR:
[2024/09/04 08:02:36.925229, 3] ssh_message_reply_default:  Don't know
what to default reply to 1120325360 type

So this looks like that the memory where the message is stored (when
passed to the ssh_message_reply_default() function), is either
uninitialized or more likely freed and already rewritten by something
else. Can you run the netopeer2 under valgrind to see if there are
some invalid memory accesses or violations?

Jakub

On Thu, Sep 5, 2024 at 8:18 AM Michal Vasko <mvasko@xxxxxxxxx> wrote:
>
> Hi Jakub,
>
> libnetconf2/netopeer2 author here. The issue actually started in our
> projects but was then moved to libssh because I believe that is where
> the problem is. That should be supported by the output
>
> [2024/09/02 09:46:31.284447, 3] ssh_message_reply_default:  Don't know what to default reply to 67108912 type
>
> meaning libssh is asked to send the reply but it fails to do so. You
> asked for trace-level output and Mike should be able to provide it,
> soon. Hopefully, you will be able to reproduce the problem and fix it then.
>
> Regards,
> Michal
>
> On 4. 9. 2024 17:21, Jakub Jelen wrote:
> > The following line from the log shows that the function processing the
> > packet is called as expected
> >
> > 2024-09-04 10:02:36,919 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> > [2024/09/04 08:02:36.925128, 3] ssh_message_handle_channel_request:
> > Received a trilead-ping channel_request for channel (43:100)
> > (want_reply=1)
> >
> > So it looks like all of the message is parsed correctly on the libssh
> > side. The next message comes form netopeer2:
> >
> > 2024-09-04 10:02:36,920 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> > [INF]: LN: Session 1: Received an SSH message "request-channel" of
> > subtype "unknown".
> >
> >  From here:
> >
> > https://github.com/CESNET/libnetconf2/blob/47ca0fb5f94588d112ec2bf26946948189e1c18d/src/session_server_ssh.c#L1692
> >
> > It looks like netopeer2 is handling the messages on its own instead of
> > using the callbacks. It most of the cases, the callers of this
> > function check the return value, but there is one where they do not do
> > that, which might cause this behavior where the reply is not sent:
> >
> > https://github.com/CESNET/libnetconf2/blob/47ca0fb5f94588d112ec2bf26946948189e1c18d/src/session_server.c#L1609
> >
> > I would probably suggest to open an issue to netopeer2 to confirm that
> > this could be the cause. The default callbacks that we have in libssh
> > seems to process the messages correctly.
> >
> > Jakub
> >>>>> I checked the RFC
> >>>>> https://ww/
> >>>>> w.rfc-editor.org%2Frfc%2Frfc4254.html%23section-5&data=05%7C02%7Cm
> >>>>> ik
> >>>>> ael.petterson%40ericsson.com%7C2e154092532e4b0f804308dccc035f05%7C
> >>>>> 92
> >>>>> e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638609562056373731%7CUnkn
> >>>>> ow
> >>>>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> >>>>> wi
> >>>>> LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Q%2FSgGmCtGEbBiJV2ah9n2IAsdFaaCN
> >>>>> XW
> >>>>> QsYZ7E0CcmQ%3D&reserved=0
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 5.4.  Channel-Specific Requests
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Many 'channel type' values have extensions that are specific to
> >>>>> that
> >>>>>
> >>>>>     particular 'channel type'.  An example is requesting a pty
> >>>>> (pseudo
> >>>>>
> >>>>>     terminal) for an interactive session.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     All channel-specific requests use the following format.
> >>>>>
> >>>>>
> >>>>>
> >>>>>        byte      SSH_MSG_CHANNEL_REQUEST
> >>>>>
> >>>>>        uint32    recipient channel
> >>>>>
> >>>>>        string    request type in US-ASCII characters only
> >>>>>
> >>>>>        boolean   want reply
> >>>>>
> >>>>>        ....      type-specific data follows
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Ylonen & Lonvick            Standards Track                     [Page 9]
> >>>>>
> >>>>> ________________________________
> >>>>>
> >>>>>
> >>>>>
> >>>>> RFC 4254                SSH Connection Protocol             January 2006
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     If 'want reply' is FALSE, no response will be sent to the request.
> >>>>>
> >>>>>     Otherwise, the recipient responds with either
> >>>>>
> >>>>>     SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or
> >>>>> request-specific
> >>>>>
> >>>>>     continuation messages.  If the request is not recognized or is
> >>>>> not
> >>>>>
> >>>>>     supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     This message does not consume window space and can be sent even
> >>>>> if no
> >>>>>
> >>>>>     window space is available.  The values of 'request type' are
> >>>>> local to
> >>>>>
> >>>>>     each channel type.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     The client is allowed to send further messages without waiting
> >>>>> for
> >>>>>
> >>>>>     the response to the request.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     'request type' names follow the DNS extensibility naming
> >>>>> convention
> >>>>>
> >>>>>     outlined in [SSH-ARCH] and [SSH-NUMBERS].
> >>>>>
> >>>>>
> >>>>>
> >>>>>        byte      SSH_MSG_CHANNEL_SUCCESS
> >>>>>
> >>>>>        uint32    recipient channel
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>        byte      SSH_MSG_CHANNEL_FAILURE
> >>>>>
> >>>>>        uint32    recipient channel
> >>>>>
> >>>>>
> >>>>>
> >>>>>     These messages do not consume window space and can be sent even
> >>>>> if no
> >>>>>
> >>>>>     window space is available.
> >>>>>
> >>>>>
> >>>>>
> >>>>> So we should at least expect a SSH_MSG_CHANNEL_FAILURE.
> >>>>>
> >>>>>
> >>>>> I checked:
> >>>>>
> >>>>> https://gi/
> >>>>> thub.com%2Flibssh%2Flibssh-mirror%2Fblob%2Fmaster%2Fsrc%2Fmessages
> >>>>> .c
> >>>>> %23L175&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C2e1540925
> >>>>> 32
> >>>>> e4b0f804308dccc035f05%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
> >>>>> C6
> >>>>> 38609562056380910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> >>>>> Ij
> >>>>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=71nnDT
> >>>>> 4y
> >>>>> jtVA0tkfjqrViDjTKFyhsPwtQibVIJFzhr8%3D&reserved=0
> >>>>>
> >>>>>
> >>>>>
> >>>>> But could not see any support for unknown.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Maybe I am looking in the wrong place.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Br.
> >>>>>
> >>>>>
> >>>>>
> >>>>> //mike
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >