DoS attack on MS Windows XP using a USB device
Having worked closely with the USB bus for many years and implementing devices of all kinds of classes, I have compiled a rather large list of various jokes in the bus behavior. In the process of debugging, everything that was possible fell, and most importantly, standard drivers from the standard delivery of MS Windows. The standard classes of devices took me to the blue screen, the drivers USBHUB.SYS, USBHID.SYS, USBCCID.SYS (the latter was generally full of hell) fell. However, in most cases, the manifestation was complex and required action from the user on the PC itself.
But one case still attracted a lot and I saved the “important” firmware of the device for analyzing and highlighting the problem. So, I present to your attention a USB device that literally carries out a DOS attack on a system running Windows XP 32-bit (also tested under Windows 2003 Server 32-bit). Windows Vista does not seem to be affected by this problem.
So, after connecting the device to the USB port, regardless of the startup settings and whether the user session is blocked or not, the System process begins to eat up a decent amount of processor time. On a single-processor system, this is all 100% (that is, the system is almost hung up), on 2 or more processors the system externally remains fully operational and responsive, but still in the Task Manager it is clear that not everything is “thank God”. Moreover, after removing the device, the effect is preserved! It remains only to reboot the system, and with the reboot, not everything is smooth, it seems that the work is completed, but the reboot / shutdown itself does not occur, the system remains on a blank screen with a cursor.
In continuation of this, all new plug-in USB devices are also not detected in the system. Apparently, the service that is responsible for the process of determining the device is hanging.
Here's what you can see in Windows 2003 Server 32-bit after connecting to the Task Manager: I bring the finished firmware for the NXP LPC214x microcontroller. Made on the basis of the LPCUSB stack. The firmware is tested on a standard Keil MCB2140 debug board. You can get the firmware here , in the archive there is a HEX file ready for uploading to LPC214x and a firmware project suitable for assembly 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 thing is in the incorrectly formed USB descriptor. Note:
USB descriptors are a set of structures that describe a USB device. In the process of initializing the device, the host requests this 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: there is a field in the configuration descriptor that describes the total size of the descriptors responsible for the device configuration (this includes the configuration descriptor, interface descriptor, class descriptor, and endpoint descriptors). So, this value in the process of editing descriptors was accidentally set to be erroneous: seriously overstated, in this example, instead of 0x29, 0x200 was set.
This field is for some reason not being processed correctly. I did not carry out deeper studies, it may not be enough just to overestimate the value and some specificity of the stack's work in this emergency situation is affected, which is why I cited the link to the full firmware above.
I leave the conclusions about the presented problem to your conscience. I can only say from myself that the main weak point is that “physical contact” with the attacked machine is required. For this reason, the danger of this error in the USB stack of the operating system in most cases is not great. Servers should be in a room with limited access, and for the average user, such a "joke" is likely to be simply 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 OSes on hand. On the existing machine under Windows Vista, no freezes occurred; it qualified the device as fully functional (apparently, it does not use the value of this field at all).
But one case still attracted a lot and I saved the “important” firmware of the device for analyzing and highlighting the problem. So, I present to your attention a USB device that literally carries out a DOS attack on a system running Windows XP 32-bit (also tested under Windows 2003 Server 32-bit). Windows Vista does not seem to be affected by this problem.
So, after connecting the device to the USB port, regardless of the startup settings and whether the user session is blocked or not, the System process begins to eat up a decent amount of processor time. On a single-processor system, this is all 100% (that is, the system is almost hung up), on 2 or more processors the system externally remains fully operational and responsive, but still in the Task Manager it is clear that not everything is “thank God”. Moreover, after removing the device, the effect is preserved! It remains only to reboot the system, and with the reboot, not everything is smooth, it seems that the work is completed, but the reboot / shutdown itself does not occur, the system remains on a blank screen with a cursor.
In continuation of this, all new plug-in USB devices are also not detected in the system. Apparently, the service that is responsible for the process of determining the device is hanging.
Here's what you can see in Windows 2003 Server 32-bit after connecting to the Task Manager: I bring the finished firmware for the NXP LPC214x microcontroller. Made on the basis of the LPCUSB stack. The firmware is tested on a standard Keil MCB2140 debug board. You can get the firmware here , in the archive there is a HEX file ready for uploading to LPC214x and a firmware project suitable for assembly 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 thing is in the incorrectly formed USB descriptor. Note:
USB descriptors are a set of structures that describe a USB device. In the process of initializing the device, the host requests this 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: there is a field in the configuration descriptor that describes the total size of the descriptors responsible for the device configuration (this includes the configuration descriptor, interface descriptor, class descriptor, and endpoint descriptors). So, this value in the process of editing descriptors was accidentally set to be erroneous: seriously overstated, in this example, instead of 0x29, 0x200 was set.
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 for some reason not being processed correctly. I did not carry out deeper studies, it may not be enough just to overestimate the value and some specificity of the stack's work in this emergency situation is affected, which is why I cited the link to the full firmware above.
I leave the conclusions about the presented problem to your conscience. I can only say from myself that the main weak point is that “physical contact” with the attacked machine is required. For this reason, the danger of this error in the USB stack of the operating system in most cases is not great. Servers should be in a room with limited access, and for the average user, such a "joke" is likely to be simply 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 OSes on hand. On the existing machine under Windows Vista, no freezes occurred; it qualified the device as fully functional (apparently, it does not use the value of this field at all).