USB driver bug exposed as "Linux plug&pwn"

Rafael Dominguez Vega of MRW InfoSecurity has reported a bug in the Caiaq USB driver which could be used to gain control of a Linux system via a USB device.

The bug is caused by the device name being copied into a memory area with a size of 80 bytes using strcpy() without its length being tested. A crafted device with a long device name could thus write beyond the limits of this buffer, allowing it to inject and execute code. Because the driver is included, and automatically loaded, in most Linux distributions, to execute code in kernel mode an attacker would merely have to connect such a device to a Linux system's USB port.

MRW says that it has assembled a suitable USB device for this purpose, boasting in a Tweet of a "Linux plug&pwn". Their derision is not entirely misplaced – buffer overflows arising from the use of strcpy() are something of a 20th century problem. Microsoft, for example, placed the function on its list of banned function calls some years ago, with the result that developers can no longer check in code containing the incriminating function. The fact that this function call was used in a Linux kernel driver and only replaced by the safer, length checking strlcpy() on 14 February 2011 is not a ringing endorsement of its quality.

To exploit this vulnerability, an attacker would nonetheless require physical access to the target system. Despite this limitation, such vulnerabilities are apparently highly sought after. US security company HBGary developed a complete framework for spying on and compromising computers via USB, FireWire and other ports under the codename Task B. The main customer for this was defence contractor General Dynamics, which supplies a range of US military and secret service agencies. Target price: around $400,000.

In one email, a General Dynamics employee described two key deployment scenarios: the first of these envisages a person leaving their laptop unattended in a locked state, allowing an attacker to briefly insert and then remove an appropriate device. In the second scenario the device is secretly inserted into a dormant PC, where it will hopefully remain undetected when the computer is turned back on and can be collected at a later date. Both scenarios are able to bypass full hard drive encryption, as the computer is accessed when on, with the system transparently decrypting all files.

(crve)