Skip to content

rdp-fuse-clipboard: Read files until the very end

Pascal Nowack requested to merge pnowack/gnome-remote-desktop:cliprdr-zero-size-fix into master

Quoting the main commit message here:

Currently, gnome-remote-desktop truncates the requested file size to
the actual size of the requested file.
While this action is protocol-wise completely fine, it causes a serious
issue with mstsc and also did with xfreerdp in the past:

Until recently, FreeRDP had a bug ([1]), where xfreerdp opened a FD to
read the file contents, closed the FD, when the transfer of the file
was complete and opened the FD again on the last (zero-sized) request,
but never closed the FD again.
The result was that, when copying over a thousand files, the
transmission will eventually fail, since xfreerdp runs out of open FDs.
The bug is now fixed on FreeRDPs master, but old clients will still run
into this issue (without this commit).

mstsc has a similar bug: However, it is way nastier:
When transferring files with mstsc, gnome-remote-desktop (and any other
server too) needs to read the file until mstsc returns the size 0.
If gnome-remote-desktop stops earlier (, while still reading the
complete file, but not requesting the non-existing last byte(s)) or
requests a zero-sized part at the end, mstsc will fail.
It fails in either two ways: Either mstsc silently fails by not
responding to the file requests (leaving g-r-d in the rain) or it fails
in a really nasty way by responding with corrupt data.
Corrupt data means, the whole PDU is corrupt.
FreeRDP notices that and puts out an error like this:
"Unexpected clipboard PDU type: 62048"
After this error, FreeRDP immediately stops the cliprdr thread to
prevent any damage.

This issue might not even just be a protocol violation, but maybe also
a serious security issue (CVE) in mstsc.
It is, however, pointless to report this to Microsoft. They won't fix
it anyway, unless Google makes the issue public (it was also the case
in the past with other way more problematic issues).

Both cases are (were in the case of FreeRDP) issues on the client side.
However, gnome-remote-desktop can work around them by not truncating
the requested size.
The FUSE backend already reads a file until it receives a zero-sized
buffer as response, so the only the thing that gnome-remote-desktop
needs to do is to not truncate files to zero any more.
The size to request can still be truncated to prevent massive requests,
but not to zero any more.

So, remove the truncate handling, except the parts, where huge file
requests are truncated to smaller ones, to ensure that both old
xfreerdp versions and mstsc always work fine.
gnome-remote-desktop cannot fix these client side issues, only work
around them.

[1]: https://github.com/FreeRDP/FreeRDP/pull/6924

Merge request reports