DoS attack on MS Windows XP using a USB device

Working closely for many years with the USB bus and realizing devices of all kinds of classes, I scored a rather large list of various jokes in the bus behavior. In the process of debugging, everything that was possible fell, and most importantly the standard drivers from the standard MS Windows delivery. I was taken to the blue screen by standard class devices, the USBHUB.SYS, USBHID.SYS, USBCCID.SYS drivers (the last one is full of holes to the hell) fell. However, in most cases, the manifestation was difficult and required action from the user on the PC itself.

But one case nevertheless attracted me very much and I saved the “important” device firmware for analyzing and isolating the problem. So, I present to your attention a USB device that literally performs a DOS attack on a system running Windows XP 32-bit (also tested under Windows 2003 Server 32-bit). Windows Vista this problem seems to be not affected.


')
So, after connecting the device to the USB port, regardless of the startup settings and regardless of whether the user session is blocked or not, the System process begins to eat off a decent amount of processor time. On a uniprocessor system, this is all 100% (i.e., the system is practically hung up), on 2 or more processors, the system apparently remains fully functional and responsive, but still in the Task Manager, it is clear that not all is “thank God. Moreover, after removing the device, the effect is preserved! It remains only to reboot the system, and not everything is smooth with the reboot, the work seems to end, but the reboot / shutdown does not occur directly, the system remains to hang on a blank screen with a cursor.

In continuation of this, all new USB connectable devices are also not detected in the system. Apparently, hangs the service responsible for the process of determining the device.

Here is what you can see in Windows 2003 Server 32-bit after connecting in Task Manager:



I bring the finished firmware for the NXP LPC214x microcontroller. Made on the basis of the LPCUSB stack. Firmware tested on Keil MCB2140 standard debug board. You can take the firmware here , there is a HEX file in the archive, ready for uploading to LPC214x and a firmware project that can be built in Keil RealView MDK version 4.00 and higher (you can use the environment in demo mode).

Now about the essence of the problem and the conditions of occurrence: the whole thing is in an incorrectly formed USB descriptor.

Note: USB descriptors are a set of structures that describe a USB device. During the device initialization process, the host requests the given descriptor, processes it and, in accordance with the received information, initializes the device (finds the necessary driver, obtains device settings, sets string constants, etc.).

To be more precise: in the configuration descriptor there is a field that describes the total size of the descriptors responsible for the device configuration (this includes the configuration descriptor itself, the interface descriptor, the class descriptor and the endpoint descriptors). So, this value in the process of editing descriptors was accidentally set wrong: seriously overestimated, in this example, 0x29 is set to 0x200.

---

  0x09, // bSize
	 DESC_CONFIGURATION, // bDescrType
	 // LE_WORD (0x29), // wTotalLength
	 LE_WORD (0x200), // wTotalLength
	 0x01, // bNumInterfaces
	 0x01, // bConfigurationValue
	 0x00, // iConfiguration
	 0x80, // bmAttributes
	 0x32, // bMaxPower 

---

This field is incorrectly processed for some reason. I didn’t do any more in-depth research, it may not be enough to just overstate the value and it is affected by some specific features of the stack operation in this emergency situation, which is why he cited the above link to the full firmware.

I leave the conclusions on the presented problem on your conscience. From myself I only note that the main weak point: requires "physical contact" with the attacked machine. For this reason, the danger of this error in the USB stack of the operating system is in most cases not great. Servers should be in a room with limited access, and for the average user such a “joke” will most likely be just unpleasant.

It would be nice to understand what other versions of MS Windows react so painfully to this incorrect descriptor. I checked on 3 machines under Windows XP and one under Windows 2003 Server (with a full set of all updates), unfortunately there are no 64-bit operating systems at hand. On the existing machine under Windows Vista, no hangup occurred, she qualified the device as fully functional (apparently, she does not use the value of this field at all).