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.

Leaving out many of the specifics about how Azure Sphere devices work. Under normal circumstances it appears that you shoudl neither be able to downgrade a devices firmware, nor install any firmware without providing the Microsoft-signed manifest beforehand.

The issue Talos Found was that it was posisble to install the “Trusted Keystore” image wihtout any manifest or version restriction. So by installing a different version will result in the Pluton processor (root of trust on Azure Sphere) using a bad key when checking the firmware image, leading to a failed verification and rebooting the device (repeating the process).

Out of bounds access in the GPIO_SET_PIN_CONFIG_IOCTL leading to information disclosure. When parsing the lineoffsets field from the gpiopin_request object, there’s no bounds checking on it before it’s used as an index into an array of descriptions to get a desc pointer. This is only useful for information disclosure though, because the only useful avenue they found for exploiting the issue was a permission check that would use the desc->allowed_user field and compare it against the current UID. By using this permission check as an oracle, they could scan memory for sequences of bytes that match the process UID. They use this to find and leak the address of the cred structure in the heap.