The Scottish design firm FTDI has used Windows Update to push a malicious driver that identifies counterfeit chips modeled after FTDI’s design. The chip in question is an RS-232 to USB converter commonly found inside pre-built, finished products widely available for order online, as well as sold in hobbyist projects such as Arduino. The new driver intercepts the intended input and output between the connected device and PC, and replaces it with arbitrary data. As such, the victims in this scenario are the purchasers of finished products or DIY kits who have unknowingly purchased products thought to be genuine, which worked properly prior to driver interference by FTDI.
How the driver targets counterfeits
This driver update sends the signal “NON GENUINE DEVICE FOUND!” instead of functioning normally. This isn’t a dialog box being presented to the user–the driver actually sends this message as arbitrary data when connected to a computer with the malicious driver. (Generally, this is not visible to an end-user.) With the continued use of RS232 devices in industrial control equipment–heavy machinery, electrical grid monitoring, among other uses–transmitting arbitrary data in the pursuit of fighting counterfeiting introduces a risk potential for personal injury, equipment damage, or industrial accident. There is a substantial difference between programming a driver to refuse to work with counterfeit chips (zero response), and programming a driver to actively interfere with the normal functioning of a given device.
This isn’t the first time FTDI has used Windows Update to inhibit the functioning of counterfeit chips. In October 2014, FTDI pushed a driver via Windows Update which identified the counterfeit chips, and set the PID (Product ID) to zero, making the device unidentifiable to the driver. As a result, uninstalling the offending driver will not return the devices using this chipset back to a usable state. Even if the device is plugged into any other computer, running a different operating system, the device will still be inoperable unless the PID is rewritten to the correct value. Although the device is not completely unrecoverable, the resulting effect is that the device is bricked, to the extent that an average user would not have the ability to restore the PID. This update was later pulled after user complaints.
Why this is a problem
Given that the affected devices worked with the driver prior to FTDI’s interference, and likely worked long enough that the devices in question are now out of warranty, end users of the affected products are the victim of such interference. Additionally, considering the nature of supply chains, it is entirely conceivable that companies thinking they have purchased legitimate parts are now being impacted as well. With the difficulty of ensuring that components in a supply chain are genuine, this action by FTDI serves as a disincentive to use any part labeled FTDI in the future.
Ultimately, this situation only exists because Microsoft has allowed it to happen. Microsoft is supposed to verify that driver updates work properly through Windows Hardware Quality Labs (WHQL) testing, but has failed twice to catch FTDI’s abuse of driver updates. This problem has been exacerbated by the Windows 10 update policy obliging users to install updates, limiting the ability of Windows users to use devices they have paid for–devices that continue to work perfectly fine on Linux.
Why this is Microsoft’s problem
In providing driver updates via Windows Update from third-party vendors, Microsoft has an obligation to ensure that the drivers they distribute do not intentionally break devices that worked prior to the update. FTDI should have lost their WHQL certification for the bricking incident in 2014. FTDI’s new tactic of sending arbitrary data is not, however, appreciably better than bricking hardware–this is a very rare case in which silently failing would be preferable, due to the use cases of the hardware in question. As it stands, Microsoft negligently allowed a third-party vendor to interfere with the normal functioning of hardware purchased by the user.
Although it is not directly Microsoft’s fault, this exacerbates the preexisting issue of Windows 10 updates lacking any public description of value. The extent to which end users lose control over what their PC does in regard to software updates is too aggressive, particularly in cases where Windows updates cause infinite boot loops, break display drivers, or in the case of FTDI, break devices that happen to use a specific component. This is an obvious conflation of two distinct issues, but the loss of control over updates combined with the troubling privacy implications surrounding the OS should give pause to power users expecting a semblance of reliability or security in their ability to control their computer.
What’s your view?
Have malicious driver updates rendered hardware you have purchased unusable? Has Microsoft’s compulsory update model in Windows 10 caused you reliability headaches? Have you delayed or opted out of a Windows 10 migration due to control and reliability issues? Share your experiences in the comments.