BadUSB security flaw (massive undetectible USB reprogramming vulnerability)

David W. Hodgins wrote:
On Sat, 02 Aug 2014 17:28:13 -0400, Paul wrote:

David W. Hodgins wrote:
On Sat, 02 Aug 2014 11:36:50 -0400, John Hasler
wrote:

David W. Hodgins writes:
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.
According to Bruce Schneier, a well known security expert, they can
https://www.schneier.com/blog/archiv...g_compute.html

That is Autoruns, and not DMA.

Read it again ...

and the ability of peripherals to use something called direct memory
access (DMA). ...
is the result of a design flaw that's likely to be with us for many
years to come

If a usb device could not access dma, then usb external hard drives would
be painfully slow, since they would be suck in pio mode.

Regards, Dave Hodgins

There is one comment in the Schneier article, asking the same
question I am. Namely, that Firewire has the RDMA capability,
and USB does not. Nobody responded to this.

"Lotharster June 9, 2006 5:34 AM

I'm not sure if USB can actually use DMA. AFAIK, Firewire can
use DMA, but USB cannot. Can anybody confirm this?
"

USB peripherals only respond to queries, or
give acks on a write. There is no RDMA on USB, because
it's not a peer to peer technology. The peripheral cannot
say "give me data from physical address 0x12345678".
The peripheral does not possess the ability to initiate
a transaction. Only when the host polls at regular intervals,
does the peripheral get a chance to talk. The host can send
data to the peripheral, as long as the peripheral completed
it's last transaction and is ready for it. The host side
DMA structure, the addresses used, are controlled by the
host driver, with no reason to modify the DMA structures
on some request from the peripheral ("move your buffer
to 0x12345678").

The article by Simson Garfinkel, gives no references to this
purported USB mechanism, no field examples (known exploits
of USB this way). Firewire, on the other hand, the case for
that one is well known. People were using it for debugging,
before it was considered as a security issue. (And it's
an issue if the perp is standing next to the computer and
a Firewire port is available.)

Paul

1) Multiple keyboards at boot:
Connect to the first found, get a login, ask what to do about the
others. Obviously, accept no input from any keyboard but the first
until authorized. Perhaps only permit root to authorize additional
keyboards.

2) Additional keyboard appears after boot:
Ask a logged-in user what to do. Obviously, accept no input from the
new keyboard until authorized. Perhaps only permit root to authorize
additional keyboards.

3) Connected keyboard vanishes, new one appears:
Log the user who was using that keyboard out with an informative
message. Connect the new keyboard and accept a log-in via it.

A message should be printed to the console any time a new USB device is
connected. Certain classes of device should not be connected without
authorization from a logged-in user. Perhaps some should require
permission from root.
--
John Hasler

Dancing Horse Hill
Elmwood, WI USA

