To both you and the poster directly before you, I say this:

If I just say "viruses", some dumb chump chimes in to tell me it's "virii". In attempting to avoid that exchange, it seems I've brought the attention of two even dumber chumps.

That is true, the closest thing I have to a manager at my current job (the CEO of the company) can't code worth shit and gets viruses (virii?) all the damn time.

Interesting, indeed. And a positive outcome, karma at work.

No. Just no. You see, I don't care if someone else has intolerant thoughts or opinions, and neither should you; after all, who the hell am I (and who the hell are you) to judge what's in someone's head, when only they know how it got there? So let them vocalize, let them write, let them scream. You don't have to listen to it and you don't have to read it. We have laws for a reason and, if someone's intolerance reaches a level that causes them to violate one or more of those laws, well, that's what the laws are there for. Likewise, there is a reason we don't have laws against holding certain thoughts and opinions, and why free speech is not only not deemed illegal, but an integral part of the US Constitution. If you live elsewhere, of course, that does not apply, but you should still be able to see my point.

And no, you've got that logically backwards: saying it's hypocritical not to eat people just because you eat potatoes is like saying it's hypocritical not to tolerate murder just because you tolerate speeding. Intolerance is a negative, tolerance is a positive; take (and pass) a logic 101 course and you'll learn why that matters.

Wherein did I claim to be victimized by anything? And that's where I stopped reading your post.

It's extremely brilliant, actually. It's useful to have your employees be able to follow the workflow for as many aspects of your company as possible, which often means getting them to work in as many departments as possible. How do you get someone to willingly move from engineering to accounting? A promotion, of course!

Except that these aren't shortcomings of the spec and, in fact, are never presented as such by Nohl and Lell. Quite the opposite, it is stated in their presentation that you (as a user) want these design features, the ability for a device to be multiple things (e.g. a video and audio device, a-la a webcam) and the ability for a device that can't talk to its driver to reattach itself to the bus as a CD-ROM drive to provide the driver. They referred to these as features, not flaws, and very clearly placed the blame on the devices, stating that the fix is to make the devices themselves not reprogrammable. I'm not arguing these points, as Nohl and Lell have already done so.

I was actually referring to you saying the following:

