[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Follow-Ups:
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
References:
Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknownJakub Jelen <jjelen@xxxxxxxxxx>
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknownJakub Jelen <jjelen@xxxxxxxxxx>
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknownJakub Jelen <jjelen@xxxxxxxxxx>
Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMichal Vasko <mvasko@xxxxxxxxx>
Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknownJakub Jelen <jjelen@xxxxxxxxxx>
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknownJakub Jelen <jjelen@xxxxxxxxxx>
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknownMikael Petterson <mikael.petterson@xxxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org