BadUSB security flaw (massive undetectible USB reprogramming vulnerability)

Paul writes:
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.

And it would not be "without the OS being aware". Quite the contrary:
it would rely on bugs in the OS.
--
John Hasler

Dancing Horse Hill
Elmwood, WI USA

On Mon, 04 Aug 2014 20:44:18 -0400, John Hasler wrote:

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.

Another link I've already posted ...
https://www.schneier.com/blog/archiv...g_compute.html

From that article ...
"Two features that make this possible are the Windows AutoRun facility and the ability of peripherals to use something called direct memory access (DMA). The first attack vector you can and should plug; the second vector is the result of a design flaw that's likely to be with us for many years to come."

And following the links from that article ...
http://www.informationweek.com/mobil...d/d-id/1297707

It's clear that usb devices have dma access, and can be used to read or
write memory, without the os being aware.

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

On Mon, 04 Aug 2014 22:43:43 -0400, John Hasler wrote:

And it would not be "without the OS being aware". Quite the contrary:
it would rely on bugs in the OS.

NO! The peripherals like usb and firewire devices have direct memory
access, that the os cannot monitor, due to the way those controllers
are designed to work.

The attacking computer pretends to be a normal peripheral. As soon as
it's connected to the computer being attacked, regardless of what the
os does, it has dma access, so it can read/write memory without the os
being able to detect it. The whole point of dma access is that the cpu
does not have to be involved in the data transfer. It's a very basic
design flaw in the hardware specifications.

In a normal usb connected hard drive, or stick, that is used to speed
up data transfers to/from the device. The os cannot block access, no
matter what os is in use.

--
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 wrote:
On Mon, 04 Aug 2014 22:43:43 -0400, John Hasler
wrote:

And it would not be "without the OS being aware". Quite the contrary:
it would rely on bugs in the OS.

NO! The peripherals like usb and firewire devices have direct memory
access, that the os cannot monitor, due to the way those controllers
are designed to work.

The attacking computer pretends to be a normal peripheral. As soon as
it's connected to the computer being attacked, regardless of what the
os does, it has dma access, so it can read/write memory without the os
being able to detect it. The whole point of dma access is that the cpu
does not have to be involved in the data transfer. It's a very basic
design flaw in the hardware specifications.

In a normal usb connected hard drive, or stick, that is used to speed
up data transfers to/from the device. The os cannot block access, no
matter what os is in use.


RDMA implies the source and/or dest address registers
and length register on the DMA, are programmed from the bus
side. That doesn't happen on USB. It cannot happen. When the
data is delivered from the bus side, host side DMA programming
controls where it goes. The key point here is *USB does
not get to control an Address generator* - not from the
peripheral side. The Host controls its own destiny.

The DMA on USB, is programmable only from the host side.
And only in association with having knowledge of expected
packet sizes as well. You can look with something like
Uwe Sieber's USBTreeView, for info on the sizes involved.

I'm a big fan of DMA, having added one address and two
address generators to hardware designs, while I was
designing hardware. Back on some of our older hardware,
it would take 50 microseconds for the slow processors
we used, to program these things (some of our IOPs ran
at 1MHz back then). It's just a wee bit faster now.

Shoving stuff up the snout of USB, violates all the
architectural principles. The emphasis on host-peripheral
architecture, tells me that. While OTG would at first
glance seem to be a violation of that architecture,
ti really isn't. Two devices, on the fly, either
decide to do one of the other of these.

host -- peripheral
peripheral -- host

The architecture is not violated. OTG allows negotiation
of role, so each party understands what it has to do.

Let's pretend the plug-in device is the one on
the right. For the first of the two lines, if that's
what they decide to do, the host on the left prepares
DMA addresses.

Now, let's check the second line. Now, the thing on
the left ("my computer") is being treated as a peripheral.
But a peripheral has to have a defined class for this
sort of thing to work, a set of data structures, places
to put things. If I was an intelligent peripheral,
maybe even DMA is involved. But again, the thing on the
right has no mechanism to send physical or virtual
addresses across the bus. There is no "DMA programming
packet". There are endpoints, packets with defined duties,
such as isochronous data transfer for video capture.
Again, I see no mechanism to do the job - no
"DMA programming packet", and no RDMA capability.

Paul

On 2014-08-05, David W. Hodgins wrote:
On Mon, 04 Aug 2014 20:44:18 -0400, John Hasler wrote:

From that article ...
"Two features that make this possible are the Windows AutoRun facility and the ability of peripherals to use something called direct memory access (DMA). The first attack vector you can and should plug; the second vector is the result of a design flaw that's likely to be with us for many years to come."

not convinced, find a real reference, not an opinion piece that states the RDMa
vulnerability is present in USB.

It's clear that usb devices have dma access, and can be used to read or
write memory, without the os being aware.

clear as mud.


--
umop apisdn


--- news://freenews.netfront.net/ - complaints: ---

"David W. Hodgins" writes:
John Hasler wrote:

