Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Roman Janota <Roman.Janota@xxxxxxxxx>]

Hi,

as the author of the original patch, I wanted to thank you Jakub for 
spotting the incorrect argument in there. I have no idea how I missed 
that and all of this would have been fixed weeks ago. Sorry for wasting 
your time.

Roman

On 9/9/24 12:33 PM, Jakub Jelen wrote:
> Thanks for checking! Good to hear it works now!
> Jakub
>
> On Mon, Sep 9, 2024 at 11:58 AM Mikael Petterson
> <mikael.petterson@xxxxxxxxxxxx> wrote:
> > Hi
> >
> > Yes my testcase works now and I cannot see any issues.
> > Thanks for the support from both of you.
> >
> > Br,
> >
> > //mike
> >
> >
> > -----Original Message-----
> > From: Michal Vasko <mvasko@xxxxxxxxx>
> > Sent: Monday, 9 September 2024 11:34
> > To: libssh@xxxxxxxxxx
> > Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
> >
> > Hi,
> >
> > @Mike Please try using the current `devel` branches WITHOUT any patches.
> > It is likely there was some confusion and you were applying a faulty
> > patch. Jakub's patch should fix the issue, so I have committed it.
> >
> > @Jakub Thanks for the patch.
> >
> > Regards,
> > Michal
> >
> > On 9. 9. 2024 10:16, Mikael Petterson wrote:
> > > Hi,
> > >
> > > Jakub, was the log sufficient?
> > >
> > > Br.
> > >
> > > //mike
> > >
> > > -----Original Message-----
> > > From: Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>
> > > Sent: Friday, 6 September 2024 11:22
> > > To: libssh@xxxxxxxxxx
> > > Subject: RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
> > >
> > > Hi,
> > >
> > > I applied the patch.
> > >
> > > Attaching new log file here.
> > >
> > > Br,
> > >
> > > //mike
> > >
> > > -----Original Message-----
> > > From: Jakub Jelen <jjelen@xxxxxxxxxx>
> > > Sent: Friday, 6 September 2024 09:41
> > > To: libssh@xxxxxxxxxx
> > > Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
> > >
> > > Thank you.
> > >
> > > I see right, in this case, there is no log line with ssh_message_reply_default(), that was the problem previously.
> > >
> > > I also see in the build process that the patch to check the return value of nc_session_ssh_msg() was added (but with wrong argument -- msg instead of ssh_msg) -- I also do not see that patch applied anywhere. Can you try with the attached patch if it will make some difference?
> > >
> > >
> > > On Thu, Sep 5, 2024 at 4:14 PM Mikael Petterson <mikael.petterson@xxxxxxxxxxxx> wrote:
> > > > Hi Jakub and Michal
> > > >
> > > > I finally managed to replace and use level 4.
> > > >
> > > > I will attach file.
> > > >
> > > > Br,
> > > >
> > > > //mike
> > > >
> > > > -----Original Message-----
> > > > From: Jakub Jelen <jjelen@xxxxxxxxxx>
> > > > Sent: Thursday, 5 September 2024 10:58
> > > > To: libssh@xxxxxxxxxx
> > > > Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
> > > >
> > > > 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > > gi%2F&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C4523de353f3
> > > > > > b4b21677f08dcce474669%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
> > > > > > C638612052746761002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Lh
> > > > > > BNVBPm7pfRaiqrxSfmTJw4AaTTLdp6UYbFejf2TLU%3D&reserved=0
> > > > > > thub.com%2FCESNET%2Flibnetconf2%2Fblob%2F47ca0fb5f94588d112ec2bf26
> > > > > > 94
> > > > > > 6948189e1c18d%2Fsrc%2Fsession_server_ssh.c%23L1692&data=05%7C02%7C
> > > > > > mi
> > > > > > kael.petterson%40ericsson.com%7C719221ae31dc4b58302a08dccd88d893%7
> > > > > > C9
> > > > > > 2e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638611234853208375%7CUnk
> > > > > > no
> > > > > > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > > > > Ww
> > > > > > iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Y6QUN%2Fj4%2F9qN9Dscw4MgnrDVxy7
> > > > > > oJ
> > > > > > 1ytZ%2B4Evkphj5E%3D&reserved=0
> > > > > >
> > > > > > 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > > gi%2F&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C4523de353f3
> > > > > > b4b21677f08dcce474669%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
> > > > > > C638612052746778162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=u8
> > > > > > iOGYcF1WcUjrK%2BI3TeQNrMrn0Bu0leulAEKbc1JS4%3D&reserved=0
> > > > > > thub.com%2FCESNET%2Flibnetconf2%2Fblob%2F47ca0fb5f94588d112ec2bf26
> > > > > > 94
> > > > > > 6948189e1c18d%2Fsrc%2Fsession_server.c%23L1609&data=05%7C02%7Cmika
> > > > > > el
> > > > > > .petterson%40ericsson.com%7C719221ae31dc4b58302a08dccd88d893%7C92e
> > > > > > 84
> > > > > > cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638611234853219071%7CUnknown
> > > > > > %7
> > > > > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > > > > > CJ
> > > > > > XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=p3xTb6x9a1nrqaZPJ5H1l7NNGDSHctbuOHE
> > > > > > %2
> > > > > > BTqO775c%3D&reserved=0
> > > > > >
> > > > > > 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
> > > > > > > > > > %7
> > > > > > > > > > Cm
> > > > > > > > > > ik
> > > > > > > > > > ael.petterson%40ericsson.com%7C2e154092532e4b0f804308dccc035f0
> > > > > > > > > > 5%
> > > > > > > > > > 7C
> > > > > > > > > > 92
> > > > > > > > > > e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638609562056373731%7C
> > > > > > > > > > Un
> > > > > > > > > > kn
> > > > > > > > > > ow
> > > > > > > > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > > > > > > > > > 1h
> > > > > > > > > > aW
> > > > > > > > > > wi
> > > > > > > > > > LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Q%2FSgGmCtGEbBiJV2ah9n2IAsdF
> > > > > > > > > > aa
> > > > > > > > > > CN
> > > > > > > > > > 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%2Fmess
> > > > > > > > > > ag
> > > > > > > > > > es
> > > > > > > > > > .c
> > > > > > > > > > %23L175&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C2e154
> > > > > > > > > > 09
> > > > > > > > > > 25
> > > > > > > > > > 32
> > > > > > > > > > e4b0f804308dccc035f05%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7
> > > > > > > > > > C0
> > > > > > > > > > %7
> > > > > > > > > > C6
> > > > > > > > > > 38609562056380910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > > > > > > > > > LC
> > > > > > > > > > JQ
> > > > > > > > > > Ij
> > > > > > > > > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=71
> > > > > > > > > > nn
> > > > > > > > > > DT
> > > > > > > > > > 4y
> > > > > > > > > > jtVA0tkfjqrViDjTKFyhsPwtQibVIJFzhr8%3D&reserved=0
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > But could not see any support for unknown.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Maybe I am looking in the wrong place.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Br.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > //mike

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature