BadUSB security flaw (massive undetectible USB reprogramming vulnerability)

  • Thread starter Thread starter bob mullen
  • Start date Start date
Paul said:
Yes, I'd heard of the Firewire (1394) attack, but never USB.

Even with USB OTP, there would be a negotiation process
before some kind of endpoints were set up. I don't know
any details of OTP, so don't know if there are any
weird exposures there. I would expect a driver to work
the negotiation, rather than logic gates in hardware
to do it.

Paul

s/OTP/OTG

OTG = On The Go

Helps to sound them out, before posting :-)

Paul
 
John said:
Most. That's their business.

Seems reasonable to me for the OS to accept the first keyboard and mouse
that offer themselves

That could be because if the OS were to ask first, the user would have
no way of answering.
 
William said:
["Followup-To:" header set to alt.os.linux.]
bob mullen wrote:

Massive, undetectable security flaw found in USB
http://www.extremetech.com/computin...-to-get-your-ps2-keyboard-out-of-the-cupboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages
the fact that every USB device has a controller chip. Whether it???s your PC,
smartphone, external hard drive, or an audio breakout box, there???s a USB
controller chip in every device that controls the USB connection to other
devices.

Every computer hardware interface has a controller. You thought the
wires and foils handled the logic?

Yes, And?
It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things ???
and, perhaps most importantly, this reprogramming is almost impossible to
detect."

Same for the EEPROM holding your BIOS.

Yes, but someone can lend you a usb stick to stick into your computer,
subverting it. They cannot stick their eeprom into your machine, nor can
they install junk on your eeprom without you perhaps noticing that they
have your computer.

Reprogrammers have to run. That would be for EEPROM writing as well as
USB controller firmware updating. USB drives have been a sore point
regarding security. Smart users disable auto-run on removable media
devices. Thereafter the user would have to be conned into running a
program so it could reprogram the BIOS or the USB firmware, or a NIC
with firmware, or anything else with reprogrammable firmware.

I plugged a USB Sony camera into my PC, and it installed a
load of crap. Had to restore from a backup.
I have all autoruns turned OFF.
Windows XP updated to SP3. Probably that's why I noticed it, I
don't have the latest "security patches".
;)
[]'s
 
Gene said:
How many users will simply click Yes just as they do with so many
other arcane prompts?
Most. That's their business.
Seems reasonable to me for the OS to accept the first keyboard and mouse
that offer themselves

Mike said:
That could be because if the OS were to ask first, the user would have
no way of answering.

The point is that there is no good reason for it to accept any keyboards
after the first without getting permission from the user. The few users
who intentionally connect a second keyboard will know what to do.
 
Gene said:
Let's hope that Ron doesn't see your edit command :-)

Yes, it probably should have been s/OTP/OTG/g or something :-)

Somewhere, a secret agent is trying to break our "code" :-)

Paul
 
A keyboards is *not* a removable-media device.

Optical and hard disk drives, thumb drives, & flash cards are removable
media...

And from what I read, they can reporgram the flash drive to present
itself as a keyboard to the computer, and the firmware can then type in
commands to your machine.
 
But maybe I'm wrong in thinking the firmware can't execute as a keyboard
unless the drive is configured to autorun.

I'm willing to learn...Or at least have my mind boggled.

The firmware is always run. autorun is for running programs in the
memory of the flash drive. Firmware is for running the base
instractions of the device and is always run. That as I understand it is
why this is considered such a serious problem.
 
Gene said:
[snip]
The quickest solution, is to add a prompt to the "new hardware"
dialog.

"I think you have added a USB Mass Storage device"

"This device appears to be a web cam. It claims a composite
device block at the top level, with one UVC video device and
one audio device underneath that top level."

"Do you want to accept connection via these classes only ? Y/N"

How many users will simply click Yes just as they do with so many
other arcane prompts?

[snip]

Sincerely,

Gene Wirchenko

The OS side has ultimate control. A bugged device cannot
force an endpoint connection. It is up to the OS to set it
up.

Either the OS or AV code, could hook the routine that
sets up new USB devices. If the characteristics of the
devices were recorded by the manufacturers of them,
an AV code could simply deny the connection entirely,
then present a dialog box indicating what has happened.
The only time the user sees a dialog in this case,
is when the thing they plugged in, doesn't work at all.

Using the user as a filter, avoided the need for a
central registry. But if you wanted to do the
extra work, you could simply lock out devices
that don't match their hardware template (i.e.
Logitech 9000 has composite+video+audio but no HID).

Paul

But since the OS has no way of knowing this is a bugged device, why
would it refuse, eg to connect a keyboard?
The OS would need a HUGE list of the devices, and the firmware could
simply pretend to be one of them. The only way the OS knows what the
characteristics is of the device is by saking the firmware to report.
 
bob mullen said:
Massive, undetectable security flaw found in USB
http://www.extremetech.com/computing/187279-undetectable-indefensible-se
curity-flaw-found-in-usb-its-time-to-get-your-ps2-keyboard-out-of-the-cu
pboard

"This flaw, dubbed BadUSB by Security Research Labs in Berlin, leverages

