Guacamole FreeRDP uses channel_id > 255 for microphone redirection

[Kishi85]

Dear folks,

Guacamole connecting to XRDP via it's FreeRDP based RDP connection uses a channel_id > 255 for it's microphone redirection. This makes the connection crash with the following error:

Received [MS-RDPEDYC] DYNVC_CREATE_RSP for an invalid channel id. Max allowed 255, received 32003

Seems like the culprit is in libxrdp/xrdp_channel.c where the channel_id is hardcoded with a limit of 255 (line 395 + 491). Just guessing here but it might have been in the protocol specs at one time or it is an arbirary limit from the past but as it is right now it breaks things (A channel_id limit of 32768 might be a good compromise if the protocol specs don't give a range, considering that microphone on guacmole starts around channel_id 32000).

Current workaround for me is to disable microphone redirects for XRDP connections. On native Windows Server 2019 it works like a charm.

Tested with xrdp_0.9.16+xorgxrdp_0.2.16 on Ubuntu 20.04 (installed with the great xrdp-installer.sh).

Thanks in advance, Kishi85

[metalefty]

Hi, thanks for the report and the good catch.

As far as I read the specification, channel id has a dynamic length of 1 byte to 4 bytes. https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpedyc/8f284ea3-54f3-4c24-8168-8a001c63b581

drdynvc_get_chan_id can properly handle such dynamic length but the hardcoded limit that you pointed is wrong. https://github.com/neutrinolabs/xrdp/blob/53e2ecff4d01e6efc197bdc31d4e64225063e169/libxrdp/xrdp_channel.c#L265-L297

https://github.com/neutrinolabs/xrdp/blob/53e2ecff4d01e6efc197bdc31d4e64225063e169/libxrdp/xrdp_channel.c#L357-L365

[Kishi85]

I've just noticed that in order to reproduce this one has to use the "RDP Encryption" setting in Guacamole/FreeRDP explicitly. Using "TLS Encryption" everything is working fine as well (even with the id limit of 255).

Also after looking at the code in xrdp_channel.c there are a few more checks for a channel_id < 255, not only the lines i mentioned earlier, which probably all have to be checked and properly fixed (which i'm unfortunately uncapable to do).