Length checking for the EGFX dynamic virtual channel is inadequate,
allowing for heap overflows to be forced by a malicious client before
authentication.
The first argument to libxrdp_init() is a intptr_t / tbus value. This
represents the xrdp instance which is using the library, but this value
is always a 'struct xrdp_process' pointer.
This PR replaces the intptr_t with an incomplete type declaration at
the interface between xrdp and libxrdp.
The original intention was probably to provide some separation from
xrdp and the libxrdp code, but in practice this has turned out not to be
useful.
void * pointers in xrdp_session are replaced with pointers to
incomplete types. This allows us to remove a very large number of casts
related to these members in libxrdp.c
This name better matches the name from [MS-RDPBCGR]. Also, the size
of the UTF-8 buffer allocated for the client name is not large
enough for some of the names which could potentially be passed across
in UTF-16 from the client.
This allows sesexec to send a reason for a connection close
request to xrdp.
xrdp is also updated to support server initiated disconnection sequences
from [MS-RDPBCGR] 1.3.1.4, along with reporting a reason to the client
for the disconnection.
The data in 'struct xrdp_client_info' which is shared with xorgxrdp
is separated out into a separate structure. This makes it simpler to
change 'struct xrdp_client_info' without affecting xorgxrdp.
1) In FIPS mode, Classic RDP security is not allowed at all.
2) In FIPS mode xrdp-keygen creates an empty file
3) Documentation wording improved around the security_level setting
4) Logging improved around the security negotiation
5) Warnings now generated if Classic RDP security is negotiated
1) Remove 'magic numbers' related to static channel name lengths, and
replace with CHANNEL_NAME_LEN, or CHANNEL_NAME_LEN+1, as appropriate.
2) Always add static channel definitions, even if they are malformed.
3) Log channels which the client sends, which aren't named in
the [Channels] section of xrdp.ini.
(cherry picked from commit 9092d898b7dceda713bd05b296ea8e8213ee614b)
This allows the `xrdp` part of the path `/etc/xrdp` where config files
are placed to be customizable. This change is useful when trying the
stable version and the devel version alternately.
THe function xrdp_sec_in_mcs_data() parses data within the
TS_UD_CS_CORE struct which could just as easily be parsed
when xrdp_sec_process_mcs_data_CS_CORE() is called.
Currently the contents of the MSC Connect Initial PDU are stored within
the client_mcs_data member of the xrdp_sec struct. This stream is parsed
once by xrdp_sec_process_mcs_data() and then separately by
xrdp_sec_in_mcs_data(). There is no reason not to perform the parse in
a single pass through the stream.
This commit folds the functionality in xrdp_sec_in_mcs_data() into
xrdp_sec_process_mcs_data_CS_CORE() and removes xrdp_sec_in_mcs_data()
We always now indicate we support skipping channel joins. If the client
indicates this too, expect no channel join requests from the client.
If we do get some, process them anyway.
The existing code contains separate TLS and non-TLS code paths for
hadling channel join PDUs. This was introduced in
8fdc1ba216 and was based on a
misunderstanding of where in the connection sequence the TLS client hello
is processed (if a TLS connection is negotiated). The assumption was
the TLS client hello is received after the channel join PDUs. However,
it is actually received immediately after the X.224 Connection Confirm
PDU some time before channel join requests are processed.
Consequently, there is no reason not to adopt a single code path for
handling channel joins.
metalefty