Multiple bugs within the Microsoft RDP Client (Server being the attacker) found through fuzzing. None covered at this time are very impactful but there is some background in Virtual Channels within RDP and experieince getting a fuzzing envrionment setup that might be of value.

Out-of-Bounds Read in RDPSND

This vulnerabilities was found in the virtual channel for transporting audio data from server to client. A wFormatNo controlled by an attacker is used to calculate the offset to for the targetFormat

targetFormat = *(AudioFormat **)(savedAudioFormats + 8 * wFormatNo);

The challenge with this one is that while there is not always length checking, if the lastFormatNo is not equal to the current wFormatNo then a call to CRdpAudioController::OnNewFormat(this, wFormatNo) will be made. This function does do some input validation to ensure the value is not out of bounds.

To get around this one could change out the number of supported audio formats between messages. Sending an inital list of supported formats with n entries, sending a message using wFormatNo set to n, then sending another list of supported formats with less than n entries. Resulting in an out-of-bounds read when calculating the targetFormat pointer.

Exploiting this bug may be a challenge though, as the targetFormat is only used to read the wFormatTag field, and check if it is equal to 1, leaking limited information.

Arbitrary Malloc

This issue was found twice, one in CLIPDR the virtual channel for clipboard synchronization, and once in RDPDR a virtual channel for redirecting file-system access.

For the clipboard case, the clipDataId field would be used in a calculation (8 x (32+clipDataId)) going into malloc. So a large value could lead to a malloc of up to around 32GB.

With RDPDR the issue was a little less powerful, OutputBufferLength being used in a malloc call directly, but since its a 32bit value, only able to allocate about 4GB, and only once per session.