And, in any case, the OS providing virtualized DMA for Firewire (and it is an OS feature, though I'd genuinely love to be wrong about that, so please point me to a source that says I am) does nothing to stop a Firewire device from injecting a rootkit into RAM during the boot process. Virtualized DMA is also no longer Direct, nor is it as fast, so it's really not an ideal solution. Firewire keyboards also exist (the PowerBook Pismo's keyboard was connected via Firewire), as do Firewire webcams (e.g. a Firewire device that's actually two devices), and you can get Firewire ethernet controllers. What that means is that, from a technical standpoint, the only thing I can't confirm without testing devices directly is whether or not I'd be able to find a Firewire device I could reprogram to do exactly what Nohl and Lell did with USB. If one can be found that can be reprogrammed, one can be found to host something akin to BadUSB; let's call it BadWire.

And, that says nothing of Thunderbolt, which many people use for permanently-connected displays and drives. That also uses DMA (in fact, it exposes one or more PCI-Express lanes, depending on which revision of the spec is implemented). A Thunderbolt controller could emulate a flash drive, ethernet controller, and a USB controller with a keyboard attached, and do these very same things. And I think you've missed that, for any of these attacks (via USB, Firewire, or Thunderbolt), an infected device need not be the initial route of infection; that could, instead, be the method of persistence (and re-infection), which negates your argument regarding the Firewire devices you use being more or less permanent.

Of course, that assumes, as Nohl and Lell said, "that [the] devices can be reprogrammed", which, really, is the crux of the attack.

As an aside, you can flash the firmware of a hard disk or SDD via SATA, as well, while the system is booted and operational; while it can't act as a keyboard, it can store a rootkit. And the attack principle is the same: modify the device's firmware.

All of that said, yes, I think we did both learn things here.

Cox ain't half bad in Ohio, where available. From the sound of things, I should be glad we have Comcast (as much as I have them) in Walnut Creek, though; I haven't heard anything good about Astound, either.

They built our network for us, using our tax dollars, and our parents', and our grandparents'. They're only able to claim it as their own because there aren't enough of us who both know that fact and care enough to do anything about it to actually accomplish the task of reclaiming it from them. They should have to lease space on it from the public, just like any other provider wishing to use it.

No, those are both very good sources for information on the problem SRLabs discovered. In fact, I referenced their presentation (one of the links on Bruces post that I suggested you review). Your understanding if the issue at hand is still way off, which is why I referred you to the USB spec, so you can educate yourself. The only way in which a BadUSB "infection" can persist on a host is if that "infection" modifies files on the host, just as with any other infection. It's persistent on the affected USB device, and there's no way to tell if a device is affected by the issue (well, there is, I've mentioned it, but we'll assume you didn't identify the affected device prior to wiping the system it was connected to), which acts as an avenue for continued attack, or re-modification of the same files on the host even after the host has been cleaned up. That's not host persistence through any special means unique to BadUSB; host persistence, again, come from files being modified on the host, as with any persistent infection, while the device remains affected by the issue in order to repeat its attack should the host be cleaned up at a later date. That means the following is incorrect

as it implies that the threat necessarily persists after the hardware is removed. This is only the case is the modified firmware on the USB device (again, this is a flaw in the device, and not all devices allow their firmware to be rewritten) modifies files on the host to make it so.

I haven't seen where BadUSB does, either, but I may be wrong about this. Can I get a direct quote, since it's clearly eluding my eyes? It would be most appreciated. (nay, I have indeed found the quote and will discuss it below)

This line, from the BadUSB homepage (linked from your post) would seem to support your claim of host persistence:

However, when you read the rest of the paragraph, Nohl and Lell go on to elaborate that this is because:

Ah, and there it is, actually, I do see a quote for the claim I questioned just a few lines above:

However, given the understanding of how a BIOS of EFI image would be replaced (this isn't something that can generally be done while a system is booted into an OS; on systems where this is possible, that is a flaw in the BIOS/EFI and not in USB), it becomes clear why keyboard emulation is required; the device would have to emulate a keyboard during boot and send the correct key sequence to enter the BIOS/EFI flash utility, then flash a correct BIOS or EFI image, lest the system fail to boot afterward. Either, or both, of us could be wrong on this point, and we won't know until they release further details, but I'm basing my position on knowledge built over nearly 3 decades of experience, and having read and understood the specifications for the technologies involved.

It bears repeating that a BIOS or EFI that can be written from within a live OS is, itself, flawed, and that is not a flaw in USB. To clarify, on such systems (for example, a Sony VAIO laptop I own, which uses a Windows-based utility for BIOS updates*[1]), malicious software running within the OS can rewrite the BIOS or EFI. That includes a binary stored in "a hidden file on the USB thumb drive" (note the direct quote from your source). It's also a flaw in the BIOS or EFI implementation of the affected system; in the case of BadUSB, it is one that is exploited by a USB thumb drive pretending to be a keyboard in order to send keystrokes to copy and execute a hidden file from its own storage. Again, not a flaw in USB, but a flaw in the device which was reprogrammed to behave as another device.

Since I managed to find that last quote on my own, but I still cannot find any reference to DMA in relation to BadUSB, I'll ask, instead, for a quote or reference for that. Again, greatly appreciated.

Also, for reference, Nohl and Lell's actual presentation, not just the slides. Pay special attention to these highlights:
2:03 where the USB device began emulating a keyboard and deployed a virus onto the system (very visibly)
6:30 where the USB registration process is explained
7:58 where it is explained what is actually being exploited (quoted below, for easy reference, but don't take my word for it, hear it for yourself when you watch the presentation) is explained
8:30 where the process of "infecting" the USB device is explained in depth
the second demo at 14:02 where they demonstrate infection of a stick (where the behavior is very visible, as the device disappears and reappears during the process)
demo 3 at 15:15 where they infect a second system (again, visibly, as they are using keyboard commands sent from the keyboard BadUSB is emulating in order to do anything at all on the host system)
16:42 where it is explained that on a Linux system (due to system architecture, so this will apply on all POSIX-compliant systems, including OS X and the BSDs) they are only able to affect the current user's account and one would require root privileges in order to propagate the infection to a new USB device (though an additional exploit to the screensaver binary, assuming one is in use, is explained, as well)
18:03 where it is mentioned that the emulation target needn't be a keyboard (implying that emulation of other devices is, in fact, what they're talking about; because it is)
18:14 where they demonstrate emulation of a network controller (again visibly, the device shows up as an ethernet controller)
20:36 where it is explained what they tried (and failed) to demonstrate during the 18:14 demonstration; emulation os an ethernet controller and DHCP server to change DNS settings
24:47 where the demonstrate an attack from an Android phone, which creates another network device (as above at 18:14) and implements the attack described at 20:36 (this is actually available on the BadUSB homepage)
28:14 where they actually do give details regarding the BIOS/EFI exploit, which incidentally match up with what I explained above, requiring that the computer be booted from the stick; though, they do take a different direction and load a rootkit prior to booting, rather than reflashing the BIOS/EFI, and they optionally emulate a keyboard to force booting from the stick if necessary (note that reflashing the BIOS/EFI would also be possible at this point, I'm not denying that; in fact, it's exactly what I said, above)
32:25 where the mechanism of persistence is explained, precisely as I described it above; re-infection via the infected USB device
34:20 where defenses are discussed; especially:
38:53 where disabling firmware updates on USB devices is mentioned, even touted as the ideal solution, evidence, again, that this is a device issue (as alluded to at 7:58)

They very clearly explain what they're exploiting, here, and it does, in fact, require cooperation of the host system "that the computer does not know how many devices are currently connected and that they can change their persona at any point in time [...] assuming, though, that USB devices can be reprogrammed (quoted from 7:58)". They also make it clear (during the 8:30 explanation) that it took considerable work to work their exploit into the firmware of the device. One can extrapolate from this that the work is not only device-specific, but firmware-specific; that is to say, the code that infects one USB device will not work on another, and it may be noticed that the firmware version has changed if the work was done against a different version of the firmware, even for the correct device.

In short, per their actual presentation as presented at BlackHat 2014, it is exactly as I say, reprogramming a USB device to behave as another device, fully with the cooperation of the host system (including the OS or, during boot, the BIOS/EFI). They are not native English speakers, so you can't fully rely on their written word to be fully accurate; watching the actual presentation should clear up the facts for you, though. Definitely watch it through the end, paying close attention to the last thin that is said as the video fades out.

Really, familiarize yourself with the USB spec, then apply that knowledge to what you already know of the security vulnerabilities discussed in the articles we've both linked to. For the record, Wired isn't exactly a first-class source.

In fact, only one theoretical attack, based on a host controller violating the USB spec, occurs before the OS is in play (for purpose of a USB keyboard, the BIOS or EFI is the OS). This was discussed earlier in this very post and it is not BadUSB.

Wow! Now that is BadUSB! And if it spoofs a keyboard, it can do anything a keyboard can do. Nothing more. You can do some pretty awful things with a keyboard (as you've shown), but nothing on the level you're freaking out about. Spoofing a network adapter and sniffing and logging network traffic (think 3TB external drive with a reprogrammed controller, plenty of potential storage space) is a much more effective means of attack, also possible via BadUSB. But, again, it requires cooperation from the host and the network interface would be a listed device. You could sniff bus traffic, as well, I suppose, but at that point, why not just spoof a device whose driver implements DMA and rifle through RAM looking for the data you're after?

Actually, it's wholly incorrect in the context of reprogramming a host controller that violates the USB spec, or a device that sniffs bus traffic between insertion and timeout. It's spot on in the context of BadUSB.

Unless I'm misinterpreting this:

you, sir, are wrong. That's what BadUSB is, reprogramming a device to behave as another device. Nothing more. Does it enable a variety of attack vectors that were previously impractical? Yes. But it doesn't do so entirely silently. I suggest you familiarize yourself with the USB spec to further your understanding on this matter.

In theory. In practice, it is the controllers on the devices that are being left in a programmable state; host controllers conforming to the spec aren't programmable from the USB bus, so a system susceptible to such an attack would be so in spite of the USB spec, not as a result of it. This is not BadUSB.

Yes, as with any serial bus. However, the spec allows for shutting down ports with no recognized device connected, so the device would have to be recognized, or the host controller not compliant with the spec, for this attack to work. This is not BadUSB.

Indeed, a device can come up on the bus and sniff traffic until the host shuts it down after a timeout. It'll take a few removals and reinsertions to get the data your after, having to sniff in 500ms increments. Theoretically, this could work, but it's not practical as it requires an immense amount of cooperation from your victim; though, retrieval of the sniffed data would be as simple as picking the device out of their trash when they throw it away, thinking it's broken. Also, this is not BadUSB.

Slashdot doesn't like posts with too many quote blocks in them, so I have to break up this reply.

BadUSB, by name, is a specific attack that requires cooperation of the host.

And there's our problem, yes. Perhaps, now that we've identified that, it's worth continuing this conversation.

But it does eliminate the threat we're discussing here.

Financing a group isn't intolerance, it's quite the opposite, you're showing tolerance and acceptance of that group. Financing a group that promotes intolerance may be an intolerant action toward who- or what- ever that group is intolerant of, and that may be rightly actionable. In general, I think I agree with the point you were attempting to make, but I can't be sure as you didn't really succeed in making that point.