(I always rate less anything written by anyone who uses the word
"dubbed" [other than when describing a knighting!], but let's assume
that's just the journalist.)
the fact that every USB device has a controller chip. Whether it¡¦s your PC,
smartphone, external hard drive, or an audio breakout box, there¡¦s a USB
controller chip in every device that controls the USB connection to other

The size of that list has a whiff of FUD-spreading about it.
devices. It turns out, according to SR Labs, that these controllers have
firmware that can be reprogrammed to do a whole host of malicious things ¡X
and, perhaps most importantly, this reprogramming is almost impossible to
detect."

While not denying that some may be reprogrammable, I very much doubt all
are: certainly I'd be surprised if, say, the USB hub or card reader I
might buy at the poundshop/99p store would have such.

That's not to say - especially if your tinfoil hat is in good order -
that the _non_-reprogrammable firmware in such devices might not have
been _manufactured_ with such in it - though I personally don't think
I'm going to worry about it yet.
 
William Unruh said:
For a keyboard?
I have neer been asked if I want my keyboard attached.
Vanguard and cranky were talking about the autorun option; I agree with
them that this should be _off by default_, maybe with a one-time prompt
for the first time the user inserts something with an autorun.
[Actually, the one-time could offer "disable", "always allow (not
recommended)", and "always ask".]

Turning off autorun will not, I'm pretty sure, stop a keyboard being
recognised.
[]
??? It is a keyboard. What harm could there be in a keyboard? :-)
1. True (or not, see 2), but something else (a camera, card reader, ...)
could present itself as two devices - what you think it is, _and_ a
keyboard, and then "type" things into the computer.
2. Even a keyboard could (in theory!) have its controller hacked to do
more than you expect (such as type more than you are typing).
 
Gene Wirchenko said:
[snip]
The quickest solution, is to add a prompt to the "new hardware"
dialog.

"I think you have added a USB Mass Storage device"

"This device appears to be a web cam. It claims a composite
device block at the top level, with one UVC video device and
one audio device underneath that top level."

"Do you want to accept connection via these classes only ? Y/N"

How many users will simply click Yes just as they do with so many
other arcane prompts?

Indeed; it would be better with tickboxes (default off of course). (The
multilevel you describe done with indents, the indented ones being
greyed out until the top one is enabled.)
[snip]

Sincerely,

Gene Wirchenko

Note: Gene is very unusual - actually, I'd say possibly unique! - in
posting posts that _don't_ have any extra (and IMO spurious) blank lines
at the end! (I think even my software adds one [before the separator I
mean]!)
 
John said:
The point is that there is no good reason for it to accept any keyboards
after the first without getting permission from the user. The few users
who intentionally connect a second keyboard will know what to do.

Oh, I thought the point was that the first keyboard and mouse should be
accepted automatically, so I gave what I thought was a plausible reason
for that.

But let's say that subsequent keyboards and mice (mouses?) required
confirmation from the user. Now, my bluetooth dongle suddenly stops
communicating with my keyboard and mouse. So I get a replacement. What next?

Just playing devil's advocate. I hope there's a good answer.
 
In message <[email protected]>, Mike Barnes
Oh, I thought the point was that the first keyboard and mouse should be
accepted automatically, so I gave what I thought was a plausible reason
for that.

But let's say that subsequent keyboards and mice (mouses?) required
confirmation from the user. Now, my bluetooth dongle suddenly stops
communicating with my keyboard and mouse. So I get a replacement. What
next?

Just playing devil's advocate. I hope there's a good answer.
I was going to say that it still would be prompting the user, even if
the acceptance came from the new keyboard.

But then it occurred to me that whatever the system prompts for, any
black had pseudo-keyboard could send - i. e. it could appear as a second
keyboard, then "type" a Y!

The way round that would be for the OS to say "a second keyboard has
been detected - type # on it to enable it", where # was _a random key_
(and the OS only looked at the _first_ key sent from any such to stop it
just sending all of them). But that sounds too complex.

I like playing devil's advocate too, and the challenge you raised! I
think my answer works. (Especially if it prompted for a combination.)
 
William said:
But since the OS has no way of knowing this is a bugged device, why
would it refuse, eg to connect a keyboard?

Because it already connected to one keyboard when it booted.
 
Mike said:
Now, my bluetooth dongle suddenly stops communicating with my keyboard
and mouse. So I get a replacement. What next?
You reboot.

But of course if you are using Bluetooth to connect your keyboard you
oviously don't care about security anyway.
 
A built-in hub might have DMA. I don't see how an endpoint device
could. On the other hand, as it would be idiotic to allow
externally-pluggable devices DMA, I would not be surprised if pc
manufacturers have done so.


USB is not mentioned.

A usb controller is a pci device, so has dma access.

Regards, Dave Hodgins
 
David said:
A usb controller is a pci device, so has dma access.

A controller does. A device plugged into it does not, any more than
does a device at the other end of an ethernet cable.
 
A usb controller is a pci device, so has dma access.

Regards, Dave Hodgins

What about these "U3" USB devices? Seems to me I returned an external
hard disk because it would automatically install some type of device
driver to control encoding backup data to the disk using the software
included on the disk when purchased. There was also some kind of
partition on the drive would show as a cd drive presumably so it
couldn't be written to. Windows would automatically load a driver off
this "cd" regardless of the "Auto Insert" setting.
 
Back
Top