Paul writes:
USB peripherals only respond to queries, or give acks on a
write. There is no RDMA on USB, because it's not a peer to peer
technology. The peripheral cannot say "give me data from physical
address 0x12345678". The peripheral does not possess the ability to
initiate a transaction. Only when the host polls at regular intervals,
does the peripheral get a chance to talk. The host can send data to
the peripheral, as long as the peripheral completed it's last
transaction and is ready for it. The host side DMA structure, the
addresses used, are controlled by the host driver, with no reason to
modify the DMA structures on some request from the peripheral ("move
your buffer to 0x12345678").

Thus the "flaw" is entirely in the OS.
--
John Hasler

Dancing Horse Hill
Elmwood, WI USA

On 2014-08-03, J. P. Gilliver (John) wrote:
In message
wwvlhr681kn.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueX f87AxnpFoA.invalid,
Richard Kettlewell writes:
"J. P. Gilliver (John)" writes:
writes:
"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.)

Better avoid Shakespeare then...

I do try to, wherever I can; his Mafia held sway for sufficiently long
in the English Literature world that it's quite difficult to do so,
though.

Yes, just like Newton's and Einstein's hold sway in Physics{-)
They just stop you from convinicing everyone that your wonderful theory
is right.

On Sun, 3 Aug 2014 12:39:40 +0100, J. P. Gilliver (John) wrote:

In message , Gene E. Bloch
writes:
On Sat, 2 Aug 2014 09:16:31 +0100, J. P. Gilliver (John) wrote:

"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.)

Copied from http://dictionary.reference.com/

dub
1 [duhb] Show IPA
verb (used with object), dubbed, dub·bing.

(Not sure what that bit was about. Presumably there's some significance
to the "1" not having a "." after it as below.)

That says it's dub 1, i.e., the first headword spelled "dub", it offers
to show the IPA (International Phonetic Alphabet) pronunciation for the
word, and it indicates that it's a transitive verb.

The missing period is of no consequence.

1. to invest with any name, character, dignity, or title; style; name;
call: He was dubbed a hero.

Have you ever heard anyone, other than in print or giving a speech or
something, actually use the word in that way?

Often.

That's why I cited the dictionary definition for your edification.

2. to strike lightly with a sword in the ceremony of conferring
knighthood; make, or designate as, a knight: The king dubbed him a
knight.

--
Gene E. Bloch (Stumbling Bloch)

On Sun, 03 Aug 2014 10:48:55 -0400, John Hasler wrote:

Thus the "flaw" is entirely in the OS.

No! The flaw is that you can hook one computer up to another using a
usb cable, and use the first one to read/write memory without the os
on the second even being aware of it.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins writes:
No! The flaw is that you can hook one computer up to another using a
usb cable, and use the first one to read/write memory without the os
on the second even being aware of it.

Explain how.
--
John Hasler

Dancing Horse Hill
Elmwood, WI USA

On Mon, 04 Aug 2014 19:56:58 -0400, John Hasler wrote:

David W. Hodgins writes:
No! The flaw is that you can hook one computer up to another using a
usb cable, and use the first one to read/write memory without the os
on the second even being aware of it.

Explain how.

Pretty sure I posted the link earlier in this thread ...
https://en.wikipedia.org/wiki/DMA_attack

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins writes:
No! The flaw is that you can hook one computer up to another using a
usb cable, and use the first one to read/write memory without the os
on the second even being aware of it.

I wrote:
Explain how.

David W. Hodgins writes:
Pretty sure I posted the link earlier in this thread ...
https://en.wikipedia.org/wiki/DMA_attack

USB is not mentioned in that article, and for good reason. But in any
case you wrote:

...you can hook one computer up to another using a usb cable, and use
the first one to read/write memory without the os on the second even
being aware of it.

Ok. I've got a computer sitting here running OpenBSD. Connect your
computer to it via USB and do DMA to/from its memory without the OS
being aware. Explain how you do this and how it works.
--
John Hasler

Dancing Horse Hill
Elmwood, WI USA

John Hasler wrote:
David W. Hodgins writes:
No! The flaw is that you can hook one computer up to another using a
usb cable, and use the first one to read/write memory without the os
on the second even being aware of it.

I wrote:
Explain how.

David W. Hodgins writes:
Pretty sure I posted the link earlier in this thread ...
https://en.wikipedia.org/wiki/DMA_attack

USB is not mentioned in that article, and for good reason. But in any
case you wrote:

...you can hook one computer up to another using a usb cable, and use
the first one to read/write memory without the os on the second even
being aware of it.

Ok. I've got a computer sitting here running OpenBSD. Connect your
computer to it via USB and do DMA to/from its memory without the OS
being aware. Explain how you do this and how it works.

First of all, you can't hook two regular desktop hosts together.
The devices would have to be OTG (On The Go) type. This is something
more common with mobile devices and SOC chips. Apparently
there is some protocol so they can decide who is the host and
who is the peripheral (when two OTG meet). The peripheral is passive,
and answers host queries, more or less like a regular host
to peripheral session would.

To hook two regular hosts together, you need a cable with a
ping-pong (bidirectional mailbox chip). Each computer thinks
it is the host, and drops items in the mailbox as if the mailbox
is a peripheral. They appear magically on the other side, to be
picked up by the host which thinks it is "reading data" from a
peripheral. When these first came out, there were custom drivers
and no class defined for the devices. Now, I think there is a bit
more basic support. It solves the host to host problem, by
converting it to a "host -- peripheral -- host" setup
instead.

"PL-25A1 USB2.0 Host-to-Host Bridge Controller"
http://www.prolific.com.tw/US/ShowPr..._id=34&pcid=43

Of all of these, there is still no indication of anything
remotely approaching RDMA. Drivers on each host are still
there to supervise what happens, tightly control buffer
usage for returned packets and so on. If there is an attack
mechanism, I'm not seeing a tech description that details
how it was possible. Merely hinting that it is there
is not enough. The first person accounts of people who
used Firewire RDMA, was sufficient proof such a capability
existed on Firewire. There are no such articles for USB.

Could you tip over a USB host, by feeding it malformed packets ?
Maybe. But then, that would not be an RDMA attack - the attack
would have another, unique name.

Paul