The old implementation used `Stream_GetLength` to obtain the amount of
data to send. However some PDUs (i.e. CLIPRDR_FILECONTENTS_REQUEST) are
overallocated as they contain optional data (clipDataId in this case).
We now use the position to determine the actual data written to the PDU
instead of the amount of bytes allocated, avoid sending garbage data to
the client.
When a FreeRDP-based server tried to open a DVC, but the client answered
the DVC create request with a negative CreationStatus in the DVC create
response PDU, the server can then assume that no actual PDUs can be
received for that channel.
However, as long as the channel handle exists, FreeRDP happily forwards
any potential PDU for that handle disregarding the CreationStatus.
This is problematic, since the channel handling usually runs in its own
thread and as a result, the channel may not be destructed yet, when
receiving such stray PDU.
The PDU may be processed, even though it is not expected to be.
A situation, where this becomes problematic is the AUDIO_PLAYBACK_DVC
channel.
It may be the case, that the client answered the DVC create request
with a negative result, the server may try to close the handle and open
the static channel (RDPSND) instead, but before the server can close the
channel handle, the client actually sends PDUs regarding the format
negotiation.
In this case, the server may unintentionally already set things up,
which was not desired (the DVC is about to be closed anyway).
While this specific situation is hypothetical, since it would depend on
a malicious client, it is still possible to happen, especially since the
server implementation does not invoke the format negotiation, but
FreeRDP does it automatically, as soon as the DVC create request is
sent.
Fix this issue by discarding any data PDUs (DYNVC_DATA_FIRST and
DYNVC_DATA) of channels, that were not opened successfully.
With all calls when WTSVirtualChannelQuery returns FALSE that means that
no ppBuffer was allocated, that was not the case with class=WTSVirtualChannelReady.
Most callers were not aware of that, leading to leaks for example when the channel is
not available client-side, the patch changes that so that you have to call call WTSFreeMemory
only if WTSVirtualChannelQuery returned TRUE.
This patch does a few cleanups to allow creating TLS and DTLS contexts.
It also introduces tls_accept_ex and tls_connect_ex that can start the SSL handshake,
and it can be finished by calling tls_handshake
The shadow server tries to resize the client to use a compatible
resolution. If that fails, e.g. if there is another resize request after
the disconnect/reconnect sequence, abort the connection.
* Add callbacks for all messages exchanged between client and server
to allow server implementations to intercept them.
* Unify logging
* Add device tracking
due to the nature of the sound channel there are multiple listeners
waiting for the server to open the channel and most of them are called
by the server. Only open the channel once.
* Ensure DeleteSurface is called before CreateSurface: Under certain
conditions it is possible that there already exists a surface with the
same id as the new CreateSurface PDU. Delete the already existing
instance in that case before creating a new one.
* Simplify surface cleanup on shutdown: Use HashTable_Foreach
In case alternate shell was set to an empty string ("") the old code
would try to convert it to a WChar string. This resulted in a NULL
pointer being returned by `ConvertUtf8ToWCharAlloc` that was interpreted
as an error and the connection failed.
* Removed comments with invalid assumptions
* Added arguments to rdp_read_info_null_string to indicate if the string
is expected to be '\0' terminated and what is actually read for error
logs
