Bug 1848018 (CVE-2020-11038) - CVE-2020-11038 freerdp: Integer overflow in VIDEO channel
Summary: CVE-2020-11038 freerdp: Integer overflow in VIDEO channel
Alias: CVE-2020-11038
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1848019 1848020 1850726 1850727
Blocks: 1848044
TreeView+ depends on / blocked
Reported: 2020-06-17 14:31 UTC by Michael Kaplan
Modified: 2021-02-16 19:52 UTC (History)
5 users (show)

Fixed In Version: freerdp 2.1.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-09-29 22:01:48 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4031 0 None None None 2020-09-29 20:44:22 UTC
Red Hat Product Errata RHSA-2020:4647 0 None None None 2020-11-04 02:39:17 UTC

Description Michael Kaplan 2020-06-17 14:31:57 UTC
In FreeRDP less than or equal to 2.0.0, an Integer Overflow to Buffer Overflow exists. When using /video redirection, a manipulated server can instruct the client to allocate a buffer with a smaller size than requested due to an integer overflow in size calculation. With later messages, the server can manipulate the client to write data out of bound to the previously allocated buffer. This has been patched in 2.1.0.



Comment 1 Michael Kaplan 2020-06-17 14:32:19 UTC
Created freerdp tracking bugs for this issue:

Affects: fedora-all [bug 1848019]

Created freerdp1.2 tracking bugs for this issue:

Affects: fedora-all [bug 1848020]

Comment 2 Todd Cullum 2020-06-24 19:26:24 UTC
Technical Summary:

This flaw exists in the freerdp CLIENT application in channels/video/client/video_main.c. The video_read_tsmm_presentation_req() routine reads the width & height of a video presentation from the input stream with data coming from the server. It passes the width & height to video_PresentationRequest(), and then to PresentationContext_new(), which computes the size requested during a memory allocation with BufferPool_Take(). BufferPool_Take()'s size parameter is of type int. An untrusted or compromised freerdp server could provide bogus width & height data in the stream, which would cause a memory allocation of an improper size due to integer overflow, and could subsequently cause an out-of-bounds write on the client, triggering a crash or memory corruption.

The patch checks to ensure that the value passed to BufferPool_Take() is less than INT32_MAX in PresentationContext_new(). It also stores the width * height result in a size_t variable.

Upstream patch: https://github.com/FreeRDP/FreeRDP/commit/06c32f170093a6ecde93e3bc07fed6a706bfbeb3

Comment 3 Todd Cullum 2020-06-24 19:46:39 UTC

This flaw can be mitigated by deactivating video redirection on the client side and not using /video.

Comment 5 Todd Cullum 2020-06-24 20:00:00 UTC
I changed the impact to Low because this affects only the client, would require connecting to a compromised/untrusted server, and exploitation would not lead to a persistent denial of service.

Comment 6 Todd Cullum 2020-06-24 20:03:25 UTC

Although this flaw affects versions of freerdp shipped with Red Hat Enterprise Linux 7 and 8, Red Hat Product Security views this flaw as having low impact because it only affects the freerdp client, the user must connect to an untrusted or compromised server, and it would not lead to a persistent denial of service if exploited.

Comment 7 errata-xmlrpc 2020-09-29 20:44:20 UTC
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

Comment 8 Product Security DevOps Team 2020-09-29 22:01:48 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 9 errata-xmlrpc 2020-11-04 02:39:16 UTC
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

Note You need to log in before you can comment on or make changes to this bug.