And it would not be "without the OS being aware". Quite the contrary:
it would rely on bugs in the OS.

NO! The peripherals like usb and firewire devices have direct memory
access, that the os cannot monitor, due to the way those controllers
are designed to work.

Perhaps it’s time you started referring to specific USB specification
sections?

--
http://www.greenend.org.uk/rjk/

On Sat, 02 Aug 2014 06:10:04 +0000, William Unruh wrote:

On 2014-08-01, Gene E. Bloch wrote:
On Fri, 1 Aug 2014 14:37:44 -0700, Gene E. Bloch wrote:

[snip]

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

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

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.

Modern X servers handle hot-plugging human interfaces (keyboard & mouse)
natively. The details depend on the exact configuration of the X server
but, conceivably, a malicious USB device can type stuff into the X
server. Provided it know when and what to type.

Firmware on a USB device primarily handles the "backroom operations" such
as physically writing to and reading from the Flash chip. It also sends
and receives USB packets with the host controller inside the computer
(desktop, laptop or smartphone). The firmware never leaves the device
(obviously), but its operation can and routinely does have far-reaching
consequences.

On Mon, 04 Aug 2014 21:52:59 -0400, Paul wrote:

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.

Thanks for that. I've never researched how that was done, so your
explanation is interesting.

It also reminds me (a little bit) of the old technique of shared memory,
where one device would store communications in the shared RAM and the
other would read it there. There are obvious protocol needs involved
there, which by now I have completely forgotten...

--
Gene E. Bloch (Stumbling Bloch)

Richard Kettlewell wrote:
"David W. Hodgins" writes:
John Hasler wrote:

And it would not be "without the OS being aware". Quite the contrary:
it would rely on bugs in the OS.
NO! The peripherals like usb and firewire devices have direct memory
access, that the os cannot monitor, due to the way those controllers
are designed to work.

Perhaps it’s time you started referring to specific USB specification
sections?


No, Hodgins started this, and I'm not reading
a thousand pages of specs that don't have
the answer, for him. The USB specification
does not describe how to build a DMA logic block.
That's for the chipset designer to do.

USB is not a network device. It does not allow a peripheral
to "send un-announced packets". Because the protocol is
polled, and polling is controlled from the host side, the
host is always in control.

http://en.wikipedia.org/wiki/Usb

"In USB 2.0, the host controller polls the bus for
traffic, usually in a round-robin fashion."

http://www.beyondlogic.org/usbnutshe...l#USBProtocols

The sets of packets in transactions, are shown in diagrams here.

http://www.beyondlogic.org/usbnutshe....shtml#Control

"However under USB if a device requires the attention of the host,
it must wait until the host polls it before it can report that it
needs urgent attention!"

And that should tell you right away, that unannounced or out
of sequence packets, are going no-where fast.

*******

http://en.wikipedia.org/wiki/USB_3.0

"Improved bus utilization – a new feature is added (using packets
NRDY and ERDY) to let a device asynchronously notify the host of
its readiness (no need for polling)"

That's a protocol change, used to pass status for the device, back
to the host. The protocol description appears to logically fulfill
the same role as in USB2.

"The SuperSpeed transaction is initiated by the host making a request
followed by a response from the device.

The device either accepts the request or rejects it. If accepted
then device sends data or accepts data from the host.

If the endpoint is halted, the device shall respond with a STALL handshake.

If there is lack of buffer space or data, it responds with a Not Ready
(NRDY) signal to tell the host that it is not able to process the request.

When the device is ready, it will send an Endpoint Ready (ERDY) to the
host which will then reschedule the transaction."

*******

The next protocol layer up, is the Class specifications.
But the responses are all under host driver control. If the
USB committee were foolish enough to define RDMA over CDC,
then the details could be found here (in the CDC section).
But that still does not allow the peripheral to send unannounced
packets. It would be a security hole, defined in a higher
layer of the protocol model. The host would still be polling and
using the above lower-layer protocols, to hand-deliver such
a request. If there were an RDMA over CDC feature, then
the Simson article would have referred to that, rather than
fiddling around with HID hacks.

http://www.usb.org/developers/devclass_docs#approved

There are a ton of documents to read. A USB implementer
would be the best person to paraphrase this stuff. Me
reading it all from end to end, ain't happening. I get
paid to do stuff like that.

HTH,
Paul

Paul writes:

Richard Kettlewell wrote:
"David W. Hodgins" writes:
John Hasler wrote:

And it would not be "without the OS being aware". Quite the contrary:
it would rely on bugs in the OS.
NO! The peripherals like usb and firewire devices have direct memory
access, that the os cannot monitor, due to the way those controllers
are designed to work.

Perhaps it’s time you started referring to specific USB specification
sections?


No, Hodgins started this, and I'm not reading
a thousand pages of specs that don't have
the answer, for him.

I think you should have a more careful look at who I was responding to.

--
http://www.greenend.org.uk/rjk/