J
John Hasler
Paul said:
Thus the "flaw" is entirely in the OS.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
BadUSB security flaw (massive undetectible USB reprogramming vulnerability)
Thus the "flaw" is entirely in the OS.
W
William Unruh
In message
I do try to, wherever I can; his Mafia held sway for sufficiently longJ. P. Gilliver (John) said:"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...
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.
G
Gene E. Bloch
Gene E. Bloch said:"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.
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.
J
J. P. Gilliver (John)
Gene E. Bloch said:In message <[email protected]>, Gene E. Bloch
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.
Ah, so there were others you didn't quote.
The missing period is of no consequence.
Often.
Our experience varies - maybe it's a transpondian thing.
J
J. P. Gilliver (John)
Newton and Einstein codified certain aspects of the natural world; onWilliam Unruh said: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.
the whole, they've been proved right by others. The only "proof" for
Shakespeare's alleged dominance is other's refusal to challenge it. I
don't deny he was good at what he did: he told some good stories (and
the fact that some of them were old ones doesn't matter), and definitely
had a way with language too; all I object to is that he gets put on a
different _level_ to all others. I _don't_ consider him on the same
level in literature as I do Newton and Einstein in physics.
G
Gene E. Bloch
Gene E. Bloch said:In message <[email protected]>, Gene E. Bloch
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.
Ah, so there were others you didn't quote.
Did you notice the ellipsis in my post?
D
David W. Hodgins
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
J
John Hasler
David said: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.
D
David W. Hodgins
Explain how.
Pretty sure I posted the link earlier in this thread ...
https://en.wikipedia.org/wiki/DMA_attack
Regards, Dave Hodgins
J
John Hasler
David said: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
Explain how.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.
P
Paul
John said:David said: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
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/ShowProduct.aspx?p_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
J
John Hasler
Paul said: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.
D
David W. Hodgins
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/archives/2006/06/hacking_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/mobi...ly-subverted-researchers-claim/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
D
David W. Hodgins
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.
P
Paul
David said: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
J
Jasen Betts
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.
R
Richard Kettlewell
David W. Hodgins said: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?
A
Aleksandar Kuktin
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.
G
Gene E. Bloch
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...
P
Paul
Richard said: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/usbnutshell/usb3.shtml#USBProtocols
The sets of packets in transactions, are shown in diagrams here.
http://www.beyondlogic.org/usbnutshell/usb4.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