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 = *(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
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.
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.
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.