Headline
CVE-2020-11525: Commits · FreeRDP/FreeRDP
libfreerdp/cache/bitmap.c in FreeRDP versions > 1.0 through 2.0.0-rc4 has an Out of bounds read.
Commits on Jul 29, 2022
Commits on Jul 26, 2022
Drdynvc needs love (#8059)
* winpr: add lock operation on HashTables
* drdynvc: change the listeners array for a hashtable and other micro cleanups
* logonInfo: drop warning that is shown at every connection
Let’s avoid this log, we can’t do anything if at Microsoft they don’t respect their own specs.
* rdpei: fix terminate of rdpei
* drdynvc: implement the channel list with a hashtable by channelId
Commits on Jul 22, 2022
Commits on Jul 21, 2022
Commits on Jul 15, 2022
codec/progressive: Fix wrong usage of subband diffing flag (#8076)
Currently, all Calista Progressive encoded streams contain tile artifacts, when the RFX_SUBBAND_DIFFING is used, but not the RFX_DWT_REDUCE_EXTRAPOLATE flag. The reason is the wrong usage of the context and tile flags. The RFX_SUBBAND_DIFFING flag should have no actual impact on the decoder itself. Especially, it does not affect the band sizes within a 64x64 tile. The RFX_DWT_REDUCE_EXTRAPOLATE flag, on the other hand, MUST have an effect on the band sizes. However, FreeRDP currently uses the RFX_SUBBAND_DIFFING flag when decoding a component to determine whether the Reduce-Extrapolate method is used, resulting in tile artifacts, when that method was actually not used. The current behaviour did not result in tile artifacts with the MS Windows RDS, as that server always sets both flags.
So, fix this issue by using the correct flag, when decoding a tile.
Commits on Jul 12, 2022
Commits on Jul 7, 2022
- gateway: Base-64 encode websocket key in request header
According to the RFC the websocket key in the request header should be
base-64 encoded:
The request MUST include a header field with the name |Sec-WebSocket-Key|. The value of this header field MUST be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded (see Section 4 of \[RFC4648\]). The nonce MUST be selected randomly for each connection.
If we just send a random key this might cause problems with
gateways/proxies that try to decode the key, resulting in an error (i.e.
HAProxy returns 400 Bad Request).
- client/X11: Relieve CLIPRDR filename restriction when possible
Microsoft Windows imposes strict filename restrictions on its platform.
As RDP is developed by Microsoft and the RDS in MS Windows is typically
used as remote desktop server for the RDP protocol, these filename
restrictions are also enforced in WinPR, when copy-pasting files over
the clipboard.
However, in some connections no peer on MS Windows is involved and in
these situations, these filename restrictions are just an annoyance.
With a recent API addition in WinPR, it is now possible to override the
callback, where the filename is checked, whether it is valid.
So, use this new API to relieve the filename restriction, when the
connected remote desktop server is not on MS Windows.
- winpr/clipboard: Allow overriding ValidFileNameComponent call
When using the wClipboard API, the connected peer might not be on the
Windows platform, where further filename restriction exists.
As a result, it is currently not possible to use the wClipboard API,
when intending to allow filenames, containing characters like ':'.
So, add a callback to the wClipboardDelegate, which is set to the
ValidFileNameComponent call by default.
This callback can be overridden by the API user, when it is known, that
there is no need to impose very strict filename restrictions.