#badbios redux? I seem to recall it was suspected that badbios started with an infected USB stick.
On 8/1/14, Ted Unangst <t...@tedunangst.com> wrote: > You may have heard about the "badusb" talk coming at blackhat. In > theory, we should wait to watch the talk and see what it's actually > about, but since some people can't wait that long, here's a few > thoughts. (I'm a little surprised nobody has asked here already. I have > some time free, thought I'd beat the rush. :)) > > The claims on the main page, https://srlabs.de/badusb/, are fairly > reasonable if a little vague. Other claims I'm reading elsewhere > appear a little overhyped. In order of increasing danger... > > 0. The final claim is that once infected, you'll always be infected > because disinfection is nigh impossible. Meh. The same could be said > of the firefox exploit of the week. It too can reprogram your bios or > persist itself in any number of ways. > > 1. They're exploiting all manner of Windows specific autorun > functionality to install or configure drivers. By default, OpenBSD > will do just about nothing when a USB device is plugged in, so this is > not a serious concern. > > 2. They have created a rogue keyboard device which will type naughty > commands. In theory, the same keyboard could type "rm -rf ~" into an > xterm. This is a tiny bit more challenging since it probably depends > on your desktop environment and window manager, but presumably your > attacker will know all that. So yeah, vulnerable. But at the same > time, I could also train a monkey to type that command and strap it to > your normal not backdoored keyboard. Beware the badmonkey attack, too. > > 3. A storage device may lie about the contents of a file. Sometimes it > will say one thing (so it looks safe on this computer), sometimes it > will say another (so it installs a backdoor on that computer). Don't > install OpenBSD from media you don't control. Technically, signing the > sets won't help since the backdoor installer might have a bogus key on > it (or a bogus installer that doesn't check). You can always pxeboot > and hope that the firmware in your ethernet card is more trustworthy. > > They don't appear to mention two other avenues of exploitation, > which may be more practical. I refer specifically to OpenBSD, > though there's no such limitation. First, the USB stack has a number > of known races and other bugs, especially around attach/detach and > error handling. If a rogue device attached and detached itself several > times, it could likely corrupt the kernel heap. Game over. > > Second, any USB disk, even one with a normal firmware, can have an evil > filesystem image on it. By this, I mean the metadata that the kernel > reads is corrupt, not that it has naughty files. There have been crash > reports when mounting corrupted (and even not corrupted) (e.g.) > MSDOSFS disks. The kernel is a little too trusting that a filesystem > is what it claims to be. There are probably exploitable vulns here, > too. > > All that to basically say "don't panic" (that's the kernel's job). > Fixing filesystem bugs is something we'll do, of course, but it's not > a priority for me to sit down and start fuzzing Right Now. Same for > miscellaneous bugs in the USB stack.
