Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Amazon WorkSpaces is a fully managed and persistent desktop virtualization service that enables users to access data, applications, and resources they need anywhere from any supported device. Session information is handled via HTTPs but the stream is handled via PCoIP or WSP (Workspaces Streaming Protocol. WSP uses many third party libraries in order to make the virtual PC feel like it is more physical than it really is, such as USB over Ethernet by Eltima SDK.

USB redirection is done by the Eltima SDK. The Kernel IO Manager (IOMgr) controls the flow of the information between kernel and user mode. When a user-mode request is sent via a IRP_MJ_DEVICE_CONTROL packet, the input and output data depend on the IOCTL code that is invoked. The CONTROL CODE is a 32-bit value with several fields, including the field TransferType.

This field indicates how the NtDeviceIoControlFile syscall will return data. There are three different modes for this: METHOD_BUFFERED, METHOD_IN/OUT_DIRECT and METHOD_NEITHER. The first one will copy the caller input data into the user provided buffer. The second version will supply an memory descriptor list (MDL) and ensures that our thread has access to this information. The final one takes in a user-mode address and reads/writes into this with no validation. Of course, the driver uses the insecure METHOD_NEITHER

METHOD_NEITHER by itself is NOT secure. However, the IOCTL handler is responsible for validating, probing, locking and mapping the buffer, depending on the use case. Since this is the case, double fetches, TOCTOUs, bad pointer dereferences and other vulnerabilities may be possible to exploit. Although this is not a vulnerability by itself, it is a code smell that should be checked out.

While reviewing the code handling for these IOCTLs, the author noticed that the size parameter given by the user request was blindly being trusted. Later on, this size was used with a multiplication operation which could easily be overflowed. Additionally, the copy operation was not verified to be smaller than the allocation!

The proof of concept has an allocation size and a copy size. To exploit this, they set the allocation size to be smaller than the copy operation size. Then, when a copy operation happens, a trivial buffer overflow happens with the user controlled write value. Since the data and size are both controlled, this leads to a highly exploitable vulnerability.

An additional point of concern is that the IOCTL does not have any ACL enforcement turned on. This means that the vulnerability can be triggered via several different mediums, such as the browser (if they didn't do their own filtering).

In the disclosure timeline everything seems fairly normal except the vendor that created the library. They claimed to have known about the bug but said that it was not possible to hit the code path because the feature was turned off. After a back-and-forth discussion with them, Eltima eventually pushed a new build with the vulnerabilities fixed. It's not a bug, it's a feature!