Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core/server: Ignore data PDUs for DVCs that were not opened successfully #8581

Merged
merged 1 commit into from
Dec 31, 2022

Conversation

pnowack
Copy link
Member

@pnowack pnowack commented Dec 30, 2022

Quoting the commit message here:

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.

Was working on a SVC fallback for audio output redirection (https://gitlab.gnome.org/pnowack/gnome-remote-desktop/-/commit/0f9f68b0d41869be51915bf9bc944b9d61e98488), then realized the situation described in the commit message.

@freerdp-bot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://ci.freerdp.com//job/PullRequestTester/8695/

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.
Copy link
Contributor

@hardening hardening left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch

@freerdp-bot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://ci.freerdp.com//job/PullRequestTester/8696/

@pnowack pnowack merged commit 8d02a07 into FreeRDP:master Dec 31, 2022
@pnowack pnowack deleted the drdynvc-data-open-failed branch December 31, 2022 09:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants