In FreeRDP less than or equal to 2.0.0, there is an out-of-bound data read from memory in clear_decompress_subcode_rlex, visualized on screen as color. This has been patched in 2.1.0. References: https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-x4wq-m7c9-rjgr https://pub.freerdp.com/cve/CVE-2020-11040/
Created freerdp tracking bugs for this issue: Affects: fedora-all [bug 1848030] Created freerdp1.2 tracking bugs for this issue: Affects: fedora-all [bug 1848031]
clear_decompress_subcode_rlex() in libfreerdp/codec/clear.c reads in rgb data for color palettes from the input stream using a loop but does not first ensure that there is enough bytes left in the stream before reading. It first reads in palleteCount from the stream as a UINT8. It then uses palleteCount to control the number of loop iterations when reading in rgb data. It's possible for the rdp server to send a bogus palleteCount to the client in the stream, which would cause the loop to perform the out-of-bounds read on the stream. The read is still somewhat limited as the most that could be read in a call is 765 bytes, or 3 * 255, since palleteCount is a BYTE type. This vulnerability will only be triggered if /gfx connection modes are used in the client. Upstream patch: https://github.com/FreeRDP/FreeRDP/commit/363d7046dfec4003b91aecf7867e3b05905f3843 The patch checks length of stream before reading.
Mitigation: The flaw can be mitigated by not running the freerdp client with the /gfx connection modes and/or not connecting to untrusted or compromised rdp servers.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:4031 https://access.redhat.com/errata/RHSA-2020:4031
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-11040
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4647 https://access.redhat.com/errata/RHSA-2020:4647