This article is severely lacking in actual information. They also make no distinction between Windows, Macs, or Linux. I seriously doubt that if I plug in an infected USB device to my Linux laptop its firmware will be able to alter the DNS settings (/etc/resolv.conf which is owned by root). That sounds like a very OS-specific (probably Windows-specific) vulnerability. My best guess is it has something to do with the "automated whether you want it to be or not" printer driver installation mechanism whereby Windows PCs inherently trust the driver that's provided by the device.
The ability to modify the data as it's copied seems like the only actual vulnerability to me. As in, I write some executable to the USB drive and the firmware modifies the executable to perform other functions. Once the file is copied off of the device though it should be pretty easy to detect such shenanigans with something as simple as a hash check.
You could also have separate flash storage on the device that isn't visible to the OS where you could store whatever data you want but that's less of a concern when you consider that a perhipheral like a keyboard can't record the keystrokes of another perhipheral (not directly, anyway--you'd have to get the user to execute some malware).
This kind of attack has been around for some time, but so far you needed a special, programmable chip for that. And yes, it can attack nearly every OS, including Linux.
The USB Rubber Ducky just emulates a keyboard. That's not a vulnerability, really. Unless I'm actively logged in it won't compromise anything. It just speeds up the process of installing back doors (and the like) if you've already got physical access to a system that is already logged in.
I could do the same with any $5 Arduino Leonardo device (of which I have several).
I agree that more detail is needed. (Somehow when they said network sniffing I thought maybe the thing presented itself as a NIC. I dunno.)
However, let's not get too dismissive. I always remember reading about the security problems in firewire for example. These were OS independent. A malicious device could do DMA into the host machine without the OS being able to validate. This type of hardware design issue leading to security problems is not unheard of.
Lastly, printer drivers? Huh? Can you point at an actual Windows feature that is currently shipping or are you thinking of 1990s Windows and autorun? When you plug in a device these days, it will check Windows Update based on the device ID but I am not aware of anything that will trust unverified code coming from elsewhere without the user doing something.
There's a reason why you have to add printer drivers to shared printers... Windows will install those automatically. The same mechanism can work for a USB device but I forget the details (it's been a long time). I remember reading about it when that signed driver from HP had a serious privilege escalation vulnerability back in the day (it let you gain "Trusted" level access which was higher than "Administrator" which basically meant re-imaging was the only option to correct such a compromise).
Also, if you configure your USB device to emulate certain other devices those drivers will also be installed automatically via Windows Update. Such drivers may have vulnerabilities or just flat out provide all sorts of privileged access to the system. It's not that complicated, actually... Just change the USB device manufacturer/ID and let Windows compromise itself.
If the bar is loading a vulnerable driver, Linux has a lot of drivers for uncommon devices in-tree. Sure, they are open and largely not written by hardware manufacturers, but I bet some of them are vulnerable to malicious hardware.
It's easy to make a USB device to randomly type dangerous things, open URLs and download, then start applications (anything you could do with a keystroke). That sort of thing is achievable with an Atmel chip wired to a USB plug. See http://macetech.com/blog/?q=node/46
I don't know whether it's possible for such a device to snoop on other devices. I suspect not, unless it is a hub which contains the bad firmware. It might be interesting for capturing passwords, then playing them back later.
Of course any device could compromise the device driver using buffer overflows, etc, to gain control of some aspect of the computer.
The initial access patterns to the device are likely to be different for different platforms, which should permit OS detection. Now it can launch a tailored payload - for instance, on Gnome, something like:
a) present as keyboard
b) windows key terminal enter
c) cat >.libevil.so.base64 <<EOF
d) dump a base64 library in there
e) base64 -d .libevil.so.base64 >.libevil.so
f) echo "LD_PRELOAD=~/.libevil.so" >>.bash_profile
g) exit
h) turn into a USB mass storage device again
I have written firmware for USB devices. These attacks are a genuine threat, because a USB device can pretend to be whatever it has to be to get the OS to load an exploitable driver, and then the exploited system can infect other USB devices by rewriting their firmware.
The ability to modify the data as it's copied seems like the only actual vulnerability to me. As in, I write some executable to the USB drive and the firmware modifies the executable to perform other functions. Once the file is copied off of the device though it should be pretty easy to detect such shenanigans with something as simple as a hash check.
You could also have separate flash storage on the device that isn't visible to the OS where you could store whatever data you want but that's less of a concern when you consider that a perhipheral like a keyboard can't record the keystrokes of another perhipheral (not directly, anyway--you'd have to get the user to execute some malware).